I think Bradley should better respons, but will give my ideas anyway...
On Friday 06 September 2002 11:44, Fabian Dortu wrote:
> On Mon, 2002-09-02 at 23:07, Bradley Smith wrote:
> > My opinion of the patch is that it is difficient in a number of areas,
> > and is not ready to go into Jmol.
> > 1. Crystal properties don't warrant a menu of their own. Rather than
> > having Crystal/Properties, it should be Extras/Crystal properties...
> Ok easy to fix
> > 2. The menu item is activated regardless of whether crystal information
> > is read from the file. If caffeine.xyz is read, the crystal properties
> > are active with defaults that are certianly not going to be related to a
> > crystal structure of caffeine. In addition, the molecule explodes if the
> > Commit changes... button is clicked.
> I can easily disable it but I chose not to do that. Why? I think that
> the user should be able to load, for instance, a XYZ file containing no
> crystal information but containing the unit cell atoms and then go the
> the crystal menu to generate the crystal.
> For instance, the site http://cst-www.nrl.navy.mil/lattice/ gives the
> unit cell atomic positions in XYZ format of a lot of crystal. It gives
> also the basis vector in a separate file. With Jmol and my patch you can
> easily generate the crystal. I think it is the responsability of the
> user to chose when to use the crystal dialog.
That sounds very reasonable... When the menu is under Extra, this seems
> Now you say, that the molecule cafeine "explodes". Its true, but this is
> the expected behavior. Try to enlarge the crystal box and you will see
> that the molecule is translated into lattice points. Of course caffeine
> is a molecule and turning it into a crystal has no sens....
> > 3. Like most of the dialogs in Jmol, it overuses the TitledBorder.
> > Granted the same design is used throughout Jmol, but better design should
> > be used for new dialogs.
Are you going to make a TitledBorder-less version?
> > 4. Why is the total number of frames listed in the crystal properties?
> > What does that have to do with crystals properties?
> Actually nothing. I can remove it.
> But there is something to say about it. Each frame of the crystal can
> have it's own crystal properties. I mean the unit cell can change from
> frame to frame. It is usefull when you do "lattice optimization" with a
> DFT package for instance. So in the future I would like to add a dialog
> box that can allow the user to change of "active frame". So far, there
> is no way to do that in jmol(except when you are in the animate dialog).
> Thereby, as a starting point, I want to allow the user to change of
> active frame from inside Crystal-->Properties (not yet implemented). But
> I think it would be better to design a new dialog bow that can do that
> and display other usefull information at the same time.
I guess the frame number can be/should be displayed in the statusbar...
For the rest... the toolbar layout is pretty static at this moment. Buttons
are always enabled, right? Maybe we could have two buttons to move
trough frames... as sort of easy access to select frames... continuous views
of animation, with interpolation etc... can remain in the dialog as more
> > 5. Values entered into the dialog box are not checked for validity.
> > Incorrect values cause exceptions to be thrown.
> Right, I am not yet familiar with execeptions in Java. Will implement it
> later. Anyway, the way java handles unchecked exceptions keep the
> program stable even when a field is not valid.
What Bradley means is that you should check that the inputed value is correct.
*Otherwise* exceptions are thrown... You should better check the input, rather
than checking the Exceptions is input throws... Though, the latter might be
easier... If you need help, let me know... It is rather easy to add...
> > 6. The crystal properties dialog does not update if a molecule is read
> > while it is open.
> Thankx, I didn't notice.
> > 7. The space group information is missing.
> Right, not fully implemented
> > These are just the first impressions obtained from using the new code. I
> > have not looked at the implementation itself.
> > Personally, I don't understand the information presented in the crystal
> > properties. The information is different than that generally used with
> > protein crystallography, which uses cell dimensions (a, b, c) and angles
> > (alpha, beta, gamma), and the space group.
> My class CrystalFile will also support also this notation in the future
> (interface already implemented).
Yes, this would be useful for me too