Rene wrote: > Sorry that this is going to be a long message.
OK > I am trying to reason my > way through the complex interconnections of the classes in the > datamodel api... I understand that the layers of data abstraction are not very clean. It has evolved over time ... sorry. > The AtomSet in the AtomSetChooser is just a class that maintains the > name to be shown in the JTree and the atomSetIndex for the associated > atomSet. I think that you can now get this data directly from the viewer. But you may want to keep this as a separate class to help you as you construct your hierarchy ... don't know. > What I am trying to update is the (tree) information needed to show the > GUI (JTree) that allows you to pick an AtomSet from the > AtomSetCollection. Since the window's show() is called when the user > clicks activates it in the menu, I could rebuild that information by > overriding the show() method of the JDialog, or could build it once at > the end of the interpretation of the file that was read. I thought that > it would be more expedient to do it only once after the > AtomSetCollection changed. OK >> No. It needs to happen in FrameBuilder. All interpretation of data from >> the JmolAdapter is happening there. > > It looks like some of the data interpretation from the JmolAdapater > happens also in the setClientFile of the ModelManager. You are correct. Unfortunately, my (so-called) design of this stuff did not work out well. My idea was that the ModelManager would hold a set of Frames (or Models). Back in Feb/Mar that changed because of something with .pdb files. So I went ahead and dumped everything into the Frame. Later, I felt like Frame was getting too ugly ... so I broke out Mmset (molecular model set). That may have only added to the ugliness. That is the historical reason why the name is wrong and why there is confusion between ModelManager, Frame, and Mmset > That one seems > to deal with the AtomSetCollection information as a whole, not separate > AtomSet. It doesn't deal with the atomSetCollectionProperties . So > should I add a 'public AtomSetCollectionProperties > atomSetCollectionProperties' and a getter method for that (the set > should be done in the setClientFile method)? I think that I effectively did this. I will look at it some more today. Your AtomSetCollection should only be accessing this information through the viewer. That way I can rearrange/rationalize the internal data structures at some point, but your AtomSetCollection will be protected from the change and will not need to know about it. > The AtomSet information per AtomSet seems to be interpreted by the > FrameBuilder, which does not interpret the AtomSetProperties from the > adapter. So I assume that Frame needs to have a setModelProperties(int > modelIndex, Properties atomSetProperties) method (or add it to the > setModelNameNumber as a setModelNameNumberProperties method) which on > its turn needs to call the mmset.setModelProperties() method, also to > be added... (Mmset seems the be the endpoint of the layers > encapsulating for the stored information). > The getter method getModelProperties(int modelIndex) should then also > be added to the Frame and Mmset classes... Correct. I added these last nite ... apparently at the same time you were writing this message. >> But, I don't yet have a clear picture of what data you want to capture. > > What I am trying to capture is a the list of the AtomSets. At the > moment nothing else can be passed to the viewer to suggest that there > may be a grouping of AtomSets that may make more sense from the user's > standpoint, so until the Properties can be accessed from the > AtomSetChooser, I can not build anything but a flat hierarchy of the > AtomSets. You can now call viewer.getAtomSetProperty() or viewer.getAtomSetProperties() in your AtomSetCollection code. > So I basically want the FrameBuilder to call my > AtomSetChooser.refreshTreeModel() method (which I could give a > different name, like buildTreeModel()), either directly or by using an > event listener type mechanism... Yes. But you should be thinking that you want the JmolViewer to notify you when the AtomSetCollection has changed, not the FrameBuilder. The FrameBuilder is an implementation detail of the JmolViewer black box ... you are working at the JmolViewer layer. > Again, the additional part that I want access to is the > AtomSetProperties for each AtomSet, so I can decode a > hierarchy/grouping that I want to be able to step through via the > AtomSetChooser. You can now do this. > Then, later down the line (v11 or so), it would be nice if it were > possible to animate only a set of AtomSets (e.g, 0, 2, 4, 6, which > would be the AtomSets that conceptually belong together). Or v10.1 > Later, when showing the AtomSetChooser, I need to get to the > AtomSetProperties to provide visual feedback of Property keys/values > (text, so far, possibly very much later [v12 or so] some of those > properties could be interpreted as floats or ints and be used in a > graph like v9 started to do). OK > In the end I would like (as I showed in the image with my previous > message) to have a hierarchy (path) of where the AtomSet conceptually > belongs. Put the keys in the properties so that you can construct this. You can now access the properties through the viewer. Make sure that your code gracefully handles the situation where the properties are not defined for the particular AtomSetCollection. > You may recall that if you do a Gaussian calculation using > symmetry, you get two orientations (z-matrix or input and standard). > During an optimization each step outputs the two, so you get the > z-matrix or input with the even AtomSetIndices, and the standard one > with odd ones. From an animation standpoint it is clearer to see what > is happening if you only see one of the two sets. The thing is that I > don't think we should limit the user to which set they can pick). I did not really follow this, but that's OK >>> 4) I am currently using (in AtomSetChooser) the viewer.modelManager's >>> methods to get to the AtomSetCollection information that was loaded. I >>> am not sure whether this the right place to get to this. >> >> All access needs to go through the viewer directly. Therefore, you >> should >> not access the modelManager directly. Rather, you should add methods to >> the JmolViewer which delegate to the managers. > > Uhmm, I am hesitant to add too much stuff to the JmolViewer, wasn't > that one of the classes I am supposed to stay away from? Correct :-) But I think the access methods are now implemented for you. > It also does > not seem that the methods needed to get the AtomSet information fits > too well with what is in there. It only has the getModelSetName and the > getModelFileHeader that gets me only to the AtomSetCollection > information as a whole, not that of separate AtomSets in the > collection. It is now there. > I checked around in JmolViewer and was wondering whether, as opposed to > implementing all the same functionality at the JmolViewer level, I > really should be using the JmolAdapter returned by the > getExportJmolAdapter method. At the moment, the FrameExportJmolAdapter > seems to have only a few of the methods that the JmolAdapter requires, > so I am not sure whether this is still a class that you consider to be > useful? The FrameExportJmolAdapter is useful, but is intended for an entirely different purpose ... do not get distracted by it. > So it seems that the Properties array needs to be stored somewhere and > made accessible through either the JmolViewer (delegating it to its > modelManager, which delegates it to the Frame instance it maintains) Correct. Independently implemented as you suggested :-) > I am getting a bit dizzy with the amount of layers involved here :-), I know. I apologize. It needs to be refactored/rationalized. So, just stay away from that code and work at the JmolViewer layer. If you need something added to the JmolViewer then ask for it. > so I definitely need you to tell me where to put this (or you could do > it yourself, but I assume that you are busy working on other parts). I > have the feeling that there must be a good reason to have so many > levels of delegation going on, but it gets me quite lost... For historical reasons listed above. But it is all private ugliness that a user of the JmolViewer should not be looking at. > I think that with a few words, you can probably set me completely > straight and tell me where the Properties need to be stored, and how I > need to get to them. You should now be able to get them through the JmolViewer. > At the moment I think I came to the conclusion that we need to add: > > Frame: > void setModelProperties(int modelNumber, Properties atomSetProperties) > Properties getModelProperties(int modelNumber) > both of which are delegated to the > Mmset: > void setModelProperties(int modelNumber, Properties > atomSetProperties); > Properties getModelProperties(int modelNumber) Correct. Now implemented. Except that these are 'modelIndex', not 'modelNumber' > where the real instances of the AtomSetProperties are maintained. > The Frame.setModelProperties(int,Properties) will be called in the > buildFrame() Correct. Now implemented. > ModelManager : > void setModelProperties(Properties atomSetCollectionProperties) > Properties getModelProperties() // the AtomSetCollectionProperties > Properties getModelProperties(int modelNumber) // and > AtomSetProperties > > which will be called by > JmolViewer: > void setModelProperties(Properties atomSetSelectionProperties) > Properties getModelProperties(int modelNumber) There is no method for setting the model properties through the JmolViewer because that is not functionality that is exposed to the user of the JmolViewer. Getting is done. In addition, you can also get a single property JmolViewer.getModelProperty(int modelIndex, String propertyName) > I think that that puts all the Properties in the right place, but that > still doesn't provide me with the location where my > AtomSetChooser.buildTreeModel() is called so I can build the proper > representation of the AtomSets.... You are correct. I will take a look at this right away. >> Correct. We need to add methods to get the current model index, the >> name >> of the current model, and the number of the current model. > > From which class, and which one To the JmolViewer. Your only entry point to get data is the JmolViewer. >>> At this point in time, you can do an >>> animation (with the popup or through a script) but the AtomSetChooser >>> doesn't update its view to reflect that. On the other hand, maybe we >>> don't want to do that anyway? I am not sure. Any thoughts? >> >> I don't think that we want to update during an animation. But we should >> update when a user is stepping from frame to frame within an animation. > > Where can I register what kind of listener for that? Doesn't exist yet. Miguel ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
