(note: this page is simply some ideas collected by DanielAbel, it does
not signify a consensus among cytoscape developers; feel free to edit
or comment.)

== The Idea ==

current (i.e. <3.0) cytoscape has a primary selection (nodes colored
yellow, by default) and a 'reverse selection' (those nodes that are
selected in AttributeBrowser; by default green).

The idea came up during CytoscapeRetreat2008 that having multiple
selections could be useful.

== Current usage ==

Currently selection is used in the following ways:

 1. quick grouping (marking a sub-group of nodes in the network); For
   example, some clustering plugins (MCODE, etc.) use it like this, in
   addition, the 'reverse selection' can be used like this from the
   AttributeBrowser (sort in browser according to some numerical
   attribute, select highest or lowest n nodes, check in graph view
   how that correlates with network structure)

 2. Marking the nodes to run an operation on (moving nodes, etc.); only
   the 'primary selection' is used like this.

   This is occasionally used by plugins to refresh some other view:
   selecting some nodes might automatically update some other widget
   showing some attributes of those nodes.


At least one plugin was mentioned during CytoscapeRetreat2008 (I think
it was GLay, by Gang Su) that creates and manipulates a VisualStyle
instead of the selection in order to allow it to be used with other
clustering plugins (MCODE). (So that the clusters identified by GLay
can be compared with the clusters identified by MCODE)

Having a single selection allows easy synchronisation of selected
state, which might be useful for different plugins to
inter-operate. (For example having clustering plugins which allow
selection of a cluster on one widget, and select the nodes of that
cluster in the main view; interoperate with a plugin that shows
attributes about sub-group of nodes, for example how homogeneous they
are. In this case having a single selection means that these two
plugins can naturally work together seamlessly.)

On the other hand, for other types of plugins, having separate
selections would be better. (Comparing clusters created with different
clustering plugins.)

== Open Issues ==

Apparently, in 3.0, selection will be an attribute and will be less
hard-coded in the model or view; thus, having an arbitrary number of
selections will be possible. The real questions are:

 * how is selection status shown? (what happens for overlapping
   selections?) -- node color might not be the best idea, showing
   selection as node border might be easier and better. The node
   border could show multiple selections by allowing several borders
   around each node (sort-of "rainbow border").

 * How can the user select which selections to sync and which to keep
   separate? I.e. how to avoid losing the advantages of shared
   selections?  (one possibility is to allow plugins to define
   selections they want to use and have a widget where the user can
   select which of these are to be the same; I.e. a clustering plugin
   would have a 'shown-cluster' selection, another plugin could have a
   'analyse-homogenity-subgroup' and the user could set both to be
   'focus group 1' thereby specifying that he wants these two to be
   synced.)

== Terminology ==

Using 'focus group' instead of 'selection' might be better, to avoid
confusion. (And the default graph view would have a focus group called
'selection' which is the nodes and edge selected by the user.)