• handle multiple types of selections: POINT, LINE, CIRCLE, RECT, OVAL, POLY, LASSO
• draw overlays for selections
• hittest against renderers' data
• render selected/non-selected glyphs differently according to policies
• be able to combine disjoint selections (e.g. ctrl-click in listboxes)
• execute selection callbacks

• that happen continuously (every mouse event)
• that only happen when a selection is "final"

Selection: list of indices into data source

Selection Geometry: object that describes a region to hittest. Has a type, and whatever attributes are appropriate for that type. All coordinate and measures are in screen space/units. Examples:

Selection Highlight Policy: functions that accept a glyphspec and return a new glyph spec. For example, a policy to dilate the size of glyphs might be defined:

  dilate = (factor, attr="size") ->
    return (glyphspec) ->
        new_spec = _.clone(glyphspec)
        new_spec[attr] *= factor

Also can just be new glyphspec to replace default spec with wholesale.

Glyph Renderer: holds data for glyphs, as well as current selections. Responsible for:

• carrying out hittest, given a selection geometry
• rendering glyphs using selection/non-selection policies as appropriate

Selection Overlays: renderers that draw boxes, ploys, etc on top of plot. Used by selection tools.

Selection Tool: handles mouse/key/touch events

• construct appropriate selection geometry from user interactions
• update selection overlays with new geometry
• update selection manager with new geometry

Selection Manager: registers selection callbacks on glyph renderers. Responsible for:

• hittest glyph renderers against selection geometries supplied from tools
• handles appending/replacing existing selection as needed
• update the glyph renderers' selections
• execute callbacks when appropriate

• propose to use RTree.js as an efficient spatial index for bounding boxes of data items

• question: data-space or screen-space? Probably either, depending on the situation...

• Should tools/overlays be made plot-independent? i.e. should one pan tool be able to service multiple plots? (Question motivated by grid plot case.)
  • Yes. --peter
• Should selections themselves be more than just lists of indices? Oftentimes an index range, or a list of index ranges, can be the most compact, and the client side can do in-out testing against those just as easily, especially if there was a way to communicate when index ranges are non-overlapping and monotonically increasing. (Actually, overlapping isn't even a problem, from an implementation standpoint.)