Cytoscape Wiki|
← Revision 5 as of 2009-02-12 01:04:04
Size: 17737
Comment: converted to 1.6 markup
|
← Revision 6 as of 2009-03-05 16:57:12 →
Size: 7127
Comment: move undiscussed stuff elsewhere
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
|
This page was originally very long and listed a bunch of questions. I moved the ones that we didn't have time to discuss to [[DanielAbel/VisualizationQuestions]] |
|
| Line 10: | Line 13: |
|
== Questions about usecases (considering existing features): == === client/server boundary? === When doing "web rendering"/"Cytoscape light" where will the client/server boundary be? Between the viewmodel and the model? or between the viewmodel and view? === NodeDecorators or NodeRenderers? === Currently (in 2.6.x) custom graphics are done as a sort of 'NodeDecorators' instead of NodeRenderers. This could be simply a workaround, NodeDecorators being easier to fit into the 2.6.x implementation. Considering actual usecases, which would be a better match? If NodeRenderers would be allowed to be composed, ie. having multiple renderers that draw on top of each other, what kind of uses would that be helpful for? Would those usecases be better implemented by a single, customizable NodeRenderer? === VisualProperty Categories? === VisualProperties are currently grouped into three categories: there are Node, Edge and Global VisualProperties. Should these categories be fixed? I.e. instead of each VisualProperty being one of these, should we allow a general 'category' field, which would allow, say having a 'Group' or 'Metanode' category? Are categories needed at all? (I think yes, to allow vizmapper gui to be more user-friendly) Are there any need for them apart from making the vizmapper gui easier to navigate? Would some other mechanism be better for organizing them? === What events are needed in the viewmodel layer? === For example, most of the vizmapper gui should be using VISUALSTYLE_CHANGED (to signal that the VisualStyle of a given GraphView was changed to another one) and VISUALSTYLE_MODIFIED (to signal that a given VisualStyle was edited) events (which were not available in 2.6.x). Are these two events enough or would there be more needed? === Immutable VisualStyles === mentioned on Molecular_Interaction_Maps (search for "customizable"), and in general I think it would be useful to ensure consistency: VisualStyles could have a 'dontEdit' flag, and the vizmap user interfaces should ask for confirmation before allowing editing. (Totally prohibiting editing would be bad, this is more about avoiding accidental edits. Or is there a usecase for a real non-editable VisualStyle; and how would that be edited? :) ) For example VisualStyles read from xgmml files might have this dontEdit flag set. |
|
| Line 72: | Line 22: |
|
==== resolution ==== It will be a viewmodel property, implemented with 'subsets' |
|
| Line 90: | Line 44: |
|
==== resolution ==== Serialize the result (which is the viewmodel state) |
|
| Line 91: | Line 49: |
|
=== Allowing not one-to-one Mappings in vizmap? === Currently the vizmap layer supports only one-to-one mapping between attributes and VisualProperties. I think this years "Implementing Boolean Logic into the Display of Visual attributes" Summer of Code project was aimed at relaxing this restriction. Would supporting many-to-many Mappers be needed? (Many attributes to one VisualProperty, or one attribute to many VisualProperty) How would the GUI used for editing these look like? How would it be possible to both edit a many-to-many mapping _and_ to allow seperate mappings to each underlying, atomic VisualProperty? Allowing many-to-many Mappers might also allow 'composite VisualProperties': Currently some VisualProperties, like EDGE_WIDTH and EDGE_DASH, or NODE_COLOR and NODE_OPACITY are actually editing different aspects of the same underlying, native object (a {{{java.awt.Stroke}}} and a {{{java.awt.Color}}}) (For example, using this aspect a more intuitive gui could be possible.) It might be nice if these would be stored in the vizmapper in one place, ie. if the implementation would also reflect this more closely. Note that this is one place where design decisions made in the viewmodel layer will have HCI aspects: where forcing some structure in the viewmodel might affect what kind of interfaces are possible. We should be carefull not to close the door on exciting possiblities, even if we don't yet take advantage of those possiblities. === direct manipulation vizmap GUI? === Does the current (or any planned) vizmap / viewmodel API constrain (or make more difficult) writing direct manipulation-like vizmapper gui? (I.e. click on node and set 'nodes of these types should all be green'. Note that this is different from the VizMapperByPass, since in this case a Mapping is defined, and not a DiscreteMapping-like exception.) |
|
| Line 172: | Line 93: |
| === Tune cytoscape event loop to underlying toolkit === | ==== resolution ==== |
| Line 174: | Line 95: |
|
Fitting the event firing loop to the event-handling loop of the underlying graphical toolkit might be usefull for improving user experience. For example (althought strictly speaking it is not an event-handling issue), redrawing (re-rendering) the network only at most once between repaints (or instead of redrawing it, just set a 'redraw on next repaint' flag). I might be completely misguided here, but would the event firing framework need special tricks to make sure it plays nice with the event-handling of the underlying graphical toolkit? |
Debated at mini-retreat; since then, many proposals were suggested, see RFC |
| Line 184: | Line 97: |
|
(One example where I seen such issues is in http://ipython.scipy.org/moin/ where the read-eval-loop of the python prompt needs to know about the event loops of the graphical toolkits to play nice with them. This, however might be a 'scripting interpreter' issue and might not affect event-firing.) |
|
| Line 207: | Line 115: |
| === edge anchor ports === | ==== resolution ==== |
| Line 209: | Line 117: |
|
Currently edges are routed to somewhere on the boundary of the node. Should it be possible to define a few number of points on the node and enforce that all edges (or certain edges) can only terminate there? (This might be needed, for example, for molecular interaction maps) |
Debated at second mini-retreat; will be discussed further. |
| Line 215: | Line 119: |
|
How would such a thing be supported? Note that this also brings up another question: Apart from forcing the edge to end at an anchor point, should it be possible to allow anchor points to have special graphic? (This would mean that NodeRenderers would need to be given some information about the edges) === edges ending at edges? === Would it be possible to support 'edge ending at edge' in a non-hackish way? (see [[[Molecular_Interaction_Maps/EnzymaticStimulation]]] FIXME ) The hackish workaround, of course, is to add a placeholder node on the edge, and set the graphics of it to be unobtrusive, and set edge-ends accordingly. But would it be possible to handle this in a native way, without such workarounds? === Drawing one node in several places === A proposal to support "one node in several places" (look for 'constant nodes' on the [[Molecular_Interaction_Maps]] page) natively: (this is somewhat similar to the previous 'edge ending at edge', but in this case I think the following could work quite nicely): The idea is that this could / should be done entirely in the presentation layer, without affecting any layers below: thus it wouldn't mess up topology-using algorithms that only use the model layer, for example. The idea is to allow layout algorithms to create multiple positions for a node: i.e. to allow them to specify that 'I want to place this node here, there and over there'. Then, they would route edges to the closest one, as appropriate. For the layout algorithms, there are two possiblities: 1. the list of nodes which are allowed to be shown in multiple places are fixed externally. (To conform to whatever convention is used for MiM views.) 1. the layout algorithm itself figures out which nodes to show in multiple places (trying to minimize the number of such nodes, of course) Changes needed for this: 1. make the x and y nodepositions to optionally be lists 1. some API changes for CyLayouts to allow list of nodes that can appear multiple times. 1. some gui changes will be needed: for example 'create another view of this node' action somewhere. === unifying vizmapper and Attribute batch editing? === Should the possibility of unifying vizmapper (Attributes -> VisualProperty mapping) and the batched editing features of the DataPanel (Attributes -> Attributes mapping) be explored? VisualProperties, especially if they are made pluggable are very similar to Attributes (the biggest difference being that the object types are different). === Explicit support for syncing === I think having explicit support for syncing different instances of model, viewmodel layer objects should be explored: As described in my e-mail to cytoscape-staff on Oct 27, there will be usecases where synchronizing the views of the same object won't be as simple as 'use a shared instance of the foo layer object, but separate instances of the bar layer object, and it will synchronise everything magically'. In some cases it will be needed to synchronise state between two instances of a class. (For example, VisualStyle, but not layout of two GraphViews.) This, of course, can be done by doing this synchronisation 'manually': writing the needed event handlers and such. However, explicit support for this might be better: it might allow implementations of the given object (in our example, GraphView) to optimize for such uses (for example, they could use a common object to store that part, 'getting synchronisation for free' again, or optimize event-handling). In addition, it would be a great help for people implementing synchronized views of data and avoid reinventing the wheel every time such is needed. For example, inte the viewmodel one could have a method like {{{ thisGraphView.syncWith(thatGraphView, someVisualProperty)}}} to specify that the values of the given VisualProperty are to be synced. (The implementation of {{{.syncWith}}} could require that the networks of the two GraphView is the same object, and maybe event that the two GraphView objects are instances of the same implementation. In this case, the GraphView implementation could use the same column-like object instance to store the values, thus getting MVC-like automatic synchronising) {{{.syncWith()}}} would sync in both directions, depending on usecases another method that syncs only in one direction might also be useful. Note that this does not necessarily have to be part of the GraphView API, it might be enough if, say, the default GraphView implementation has such extra methods. (But in that case, how can plugin writers who want to use this functionality ask for such a hypothetical SyncableGraphView to be used for a given network?) On the other hand, the 'manual syncing' can be allways done in any GraphView implementation, so requiring that the GraphView implement that might be acceptable, if bloating all GraphView implementations is not too big a problem. === Changing MDI design? === An aspect to consider about presentation: currently the stand-alone Cytoscape program has an MDI design. This has some drawbacks, for example is less useful on multiple monitors, or see bug no.1931. If using a 'single document interface' (http://en.wikipedia.org/wiki/Single_document_interface) is considered for 3.0, that would mean that the current 'there is one editor, one vizmap editor for all networks' view would explicitly change to a 'each editor, vizmap panel belongs to one network view' setup. For example, the whole idea of having a 'global current VisualStyle' is obviously wrong, but I for one didn't realize this until I considered the 'each editor, vizmap panel belongs to one network view' setup. |
|
| Line 360: | Line 146: |
|
==== resolution ==== Since no-one objected, I assume these changes are acceptable. |
|
| Line 364: | Line 155: |
|
==== resolution ==== Since no-one objected, I assume this feature is acceptable. |
Some talking points for the mini-retreat
This page was originally very long and listed a bunch of questions. I moved the ones that we didn't have time to discuss to DanielAbel/VisualizationQuestions
Contents
The following is a list of questions / issues that I would like to ask others' opinion on during the mini-retreat. Some of these are strictly speaking not questions, but suggestions for discussion. Feel free to edit/comment either in-line or at the end.
Is 'selection' a viewmodel or model property (state)?
Currently in core3/model it is in the model layer, does it obviously belong there? Could it allow multiple different selections? (as described at the end of the PluggableRenderers page.)
In the model, is it the property of the CyNode/CyEdge or the CyNetwork?
resolution
It will be a viewmodel property, implemented with 'subsets'
Serialize VisualStyle, or result of applying it?
Currently (in 2.6.1) saving a network in xgmml and then reloading it will corrupt the VisualStyle: the VisualStyle that is reloaded turns all mappings into DiscreteMappings. Basically what is saved is not the VisualStyle, but the result of applying that VisualStyle. Should 3.0 do the same? (I think properly saving the VisualStyle instead should be possible. It might break upstream-xgmml compatibility, i.e. make 'cytoscape xgmml' a bit incompatible with the 'upstream xgmml' standard, but that already happens with allowing mixed networks and due to the fact that cytoscape uses bad default values in some cases.)
Would saving the result of applying the VisualStyle be usefull for compatibility? Are there non-cytoscape tools that can read the visual attributes Cytoscape includes? (I think the constants used for serializing look like they are non-cytoscape constants.)
resolution
Serialize the result (which is the viewmodel state)
Questions about possible new features:
Event-coalescence optimization
In the vizmapper GUI there was an optimization implemented which ignored events fired during session load. (The implementation had an 'ignore' boolean field which was set in the 'loading begins' event handler and cleared in the 'loading finished' event handler, and all other event handlers ignored events if it was set.) This should be implemented in a less ad-hock manner: whoever fires/initiates the events should be able to give hints to the event-handling framework like 'collect, don't fire events' and then 'fire all events collected so far'. The event firing framework should then be able to fire a single event instead of many small ones (for example, when loading a network, instead of firing an AddedNodeEvent for each node, it could fire a single AddedNodeEvent at the end. Of course this event will be more of a AddedNodesEvent, with a Collection<CyNode>getNodes(), for example.) I think this will be helpful to avoid problems like bug no. 1941 (http://cbio.mskcc.org/cytoscape/bugs/view.php?id=1941) especially since the events (as far as I can tell from the current code in core3/model/trunk/src/main/java/org/cytoscape/model/internal/ArrayGraph.java) are fired by the method that does the action, and not by the one that initiates the action. I.e. with the current code in core3/model, if I create a bunch of nodes, I will have to do that by calling CyNetwork.addNode() one-by-one, which will fire AddedNodeEvent one-by-one, which means I can't even do the "collect nodes to add and then add them in one go" trick suggested for fixing bug no. 1941.
Of course, such automatic event-coalescence might be very tricky to do right. For example, if one can subscribe to events of a single item, then events for a bunch of those items can't all be replaced with one event. (But such specific event listener subscriptions are not supported now.) If trying to implement something like this is deemed too risky, all events that can be mass-fired in usecases should / must support mass-actions (like being able to select a lot of nodes at once), so that "collect items to operate on and then do it in one go" optimizations are possible.
Note that doing event-coalescence hypothetically might defeat some sorts of possible parallelism in event handling (i.e. one processor loading the network while another network handling the AddedNodeEvent-s one-by-one), although I am quite suspicious such parallelism wouldn't provide much of a speedup.
resolution
Debated at mini-retreat; since then, many proposals were suggested, see RFC
supporting provenance-tracking?
Does the event-firing framework need to explicitly support provenance-tracking? Logging all the events that are fired would certainly capture a lot of information, but it might be too low-level.
How will the framework help make supporting provenance-tracking trivial? (Or how would it enforce that it is accuratelly done?)
If provenance-tracking is done in the Command layer, would that still be able to guarantee accuracy? I.e. would all plugins be aware of provenance tracking and would the correctness of all plugins be required for accuracy? Would we want to force all plugins to make modifications through a layer that would enforce provenance tracking? (How would this layer differ from the model layer, and why would it be seperate from it?)
resolution
Debated at second mini-retreat; will be discussed further.
Questions about implementation issues in pluggable-renderers:
Larger refactorings done in pluggable-renderers branch
Is everyone okay with the larger refactorings I have done in the pluggable-renderers branch? Since the 2.6.x architecture of some layers made further development really hard, I simplified and refactored it in some cases. This means that the pluggable-renderers branch contains not only changes related to pluggable rendering, but also changes which simply refactor existing functionality.
These larger refactorings are: (hopefully complete list)
- removing Appearance-layer: there was a complete layer of
NodeAppearance, EdgeAppearance, EdgeAppearanceCalculator, etc. classes between Mappings and NodeViews. Since it didn't seem to serve any usefull function, it just connected those two, I removed it all. (svn rev. r14617 and r14618)
Removing the idea of having a 'global current VisualStyle'. (svn rev. r15150)
fixing all cases where the name of VisualStyles are passed around instead of the VisualStyles themselves. (svn rev. r15161)
resolution
Since no-one objected, I assume these changes are acceptable.
DependentVisualProperty feature
Is everyone comfortable with the DependentVisualProperty feature? See on the pluggable-renderer page.
resolution
Since no-one objected, I assume this feature is acceptable.