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