Hi,
So I am trying to hide and show nodes/edges per user request - in gui
their are filter selections the user can select to hide nodes. (Some
background - I am not displaying molecules so the user isnt hiding atoms
- im displaying a graph of genetic interaction data, so the user is
filtering out parts of the graph they dont want to see)
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.
However when an eval script occurs (like our layout script that we
added), the tainted flag gets set in the Viewer.
This triggers setModelVisibility call on the next repaint.
Calling setModelVisibility has the effect of resetting all the
NODE_IN_MODEL bits (first bit)to true (see Balls.setVisibilityFlags),
which makes nodes that should be hidden reappear.
So my first question is am I misusing/abusing the NODE_IN_MODEL flag?
and what is its purpose? (and are their docs on this?)
And also why does evals set tainted and then reset all vis flags? Is
there some way of doing evals and not resetting vis flags? Should I muck
with the "refreshing" flag?
So it seems I could solve this in 3 different ways:
1) supress certain calls to tainted flag from eval - I actually did this
for our layout script, but other things are calling too. And this is
probably not the proper way to go.
2) Muck with Balls.setVisFlags so it only resets flags in certain
situations - which would require more flags to describe those situations.
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.
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
