On Wed, Feb 18, 2009 at 10:34 AM, mark gibson <[email protected]>wrote:
> Hi,
> So I am working with the shape visibility flags. So at first I used a
> shape (balls) that was used for the node, but there was more than one
> shape being used to display the node (ball, halo,...) so this didnt seem
> like the way to go.
> So now Im using (or misusing?) NODE_IN_MODEL flag, which does hide &
> show the nodes.
right, well, don't do that. Those are all internal aspects of Jmol. You
should restrict yourself to the public JmolViewer interface, not the public
methods of Viewer. We have a commitment to not change those interface
methods, as much as we can, but absolutely none with respect to the other
public Viewer methods. Those methods are "public" only because they are
needed by classes in other Java packages outside of org.jmol.viewer.
Your interface should be using JmolViewer.evalString(...) for everything the
user is involved in, and I can't imagine there would be any problem doing
what you want to do with a script.
If Jmol can't do what you want to do with a script, ask about it -- maybe
you don't know of a command, or maybe you have a good idea that we can
implement.
> 3) Add my own bit/flag for hiding that doesnt get reset on
> eval-tainted-redraw.
>
> Im leaning towards #3, as it doesnt seem like theres a way to do what I
> want to do. But I wanted to check if Im missing something.
>
> I should mention I did at first try the hide/show in the scripts. But
> they were absolute and thus awkward for my purposes. So I couldnt just
> say hide node 3 without having all the other nodes then show, where I
> wanted to be able to say hide node 3 without having an effect on all the
> other nodes. In other words I didnt want to have to set the hide/show
> state for all nodes just to have to set the state for 1 node.
>
Angel has your answer ---
hide hidden or....
display displayed or....
Seriously, you should be able to do anything with scripts. Scripts even
accept atom bitsets in the form ({2,3,5,5}).
> Thanks for your help,
> Mark Gibson
>
>
> Bob - thanks for your previous response - it was very helpful - and some
> comments below. (Are you the main jmol developer - how many jmol
> developers are their out there? just curious)
>
> Robert Hanson wrote:
> > Hi, Mark,
> >
> > It's certainly fine to take Jmol and use it in any way you like.
> >
> yea we are definitely doing that
>
> > Mostly I would recommend being careful about changing classes, as you
> > can easily get stuck with problems when we upgrade Jmol. But a good
> > way to do this is to subclass the Jmol classes so that all your code
> > goes into a layer above ours, and you can always at least try to pull
> > newer Jmol code in under that layer. (If that makes any sense...)
> >
> This is good advice but unfortunately its too late. I came in late to
> this project. The way it was done was to mostly modify jmol classes to
> suit jnet needs. And my colleague occasionally tries to merge with
> latest versions (11.7.22 is our last merge) but thats getting harder and
> harder as you might imagine. So unfortunately I think we are diverging
> from jmol and wont get to pick up on the latest stuff (though if there
> is something we really need we'll probably attempt some subset merging?)
>
> > The reason to use the scripting interface is that then you pretty much
> > guarantee continued access to any newer Jmol versions.
> >
> Ok, so the scripting interface is THE interface, and no java interface
> is planned? and why have a java interface if you have a scripting one i
> suppose right?
> And probably are jamming of jmol into our java application and talking
> to each other via java is probably a little unorthodox(?)
>
> > Merging really is quite a major operation. It does integrate perfectly
> > new atoms and bonds into the old. But you are right that the operation
> > itself adds independent sets of atoms and bonds. Then, if you wanted
> > to connect those to already-present atoms, you would use the "connect"
> > methods.
> >
> > There are two modes of merging -- where you create a new "frame" and
> > when you "append" to an existing frame. Sounds like you are interested
> > in the append business.
> >
> > Jmol does the following:
> >
> > 1) FileManager creates an "AtomSetCollection"
> > 2) ModelManager creates (or merges this into) a "ModelSet"
> >
> > Probably the best place to start, because it involves no file reading,
> > is in Viewer:
> >
> > private String createModelSetInline(String strModel, Hashtable
> htParams,
> > boolean isAppend, boolean
> createModelSet) {
> > //loadInline, openFile, openStringInline
> > if (!isAppend)
> > zap(true, false);
> > fileManager.createAtomSetCollectionFromString(strModel,
> > setLoadParameters(htParams), isAppend);
> > return (createModelSet ? createModelSetAndReturnError(isAppend) :
> null);
> > }
> >
> >
> > This is 11.7 code. Note that I recently refactored this section
> > because there were some bugs that were creeping in, and I couldn't
> > figure out what was going on. So these methods will be different with
> > previous versions.
> >
> Well fortunately we are on 11.7 so we' must have your fixes.
> So dont know if this is of interest, but I ended up adding my own
> methods to be able to dynamically add new nodes to the existing model
> set. Basically reused/exposed ModelLoader.addNode method and had to set
> a few other bitsets (in shape and such) and it seems to work ok.
>
>
> > Hope that helps.
> >
> > Bob
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Jan 13, 2009 at 10:02 AM, mark gibson <[email protected]>
> wrote:
> >
> >> Hi,
> >> Just joined the list.
> >> I was wondering about ModelSet merging.
> >> From looking at the source, merging doesnt seem to be a way of adding
> >> additional nodes and edges to an existing model set(where new edges may
> >> connect old & new nodes), but seems like its a way of having multiple
> >> model sets in jmol. Do I have this right?
> >>
> >> Is there some existing way to add more nodes and edges to an existing
> >> (already created) ModelSet?
> >>
> >> If there is developer documentation on this please point me that way.
> >> What is there for developer documentation?
> >>
> >> To give some background, my colleague Victor Chest, whom I am now
> >> helping, has created an application called NBrowse that is used to
> >> visualize genetic interactions. JMol is embedded inside of NBrowse
> >> essentially.
> >> NBrowse had been mostly talking to JMol via its scripts, and Ive been
> >> adding more direct java interaction.
> >> I am guessing this was probably not an intended use of JMol? That is
> >> basically to be used as a library rather than a stand-alone application?
> >> (not to mention being used for viewing genetic interactions rather than
> >> molecules)
> >>
> >> Thanks for your help,
> >> Mark Gibson
> >>
> >>
> ------------------------------------------------------------------------------
> >> This SF.net email is sponsored by:
> >> SourcForge Community
> >> SourceForge wants to tell your story.
> >> http://p.sf.net/sfu/sf-spreadtheword
> >> _______________________________________________
> >> Jmol-developers mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/jmol-developers
> >>
> >>
> >
> >
> >
> >
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Jmol-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
