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.

Q. 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.

Q. 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.

Q. 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.

Q. 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).

Q. 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?

Q. 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.

comments:

What is meant by "selection" --rbritten, Thu, 17 Jan 2008 21:38:46 +1300 reply
I'm assuming by selection you mean when a user interactively mouse-clicks on or lassoes nodes and elements, often when planning to edit their spatial location them by dragging them around.

What is meant by "selection" --andre, Thu, 17 Jan 2008 21:59:20 +1300 reply
Isn't selection a bit more general than that? More a general concept for defining a subset of a region (or spanning multiple regions) to which you want to apply a specific operation, maybe? Programmatic selection is just as useful for this as interactive/graphical selection, especially when wanting to select nodes, for example, based on conditions defined by computed fields (pretty sure I've done that in the past).

selection is a special group or region --blackett, Mon, 21 Jan 2008 14:15:46 +1300 reply
It seems that the selection (for nodes and elements anyway) is a special group or region. If we could combine the concepts then many things that require multiple different options could be combined. For example, to write the selected nodes, I think you currently have to make a group and add selected (and I don't know what happens if they are not groups but actual regions), Most of the other commands support both "selected" and "group or region"

selection identifier lists --blackett, Mon, 21 Jan 2008 14:22:46 +1300 reply
I find working with the identifier multiranges an unnatural sort of list. It is useful to be able to succinctly describe a list of objects which contains a few differences to the whole set, but maybe we could have a list class that has a normal iterator interface but knows that it is all the nodes in the region minus some specifics or so on.