How can I keep track of objects being removed from the selection ?
[ I have been digging through the desktop.cpp/inkscape.cpp/selection.cpp files and couldn't find any noteworthy construct that let me do it. ]
Also, if I bubbled up signal emission, how can that be achieved ? If widget A contains B which contains C. So I want "released" signal of A to be invoked when "released" signal of C is invoked. How can I do that ?
On 09/21/2013 03:36 PM, Arshdeep Singh wrote:
How can I keep track of objects being removed from the selection ?
[ I have been digging through the desktop.cpp/inkscape.cpp/selection.cpp files and couldn't find any noteworthy construct that let me do it. ]
In my connector-wip branch [0] I added a "selected" signal to SPObject. This could be used for that purpose.
Sebastian
[0] https://code.launchpad.net/~h-e-6/inkscape/connector-wip
2013/9/21 Sebastian Götte <jaseg@...2974...>:
On 09/21/2013 03:36 PM, Arshdeep Singh wrote:
How can I keep track of objects being removed from the selection ?
[ I have been digging through the desktop.cpp/inkscape.cpp/selection.cpp files and couldn't find any noteworthy construct that let me do it. ]
In my connector-wip branch [0] I added a "selected" signal to SPObject. This could be used for that purpose.
As I mentioned some time ago, this is a very bad idea. It would be better to add this signal on the Inkscape::Selection object. Adding a "selected" signal to SPObject introduces UI functionality into the SP tree, which is a design error.
Regards, Krzysztof
On 09/22/2013 12:04 AM, Krzysztof Kosiński wrote:
2013/9/21 Sebastian Götte <jaseg@...2974...>:
On 09/21/2013 03:36 PM, Arshdeep Singh wrote:
How can I keep track of objects being removed from the selection ?
[ I have been digging through the desktop.cpp/inkscape.cpp/selection.cpp files and couldn't find any noteworthy construct that let me do it. ]
In my connector-wip branch [0] I added a "selected" signal to SPObject. This could be used for that purpose.
As I mentioned some time ago, this is a very bad idea. It would be better to add this signal on the Inkscape::Selection object. Adding a "selected" signal to SPObject introduces UI functionality into the SP tree, which is a design error.
I disagree. The interesting action is the selection change of a particular object. To introduce a global signal covering any selection changes and then filtering for a single object is not the right way to solve this. The object itself is the natural place to "bounce" this signal between the listener and the emitter.
Introducing this kind of UI code into the SPObject tree is not problematic by itself as long as it is only used by UI code.
Sebastian
2013/9/22 Sebastian Götte <jaseg@...2974...>:
I disagree. The interesting action is the selection change of a particular object. To introduce a global signal covering any selection changes and then filtering for a single object is not the right way to solve this. The object itself is the natural place to "bounce" this signal between the listener and the emitter.
Inkscape::Selection should have two additional signals: "added" and "removed", which would include the relevant SPObject as a signal parameter. This is far better than adding references to UI code in the SP tree.
Introducing this kind of UI code into the SPObject tree is not problematic by itself as long as it is only used by UI code.
If this signal is included, it will not be possible to compile the SP tree code to a separate library, because it will reference Inkscape::Selection. (I'm aware this is not yet possible at present, but that's something we should eventually plan for.)
Regards, Krzysztof
On 09/22/2013 02:07 AM, Krzysztof Kosiński wrote:
2013/9/22 Sebastian Götte <jaseg@...2974...>:
I disagree. The interesting action is the selection change of a particular object. To introduce a global signal covering any selection changes and then filtering for a single object is not the right way to solve this. The object itself is the natural place to "bounce" this signal between the listener and the emitter.
Inkscape::Selection should have two additional signals: "added" and "removed", which would include the relevant SPObject as a signal parameter. This is far better than adding references to UI code in the SP tree.
No, it is not. If I am interested in the selection status of a single SPObject (say, a Point), I do not want to listen on and filter *any* selection changes *globally*. If I am interested in events concerning a specific object, the correct place for that information is the object.
The only option to emulate this behavior from within Inkscape::Selection would be to have a hash map mapping objects to sigc::connections and looking them up on every selection change.
Introducing this kind of UI code into the SPObject tree is not problematic by itself as long as it is only used by UI code.
If this signal is included, it will not be possible to compile the SP tree code to a separate library, because it will reference Inkscape::Selection. (I'm aware this is not yet possible at present, but that's something we should eventually plan for.)
SPObject now contains one additional signal (via one sigc::signal field, a connectFoo method and an emitFoo method). With just a forward declaration of Inkscape::Selection for the signal parameter (Inkscape::Selection*) this compiles without any UI code. In fact, this forward declaration already is part of sp-object.h and since the two lines of signal logic are inside sp-object.h this already compiles without UI code in all the places where sp-object.h is included without UI thing being included, too.
Sebastian
On Sun, 2013-09-22 at 10:22 +0200, Sebastian Götte wrote:
No, it is not. If I am interested in the selection status of a single SPObject (say, a Point), I do not want to listen on and filter *any* selection changes *globally*. If I am interested in events concerning a specific object, the correct place for that information is the object.
I agree that signals about selected or unselected are pertinent to the object. Where are signals about the selection collection are not, like adding to or removing from the collection.
If we don't have a signal for selected and unselected for objects, we should add one.
Martin,
If we don't have a signal for selected and unselected for objects, we should add one.
Should I wait for this being implemented or should I go ahead with Sebastian's addition ?
On Sun, Sep 22, 2013 at 6:01 PM, Martin Owens <doctormo@...400...> wrote:
On Sun, 2013-09-22 at 10:22 +0200, Sebastian Götte wrote:
No, it is not. If I am interested in the selection status of a single SPObject (say, a Point), I do not want to listen on and filter *any* selection changes *globally*. If I am interested in events concerning a specific object, the correct place for that information is the object.
I agree that signals about selected or unselected are pertinent to the object. Where are signals about the selection collection are not, like adding to or removing from the collection.
If we don't have a signal for selected and unselected for objects, we should add one.
Martin,
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2013-09-22 at 19:03 +0530, Arshdeep Singh wrote:
Should I wait for this being implemented or should I go ahead with Sebastian's addition ?
It looks like Sebastian's already done the work. But I'd like to make sure there's an unselected signal too. For consistency. Would it be much work to add (it doesn't seem like it, but that depends I think)
Martin,
On 09/22/2013 04:01 PM, Martin Owens wrote:
On Sun, 2013-09-22 at 19:03 +0530, Arshdeep Singh wrote:
Should I wait for this being implemented or should I go ahead with Sebastian's addition ?
It looks like Sebastian's already done the work. But I'd like to make sure there's an unselected signal too. For consistency. Would it be much work to add (it doesn't seem like it, but that depends I think)
The change is only about 15 lines, alas I think I did not give it its own commit. I made only one signal with a bool argument for selected/unselected.
Sebastian
On 22-9-2013 0:57, Sebastian Götte wrote:
On 09/22/2013 12:04 AM, Krzysztof Kosiński wrote:
2013/9/21 Sebastian Götte <jaseg@...2974...>:
On 09/21/2013 03:36 PM, Arshdeep Singh wrote:
How can I keep track of objects being removed from the selection ?
[ I have been digging through the desktop.cpp/inkscape.cpp/selection.cpp files and couldn't find any noteworthy construct that let me do it. ]
In my connector-wip branch [0] I added a "selected" signal to SPObject. This could be used for that purpose.
As I mentioned some time ago, this is a very bad idea. It would be better to add this signal on the Inkscape::Selection object. Adding a "selected" signal to SPObject introduces UI functionality into the SP tree, which is a design error.
I disagree. The interesting action is the selection change of a particular object. To introduce a global signal covering any selection changes and then filtering for a single object is not the right way to solve this. The object itself is the natural place to "bounce" this signal between the listener and the emitter.
Introducing this kind of UI code into the SPObject tree is not problematic by itself as long as it is only used by UI code.
Can you explain to me, for what functionality do you need the "selected" signal?
regards, Johan
On 09/23/2013 11:03 PM, Johan Engelen wrote:
On 22-9-2013 0:57, Sebastian Götte wrote:
On 09/22/2013 12:04 AM, Krzysztof Kosiński wrote:
2013/9/21 Sebastian Götte <jaseg@...2974...>:
On 09/21/2013 03:36 PM, Arshdeep Singh wrote:
How can I keep track of objects being removed from the selection ?
[ I have been digging through the desktop.cpp/inkscape.cpp/selection.cpp files and couldn't find any noteworthy construct that let me do it. ]
In my connector-wip branch [0] I added a "selected" signal to SPObject. This could be used for that purpose.
As I mentioned some time ago, this is a very bad idea. It would be better to add this signal on the Inkscape::Selection object. Adding a "selected" signal to SPObject introduces UI functionality into the SP tree, which is a design error.
I disagree. The interesting action is the selection change of a particular object. To introduce a global signal covering any selection changes and then filtering for a single object is not the right way to solve this. The object itself is the natural place to "bounce" this signal between the listener and the emitter.
Introducing this kind of UI code into the SPObject tree is not problematic by itself as long as it is only used by UI code.
Can you explain to me, for what functionality do you need the "selected" signal?
In the connector context, SPPoints are rendered through ControlPoints (square handles). When the SPPoint is selected, the handle's display style needs to be updated. I am using the signal since there are many ways to select a SPPoint (clicking, keyboard shortcuts, Redo/Undo, XML editor etc.) I opted for a signal from SPObject.
Sebastian
participants (5)
-
Arshdeep Singh -
Johan Engelen -
Krzysztof Kosiński -
Martin Owens -
Sebastian Götte