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.
I also changed the UI a lot to make it possible to reconnect connectors. SPPoints are now created by shift-clicking into the document while the selection is empty. If the selection is not empty, shift-click toggles the selection of the object under the cursor. Control-click should work as expected with groups. Connectors are terminated by clicking on the end point or somewhere in empty space (in which case a new SPPoint will be created on the clicked location).
Sometimes stray points still appear because I have not yet found out how to delete SPPoints without crashing Inkscape. I am working on that.
Connector deletion appears to work now. SPPoint deletion still has its issues. After deleting a SPPoint, Inkscape crashes with ominous memory corruption errors. I was unable to find the cause of that so far. I will push a commit later that allows easy reproduction of this.
Sebastian
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.
Regards, Krzysztof
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
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
participants (2)
-
Krzysztof Kosiński -
Sebastian Götte