2007/1/24, bulia byak <buliabyak@...400...>:
On 1/24/07, Aron Stansvik <elvstone@...400...> wrote:
My first question is how would you want this feature to work? There are two approaches that I can see:
- Inputs in node editing tool bar
- Values are updated while dragging a node?
- Values are updated when a node is released after dragging?
- Inputs in a dialog
- Dialog is shown when double clicking a node?
- Dialog is shown by pressing a button in the tool bar?
After mentioning this on IRC, it seems the first approach is the favored one. So a couple of questions regarding this approach:
Certainly the controls bar (= toolbar) is the way to go. We try to avoid adding new dialogs if possible.
Here's the corresponding RFE:
https://sourceforge.net/tracker/?func=detail&atid=604309&aid=865050&...
where you can find some discussion on what to display when more than one node is selected.
- What's the best way to make the node editing tool bar aware of what
goes on in nodepath.cpp (node selected, moved, N of selected nodes et.c.). Can I fire off signals and the tool bar will see them? The approach that the select tool bar uses to get notified of object modifications does not really seem to work for this (though I'm not sure).
The selector just listens to the object selection's changed and modified signals. This indeed won't work with node tool, because node selection is completely independent of object selection. Object selection is global and is always there, regardless of which tool you are in; node selection is only active in node tool and shuts down when you switch to another tool. If you listen to object selection changes, you will get notified when a node is moved (because that changes the path object, which is selected, and therefore fires the selection-changed signal) but you won't get any notification when a node is selected or deselected.
Right.
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.
A simpler approach would be to do away with any signals and just access the toolbar directly from nodepath or node-context. It's been done for example in Calligraphic tool: when you press left/right arrow keys, the calligraphic context processes the keystrokes, digs out the corresponding spinbutton on the toolbar (by its associated data string), and updates it directly. But this might get a little too messy for a more complex case such as the coordinate controls.
Yea, sounds like a backwards way of going about it.
- Is it really important that the input values are updated _while_
dragging a node (like with object dragging), and not when dragging stops? (Latter seems easier to implement).
It is much better to see the spinbutton updated while you drag, because it allows you to drag a node to a precise position in one go, without several drag-and-drop attempts. It will also be more consistent with the Selector toolbar.
Ah, very true.
Thanks a lot for the information. It has given me some new angles to work with. I didn't find that RFE when I first searched, probably because I used the keyword "numerical" instead of "coordinate", I'll check it out.
Regards, Aron