On 1/25/07, Aron Stansvik <elvstone@...400...> wrote:
Alright. Question; do you think it would make sense to make a sister signal to subselection_changed called subselection_moved, or should I reuse the subselection_changed signal for this purpose also? Having all style-displaying widgets to requery the style during dragging of nodes sounds not so good.
Yes, absolutely. For regular selection, we have two signals: _changed means that the scope of selection has changed; and _modified means that one of the selected objects was modified in some way (the names aren't too obvious, but this is what we inherited from Sodipodi). For subselection, so far there was only one signal because I was only interested in style changes and scope changes and treated them the same. But obviously the right way to do it is to use three signals:
_changed: the scope of selection has changed
_transformed: subselection or part of it was affine-transformed without changing style
_modified: subselection or part of it was modified in some other way (most likely by assigning style)
Then, the style displaying widgets would only listen to _changed and _modified, and the node toolbar would only listen to _changed and _transformed.
There are not too many emitters and listeners to subselection signals so far, so it should be easy to make this change consistently everywhere.
Note that you'll also need to create corresponding retransmission signals in inkscape.cpp. The only technical difficulty is that SPDesktop signals are sigc++ signals while inkscape.cpp uses the old-style GObject signals; hope you can sort them out :)