On Wed, Feb 18, 2009 at 10:34 AM, mark gibson <mark.gus.gibson@gmail.com> wrote:
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

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 <mark.gus.gibson@gmail.com> 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
>> Jmol-developers@lists.sourceforge.net
>> 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
Jmol-developers mailing list

Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
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