I'd add several GUI suggestions: - Cut, Copy, Paste (and ultimately a "library" of preset molecules and groups for pasting directly - A "lasso" tool for selecting a region - A "measure" tool for measuring distances, angles, torsions (or three separate tools, whichever is easier) - Undo/Redo - A "symmetrizer" for adjusting to a specific symmetry. I have some GPL'ed code to detect symmetry of a molecule with a tolerance adjustment, so it's adapting this... - More complete documentation from GNOME I'd also add some render suggestions: - User prefs for colors, number of polygons, etc. - Rendering modes for export to POVRay or "flat" circles and lines for black and white printing In the near future, I will probably be working on: - More file translators for OELib - User prefs (as above) - "Revert file" and "Save" features to use the last filename

Just to add to the wishlist-- Toolbars! instead of a popupmenu item to change the current element/bondtype, have it be toolbar, a la gimp/spartan/etc. More functionality to the select tool ie delete selected, move selected/ in addition to cut/copy selected. in the nearest future, i am working on rendering double/triple/conj. bonds in ball and stick and cylinder mode comments/questions? - James Schroeder jschroeder@northwestern.edu

> More functionality to the select tool Actually you can move/rotate/orbit selected if you hold down the shift key. As I said, documentation for the GNOME frontend is needed... -Geoff

I would like to define what I expect we have in the v1.0, and then divide my wishlist/plan to "pre-1.0" and "post-1.0" parts. I would like to promote the version number to 1.0 when we have all the "standard" QM and MM techniques properly implemented and easily available to the users. In this group I would take for MM geometry optimization and molecular dynamics, and for QM geometry optimization and some kind of transition-state search (if possible, I don't really know how difficult one this is). Where are we now? In MM, we have the algorithms, but only a very simple and limited forcefield. The QM case is opposite: we don't have the algorithms yet, but we have the excelent MPQC program that we can use in calculations. I think it will take roughly a year for us to reach the v1.0 (using that my definition of v1.0). The "pre-1.0" wishlist: ^^^^^^^^^^^^^^^^^^^^^ - a better "treelist view"; this will probably wait for the next GNOME version. - graphical input-file generators for programs like MPQC and ammp (or other programs???), implemented as gnome "druids"; currently we have under directory "small-utilities" a program "gp2mpqc" that inspired me to this. - improved documentation, for both developers and users. - and of course, those standard MM and QM techniques I mentioned above. The "post-1.0" wishlist: ^^^^^^^^^^^^^^^^^^^^^ - there are many smaller tweaks that I have thought, but I think I will leave most of them at this stage. - data exportation in CSV (comma separated values?) format. Some time ago I planned spreadsheet-like properties and plotting, but I believe we can use external programs for all that if we have good data export properties. In the near future, I will probably be working on: - suggest a way how to implement data exchange between mm1_mdl <=> OELib. - suggest a way how to implement quick "mode changes" mm-model <=> qm-model, and how to implement "layered" models. - I'm actually quite happy with the GUI at the moment, so I expect to spend more time working with those "engine" classes in future... Ok, as I'm responsible for the largest part of the current class framework, I think I'm also responsible for all that stuff where co-operation with other programs and libraries are needed. So please just throw me some questions if you have any. When we plan some new features, I might cough up some example code to show how we might do that (in my opinion) easily. On the other hand, I might start yelling if you propose some (dramatic) changes to the core part of the current framework; unfortunately I'm quite dependent on all that at the moment...