Highlighing Selected Features

History and new developments

Highlighing selected features

The user clicks on a feature and that feature becomes the 'hot item' aka the selected feature and it is highlighted according to configuration. Some users prefer a single highlight colour which is defined in the ZMap [Window] section and if set this is used. If not then the 'selected colour' is taken from the features style. If no selected colour is defined then the normal colour is used and there will be no indication of focus on the display.

The selected column is also highlit via its background, using a window defined colour.

The window feature highlight colour only applies to the fill attribute and for small features or minimal zoom focus may not be visible. Using a global colour for focus has the advantage that it is easy to recognise, but the disadvantage that it could be similar to a feature's normal colour.

Multiple features may be selected by shift-click but this is restricted to features in one column. Selecting a feature in another column will deselect the existing ones. Features are referred to by a focus item list held in the window data.

Highlighting Evidence

There is a requirement to highlight all the features used as evidence to a given transcript and these may appear in several columns. As we wish to show these features as a group there is an argument that the same colour should be used for all, in which case adding a style colour for this would be wrong - this colour should be defined by the window config.

Another option would be to overlay the features with a stipple (similar to the mark). (A different bit map can be used). There is the disadvantage that this would obscure the features slightly, and if we choose a sparse bitmap than small features will not be highlit clearly.

We also wish to have focus continue to work on top of evidence highlights. Focus is displayed using the fill colour and if we show evidence using fill and border then both can be visible simultaneously (subject to features being big enough to show a fill colour).

Highlighting text

DNA and peptide sequences corresponding to selected features are highlit and currently this is handled independantly of the focus feature list.

Features used for the mask

Selecting a feature and then the mask results in that feature being stippled. This is implemented by adding an overlay item to the feature.
NB As we wish to simplify basic features it may be a better idea to add this feature to the block, as for the mark range overlays.

Handling multiple feature lists

Multiple highlit features will interact - removing a focus highlight will require us to redisplay a feature in normal or 'evidence' mode and having multiple data structres will require us either to have these interact internally or to have the application code operate all of them together, neither of which is a clean solution.

Extending the existing focus list to handle multiple independant groups of data looks like the best solution. Currently the focus data has a 'hot column' and a list of references to features in it. The following is proposed:

Further notes: use of this code

Multiple windows

As implemented the focus functions and data are window specific ie are part of the window, which makes sense in that the user inteaction is via a window. The user may have multiple windows open for the same data and there are callbacks used to update these other windows when focus items change. eg zmapView.c/viewSelectCB().

zmapView.c/zMapViewHighlightFeatures() is defined but not used.

zmapWindow.c and zmapWindowList.c call zMapWindowHighlightObject() when a feature is selected via user actions not including mouse.

zmapWindowItem.c includes the confusingly named zMapWindowHighlightObjects() zmapWindowHighlightObject() and zMapWindowHighlightObject() which between then handle highlighting groups of features eg those with the same name.

NB these functions are a focus specific interface and are not relevant to evidence highlighting.

Implications for evidence highlighting

The interface to focus highlighting is relatively clean but is specific to one window. Various actions result in the view callback being called and (some of?) these can be found by searching for caller_cbs->select. One of these is in zmapWindow.c/zMapWindowUpdateInfoPanel() (NB: the second call) which is called when items are highlighted eg via mouse action and this updates the focus items on other windows. A large data structure is constructed with details of the one feature implicated and this is passed further up the chain of callbacks to allow the feature info panel to be updated.

If we are to highlight evidence features for a transcript then we need to do this for all windows and the interface to this must be via the view. During development and testing this can be done on the current window but when driven by XML/ otterlace then we need to call a view function directly with a list of features.

Hide/show selected features

An option is provided to hide the focus items and redisplay them via DEL and shift-DEL. The features involved are stored in a list external to the focus code when hidden (using the foo canvas) (and removed from the focus data) and unhidden by the window code. It may make sense to re-implement this as by creating a new focus group such as WINDOW_FOCUS_GROUP_HIDDEN but as the current code is not complicated that has not been done.

When a column is not bumped then highlighting requires features to be moved to the front of the column's display list for them to be visible. When bumped this makes no difference and is not necessary but when combined with hide and show can result in unstable ordering of features. he problem to be solved is that of ensuring that the display list for a column remains in the same order regardless of bump state of highlight/ focus choice.

User interface

Hide and show selected features

Delete/ Shift Delete - hide/show features and rebump instantly
Control Delete/ Control Shift Delete - hide/show features and do not bump

Selecting features

Clicking on a feature will select and highlight that feature and remove any other highlights. Transcripts are selcted whole and alignments are grouped according to name.

Shift will cause a selection to accumulate and Control will select single features/ sub-features only (eg a single exon)

Selecting a feature in another column will cause previous selections to be lost.

Highlighting and unhighlighting

Originally highlit features were moved to the front of the foo canvas display list as this was the only way to ensure that they were visible, and their previous position used to put them back. This only works for single items and has been replaced with moving them to the bottom of the list. Arguably it would be better to leave them at the top and just un-highlight.

To achieve a stable display where items appear in the same place after being un-hidden it is necessary to replace items where they originally were. Here are some possible solutions:

Note that the last two of these imply that highlit features will be displayed twice, which will mean that the FToI hash will fail to find the original ones if the visible ones are clicked on. It would be nice to be able to have more than instance of a feature but ATM this looks like a lot of trouble.

So to keep things simple we will adopt the 'insert in place' strategy. This still generates an unstable display when items are hidden and redisplayed and the column is rebumped but it not too disturbing. The sorted insert ficntion is also not stable relating to items that sort in the same place.