2013/8/31 Sebastian Götte <jaseg@...2974...>:
I am using the new signal to couple the SPPoint's selection status to the ControlPoint it is represented by. The ControlPoint only needs to listen to selection status changes from a single object. This would be possible using the selection's "modified" signal, but this would require every ControlPoint on the screen to *search* the whole selection for its current status (selected/unselected). The way through SPObject means the selection change is propagated only to the affected control point *through* the object (SPPoint in this case). This should also handle multiple selections just fine with one more if clause since the signal has the emitting selection as one argument. The code would just need to compare that against desktop->selection to distinguish it from changes originating from auxiliary selections.
Instead of introducing the notion of selection into the SP tree, where it absolutely does not belong, the better way to solve it is to change the internal data structure of Inkscape::Selection. Currently it contains a GSList, but it should be changed to a combination of std::list and std::unordered_set, essentially something like Java's LinkedHashSet. This way 'searching' the list of items would take O(1) time and the information about selection order, needed e.g. for the Align and Distribute dialog, would still be preserved. This would also speed up many current operations which indeed do search the list of selected objects, for example clone moves.
Regards, Krzysztof