On 1/25/07, Aron Stansvik <elvstone@...400...> wrote:
2007/1/24, bulia byak <buliabyak@...400...>:
Sure, you will need to create new signals fired by the nodepath and listened to by the node toolbar. However, it's made more difficult by the fact that the toolbar stays always on (it's just hidden and shown when you switch tools) but nodepath is launched and shut down every time you switch to Node tool and back. So you'll need to emit the signal from something that's always on, most appropriately the SPDesktop, not from nodepath (i.e. nodepath would just call a SPDesktop method for emitting the signal). But even then, you can't send all the information that the toolbar needs with a signal. You will still need to create query methods on nodepath that the toolbar would use to get the actual coordinates etc. That is probably the most correct way to implement this.
Okay. Correct is what I'm after. Thanks for clearing some things up.
One thing I didn't think of yesterday: There's already a similar signal issued by SPDesktop (and retransmitted by the global Inkscape object for dialogs which do not belong to any single desktop): it's called subselection_change. It is intended to reflect a change in some "subselection", i.e. tool-specific secondary selection while the regular object selection remains the same. Currently subselection is used when you change text selection (i.e. shift+arrows or mouse drag over text) in Text tool and when you select one or more gradient handles in Gradient tool. So, in principle, you can reuse this signal for the node selection changes too, at least it would be consistent.
However, so far the primary function of the subselection_change signal has been to track style changes in parts of the selection, i.e. color/opacity of gradient stops and the style of fragments of text in a text object. When a widget (such as selected style indicator at the left side of the statusbar) or dialog (such as Fill&Stroke) gets this signal, it runs a query on the desktop, which causes the desktop to emit a query_style signal. Subselections are supposed to listen to this signal and, when they get it, and when the queried style properties apply to them, return the style of the subselection which would be then displayed by the querying widget/dialog.
However, since a path node cannot conceivably have a style of its own, nodepath need not listen to the query signal at all. If no subselection answered the query, SPDesktop just retuens the style of the selected objects. So, if you reuse the subselection_change signal, each selecting or deselecting of a node in Node tool will cause all style-displaying widgets to requery the style and the SPDesktop to return the style of the selected object to every of them. That's the price to pay for consistency :) Even if useless, I don't think it will be too bad. Just make sure that when you do bulk changes in node selection (such as Ctrl+A to select all nodes), you emit the subselection_change signal only once at the end, and not for every node.
On still another hand, when we have Path Effects implemented, one of the effects would be a variable-width stroke built from a given path as "skeleton" and an array of widths. It is logical to allow the node tool to edit the skeleton path when such a shaped stroke is selected. But then, the notion of a "style of path node" will suddenly make sense for at least one property: stroke width. That is, you will be able to select a node, see its associated stroke width in all style-displaying widgets, and set it back _on that node only_ exactly in the same way as you do now for the entire stroke. That will be the triumph of consistency :)
So, to summarize, I think it makes sense to just fire the existing subselection_change signal for node selection changes and make the node toolbar listen to it. Hope this makes sense, feel free to ask anything that's unclear.