(Sorry if this comes in several copies, I'm having trouble sending to the list)
I just did a temporary hack: now sp_document_undo emits the selection_changed signal. The node editor catches it and redraws the path. This fixes bug 848355 for now. As an unwanted side effect, selected nodes are deselected after an undo. A better solution would require figuring out what's up with selection_modified signal and using it instead (see my previous mail - attached below).
On the bright side, today I implemented duplicate node in node editor (shift-d). As a regular duplicate object (ctrl-d), it places the new node(s) exactly over the previously selected ones (and selects the new node(s) instead). By using together with Tab and Ctrl-a, this makes possible some nice keyboard-only effects. Here are some ideas for eyecandy screenshots for 0.36:
- create a filled star with about 30 rays, press ctrl-shift-c, F2, ctrl-a, shift-d, some arrow keys (maybe with shift)....
- create a spiral with about 30 revolutions, ctrl-shift-c, F2, ctrl-a, shift-d, some arrow keys...
Also, I fixed shift-b (break nodes) so that it breaks all selected nodes and only selects one end of each break (previously it selected both ends). So you can add more fun to the above examples by pressing shift-b, some arrow keys, then ctrl-a again, shift-d, more arrow keys, etc.
More usefully, this allows to easily "draw" with keyboard. Use tab to move to the end node of an unclosed path and go like this: shift-d, arrows, shift-d, more arrows, etc. It's an easy way to create rectangular shapes, very useful for diagrams.
So what remains in node editor is implementing the []<> keys to edit control points, and voila - a totally keyboard-driven path editor! Something I've dreamed about for long, but did not see to date in any vector editor.
P.S. Looks like my previous mail was lost, here it goes:
Does anyone have an idea why sp_selection_idle_handler in selection.c is constantly emitting the "selection modified" signal - even two signals, one on the selection and the other on the inkscape object???
There is indeed a constant flood of these signals even when absolutely nothing is happening, not even a mouse move.
Is this by design? I'm sure there must be a better way. I was investigating why undo and XML-editor changes in node edit do not work, and found that nodepath context lacks any callback that would update the path when its repr has changed. I tried to hook it up to the "modified" signal but that rendered the program unusable because that signal is "always on" like white noise.
Can someone share any insights? It seems to me that something is seriously broken here. I think that it's the repr subsystem that must issue a signal when the document is changed, but that subsystem apparently emits no signals whatsoever.
_________________________________________________________________ Don�t worry if your Inbox will max out while you are enjoying the holidays. Get MSN Extra Storage! http://join.msn.com/?PAGE=features/es