Hi Yann - thanks for the reply!
I'm sorry I hadn't looked at it yet.
Shouldn't be too hard to do but I haven't had the time yet ( something about a collaborative book
chapter that has to be written jointly with not-so-responsive coauthors, ask Jim!)
ah yes. I'll send you another email about that in about 10 mins ( 
).
These are the features that we would really like to be able to restore:
-the current base positions in the diagramok, will do.
-the rotation of the structure
I prefer that we do not save this one, since a rotation will only affects the base coordinates.
Do you mean that the current base coordinates include the rotation ? If so, that's great - the idea is that if the user prepares a diagram 'just so', then they get it back when the load the project again.
-the draw algorithm
ok
-Annotations added to the sequence
Which one would you prioritize?
Textual annotations related to loops? of absolute XY coordinates?
Helices? Highlighted regions? Chemical probing style?
I'll leave it to Jan to work out the precise order, but I'd consider anything user created to be essential (any text annotations or interactively coloured parts of the structure for certain).
-base coloring
Single base styles then?
not sure. probably !
-zoom level
Do you really want that?
In my opinion, it might be preferable to "make everything fit" when loaded.
good point. However, the philosophy we took with Jmol was that if the user makes a special view, we don't mess with it when it gets reloaded - but provide some Jalview menu options above the Jmol window to allow the position to be reset, should the user want to do that.
-backbone color
ok
-base-pair style
ok, this will require exporting base-pair types (Leontis-Westhof classification)
How are those normally stored ? Jan and I have discussed the possibility of making the base pair representation within Jalview's datamodel richer - to facilitate visual analysis of the alignment w.r.t. base pairings, but we haven't identified the ultimate base pair datamodel as yet.
-color map
ok
-background color
ok
I also noticed that the selection of the sequence by a mouse click is
gone after one releases the mouse. In contrast to regions selected by
dragging a box around them. I'm not sure if it's by purpose by I think
it makes mouse selections a bit uncomfortable.I see, good point!
So you would expect a single click on a base to persistently select the base, right?
I think that's the normal expectation - having watched other people use VARNA as well, they do expect that when a base starts to flash when clicked, that it should stay flashing. However, it may be that these users are used to the way that Jalview operates - where a single click selects a position.
Please note that you can use shift to toggle/add bases/boxes to the selection.
Another thing is that we would like to send sequence or structure edits
that where made in VARNA back to Jalview. Are there some public usable
Listeners for that? I could not figure them out.Yes, we have a couple of listeners, but I'm not sure their design is clean enough to
be used within JalView. Could you again specify which features you had in mind?
We'd actually like to listen in to the following events:
* mouse over base position
- when the user moves the mouse on to a base, an event indicating the position within an associated VARNA RNA model is raised (reference to base, reference to model containing base).
* user selects part of or clears a selection on a structure
- event gives reference to model and list of bases selected, or null if the user cleared the selection.
* user modifies the RNA secondary structure
- event gives reference to model [and optionally - region of structure affected to allow efficient updating of Jalview's model].
Other events concerning colouring and annotation modifications could be used be Jalview in future versions - but at the moment, the only data exchanged between jalview and VARNA is sequence, base pairing, mouseover highlighting and (eventually) selections.
Do you think you could do something about this stuff?
Most certainly Yes, but it will depend on the time frame.
Jan is due to finish up his GSOC stint on 22nd August - which is almost certainly way too soon for you to do anything much. However, it would be nice if we could have interactive mouse overs/selections, and maybe structure edits exchanged between VARNA and Jalview by the end of his project - if that were at all possible.
Varna state saving is less urgent, but my hope is that Jan and I will be able to finish the VARNA integration ready for incorporation into Jalview series 2.7.x, and for this to happen, we need to be able to store VARNA states in Jalview projects.
I have started to lay the groundwork for VARNA state saving to save Jan some pain with XML schema modelling, and I'd suggest you start by working out a standard api for saving and loading these VARNA states that can import or export data (ideally via an abstract InputStream or OutputStream provided by the caller). Jan can then implement the necessary code in the VARNA/Jalview binding to call the API when a jalview project is saved/loaded. That way, integrating future updates to VARNA should require minimal (or no) modifications to the Jalview project save/loading code, and providing you have a basic format for representing the core aspects of a VARNA visualization that will be accepted by future versions of VARNA, you can embellish it at your leisure.
路路路
On 09/08/2011 09:13, Yann Ponty wrote: