Selection In Regions

Proposal: Selection In Regions

We currently allow multiple regions with different node and element namespaces, but there is only one global list of selected elements, nodes and as a special case (until we Remove Special Data Regions), data.

It is not possible to select both node 1 from region A and node 1 from region B, but due to the selection storing nodes by index, it may contain a list of nodes from any region, just no two with the same identifier. Under certain circumstances all nodes with the same identifier will be highlighted. Functionality such as editing nodes from multiple regions generally fails (see http://www.cmiss.org/cmgui/tracker/619).

It is proposed that a selection object be created and attached to each region in the hierarchy. This object is responsible for maintaining the list of selected objects (nodes, elements, element-points) within that region. Sub-regions handle their own selection.

It is further proposed that each instance of a region has a flag indicating whether it is selected as a whole. The root_region is also selectable.

The selection hierarchy will often need to work as one entity. An example is that clearing the selection in the root_region clears all selections below it. Clients should be able to get notification of changes within a whole hierarchy by requesting from the top region.

Note: Many ideas listed here require small changes to the objects making up the region hierarchy, which I will discuss in Merge Regions And Scenes.

17. How do selection objects get created and added through the hierarchy?

The first selection object is added to the root_region and it requests notification of region changes. When a new child region is added it creates a new selection object for it, and so on, ensuring selection objects are present across the hierarchy. Selection objects are destroyed with the containing region.

An alternative implementation is for the object making up the representation of a region (currently just the FE_region) to take care of selection of its own objects.

17. How are groups (regions whose nodes and elements belong to a master region) handled?

These share node and element selection information with the master FE_region, as would two Cmiss_regions referencing the same FE_region.

17. If a region is selected, are its sub-regions also selected?

No, only the representation (FE_region, rendition, other relationships) of the region instance is selected. Each entity with a selection object is responsible for its own selection. We can provide methods to select all regions in a hierarchy to apply operations to all of them. We are also free to make some operations work hierarchically from the selected regions.

17. What changes are needed to the node viewer dialog?

With minimal change it will be no worse than now if it just follows the selection for the root_region. To fix it properly it requires a region path chooser, and the ability to receive hierarchical selection changes (see below).

17. How do we set and communicate hierarchical selection?

Need to be able to request and get selection changes for a region hierarchy.

Implementation concept: the entity making the selection builds up a transaction containing selection changes across the hierarchy, order possibly important. On committing into the top region's selection object, the changes are merged and clients are notified, passing along the latest changes (as originally received) should a client need them in addition to the current selection.

Any other implementation ideas?

17. Are any other changes needed?

Changes are needed wherever selection is used. Most will require a small change to work as well as they do now with the root_region, and more change to work with the whole hierarchical selection.

Feedback

Please add any feedback here.