On 08/30/2013 04:41 PM, Krzysztof Kosiński wrote:
2013/8/23 Sebastian Götte <jaseg@...2974...>:
Hi, this week I changed the SPPoint selection to use Inkscape's normal selection mechanics instead of the control-point-selection.cpp. This has the advantage that selecting points and connectors at the same time is not quite as bad a hack as it would be otherwise.
Doing this I introduced a new signal for selection/deselection in SPObject.
Sorry for commenting that late, but couldn't this be done using the already existing signals on Inkscape::Selection?
In future we could have multiple selections per document (which would be used to pass sets of objects to scripted commands), not only the single one associated with the SPDesktop, and introducing this kind of dependency between the GUI and the object tree is a bad idea.
I agree in part, I am not completely satisfied with this solution either.
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.
I am only using the object as a proxy for the signal here since the ControlPoint *is* tightly coupled to the object tree.
Sebastian