From: E.L. W. (Egon) <eg...@sc...> - 2003-06-14 19:41:51
|
Hi all, Peter MR recently emailed about his CML files which look like: <list> <molecule id="m1"/> <molecule id="m2"/> </list> The molecules would all be placed in on ChemFrame (=AtomContainer)... I thought that I could easily solve this in CDKs CMLReader, but the problem was not really there, but in Jmol itself... Then I realized a reader in Jmol cannot open up a second Jmol window... that is, not with an easy patch that could go into the b6 branch... The problem: at this moment the Jmol Readers take a DisplayControl only, and no reference to Jmol itself... it can thus not call a specific Jmol method... But, it could use the approach used in the NewwinAction... However, problem 2: the Reader cannot open up a second window just like that... that would break it for use in the applet... which cannot open up a second window... The solution: The reader should detect in some way that it may open up a second window or not, or in other words, if it is used by an application or an applet... But I am not sure I want to fix this like this... in HEAD the IO is going to be moved to CDK, and CDK does it differently... the Reader then just returns a ChemObject of a certain class (well not really, but it should...) The application *or* applet can then decide what to do with the content... Why is this important: the <list> example is one reason why it is important... (is basically is equivalent with the SDF file problem) A second important reason is this: many optimization programs store both the optimization run in the output file *as well as* the input structure... such content is now shown as one animation leading to very strange behavior going from the first to the second frame... Ok, that's about it... Conclusion: Peter, I am sorry that I won't be able to fix your problem in the next release... but it will be fixed, at least with the new IO in CDK... Egon |
From: Miguel H. <mi...@ho...> - 2003-06-14 20:50:56
|
> The problem: > > at this moment the Jmol Readers take a DisplayControl only, and no > reference to Jmol itself... it can thus not call a specific Jmol > method... But, it could use the approach used in the NewwinAction... > > However, problem 2: > > the Reader cannot open up a second window just like that... that would > break it for use in the applet... which cannot open up a second > window... My quick thoughts. I think the way to do this is route it through the DisplayControl. The DisplayControl is already using an interface to deal with its two types of containers. (It is currently called JmolStatusListener ... but it is going to get a name change to JmolContainer). We can define a JmolContainer method to determine whether or not the container is multi-window capable. The IO code could route through the control to a) determine whether or not the container is capable of opening up multiple windows, b) request it to do so. I agree that this is not a short-term thing. Miguel |
From: Peter Murray-R. <pm...@ca...> - 2003-06-15 09:53:05
|
At 21:42 14/06/2003 +0200, E.L. Willighagen (Egon) wrote: >Hi all, > >Peter MR recently emailed about his CML files which look like: > ><list> > <molecule id="m1"/> > <molecule id="m2"/> ></list> > >The molecules would all be placed in on ChemFrame (=AtomContainer)... > >I thought that I could easily solve this in CDKs CMLReader, but the problem >was not really there, but in Jmol itself... Then I realized a reader in Jmol >cannot open up a second Jmol window... that is, not with an easy patch that >could go into the b6 branch... If there are a lot of molecules you don't want separate windows! I partially tackled this problem in JUMBO4 as follows: - read in many CML files (limit was ca 1500 before the memory ran out). - translate all to DOM and store in a Hashtable - create a Swing ComboBox listing the names of all molecules - allow the user to step through these (or scroll and select). Each selection *replaced* the current display in Jmol. I think you want to consider (if not implement) all the following: (a) a JUMBO-like display of "compound card" containing a JCP window (2D) and Jmol 3D for the molecule. In JUMBO this worked reasonably well but occasionally Swing gave problems. I'm not proud and if you want to include the approach in Jmol feel free. (Actually I think there is a potential role for a "ChemEdit" - rather like JEdit which encompasses several of the opensource tools) (b) a <list> or <molecule>s which are directly superimposable (i.e. all in same reference frame.). There are many reasons for doing this - pharmacophores, supramolecules, etc. An extension is to go to a service to generate the superimposition matrices (c) a *small* number of separate windows (?2) for human comparison of molecules (d) a <list> of unrelated molecules which should be shown sequentially on user command. This is what I currently need - we have files of 500 unrelated molecules in a single file and want to eyeball them. The ability to select by name (a la JUMBO) would be extremely useful (e)a list of related molecules (animation-like) - Jmol already does this, but it could be useful to have display of individual titles >The problem: > >at this moment the Jmol Readers take a DisplayControl only, and no reference >to Jmol itself... it can thus not call a specific Jmol method... But, it >could use the approach used in the NewwinAction... > >However, problem 2: > >the Reader cannot open up a second window just like that... that would break >it for use in the applet... which cannot open up a second window... In the applet it is particularly useful to be able to step through molecules. At present we generate 500 HTML pages, each with an applet and display them on demand. It would be useful to have one applet. I suppose there is a javascript workaround so we can poke in the CML to a single applet? If so, it would be useful even though I don't like Javascript for portability reasons >The solution: > >The reader should detect in some way that it may open up a second window or >not, or in other words, if it is used by an application or an applet... >But I am not sure I want to fix this like this... in HEAD the IO is going to >be moved to CDK, and CDK does it differently... the Reader then just returns >a ChemObject of a certain class (well not really, but it should...) >The application *or* applet can then decide what to do with the content... > >Why is this important: > >the <list> example is one reason why it is important... (is basically is >equivalent with the SDF file problem) Yes. - a useful analogy >A second important reason is this: > >many optimization programs store both the optimization run in the output file >*as well as* the input structure... such content is now shown as one animation >leading to very strange behavior going from the first to the second frame... Yes. We have examples of this (e.g. the pointgroup changes during optimisation and we wish to know why) >Ok, that's about it... > >Conclusion: > >Peter, I am sorry that I won't be able to fix your problem in the next >release... but it will be fixed, at least with the new IO in CDK... Understood P. >Egon > > >------------------------------------------------------- >This SF.NET email is sponsored by: eBay >Great deals on office technology -- on eBay now! Click here: >http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 >_______________________________________________ >Jmol-developers mailing list >Jmo...@li... >https://lists.sourceforge.net/lists/listinfo/jmol-developers |
From: E.L. W. (Egon) <eg...@sc...> - 2003-06-15 13:08:49
|
On Sunday 15 June 2003 11:48, Peter Murray-Rust wrote: > If there are a lot of molecules you don't want separate windows! Yes, that's true... > I partially tackled this problem in JUMBO4 as follows: > - read in many CML files (limit was ca 1500 before the memory ran out). > - translate all to DOM and store in a Hashtable > - create a Swing ComboBox listing the names of all molecules > - allow the user to step through these (or scroll and select). Each > selection *replaced* the current display in Jmol. > > I think you want to consider (if not implement) all the following: > > (a) a JUMBO-like display of "compound card" containing a JCP window (2D) > and Jmol 3D for the molecule. In JUMBO this worked reasonably well but > occasionally Swing gave problems. I'm not proud and if you want to include > the approach in Jmol feel free. (Actually I think there is a potential role > for a "ChemEdit" - rather like JEdit which encompasses several of the > opensource tools) > > (b) a <list> or <molecule>s which are directly superimposable (i.e. all in > same reference frame.). There are many reasons for doing this - > pharmacophores, supramolecules, etc. An extension is to go to a service to > generate the superimposition matrices > > (c) a *small* number of separate windows (?2) for human comparison of > molecules Yes, indeed... > (d) a <list> of unrelated molecules which should be shown sequentially on > user command. This is what I currently need - we have files of 500 > unrelated molecules in a single file and want to eyeball them. The ability > to select by name (a la JUMBO) would be extremely useful > > (e)a list of related molecules (animation-like) - Jmol already does this, > but it could be useful to have display of individual titles > > >The problem: > > > >at this moment the Jmol Readers take a DisplayControl only, and no > > reference to Jmol itself... it can thus not call a specific Jmol > > method... But, it could use the approach used in the NewwinAction... > > > >However, problem 2: > > > >the Reader cannot open up a second window just like that... that would > > break it for use in the applet... which cannot open up a second window... > > In the applet it is particularly useful to be able to step through > molecules. At present we generate 500 HTML pages, each with an applet and > display them on demand. It would be useful to have one applet. I suppose > there is a javascript workaround so we can poke in the CML to a single > applet? If so, it would be useful even though I don't like Javascript for > portability reasons The JavaScript on the Jmol website includes an example for reading files... And that code is quite portable... I believe the only platform/browser combo it does not work on is IE on Mac... Egon |
From: Miguel <mt...@mt...> - 2003-06-16 07:50:35
|
> In the applet it is particularly useful to be able to step through > molecules. At present we generate 500 HTML pages, each with an applet > and display them on demand. It would be useful to have one applet. I > suppose there is a javascript workaround so we can poke in the CML to a > single applet? If so, it would be useful even though I don't like > Javascript for portability reasons <script> function loadModel(filename) document.jmol.load(filename); } </script> <applet name="jmol" ...> </applet> |