On Thu, 2003-12-04 at 16:25, bulia byak wrote:

(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).

I think for now unselecting the nodes is acceptable.

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.

Nice~

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.

oooh~~~

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???

Hmm... I will have to look into that. It should not ever be doing that.

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.

Though SPRepr provides "signals" for notification when individual nodes change, there is no mechanism to recieve notification for overall document changes.

However, with the addition of the transactions code, it would not be very hard to implement if you wanted it.

SPRepr itself doesn't use GObject signals at present -- SPReprs maintain lists of SPReprEventVectors (added via sp_repr_add_listener), which are used to specify callbacks when something changes.

Here are the current callbacks in an event vector (they may be NULL):

void (* destroy) (SPRepr *repr, void * data);

Called when the repr is destroyed.

unsigned int (* add_child) (SPRepr *repr, SPRepr *child, SPRepr *ref, void * data);

Called before a child is added; the handler can return FALSE to veto the addition. ref is the child after which the new child is to be added.

void (* child_added) (SPRepr *repr, SPRepr *child, SPRepr *ref, void * data);

Called once a child has been added.

unsigned int (* remove_child) (SPRepr *repr, SPRepr *child, SPRepr *ref, void * data);

Called before a child is to be removed; it may veto the removal by returning FALSE. ref is the child before the child to be removed.

void (* child_removed) (SPRepr *repr, SPRepr *child, SPRepr *ref, void * data);

Called after a child is removed; ref is the child that used to precede the removed child.

unsigned int (* change_attr) (SPRepr *repr, const gchar *key, const gchar *oldval, const gchar *newval, void * data);

For Element nodes. Called before an attribute is changed; can veto by returning FALSE.

void (* attr_changed) (SPRepr *repr, const gchar *key, const gchar *oldval, const gchar *newval, void * data);

Called after an attribute has been changed.

unsigned int (* change_content) (SPRepr *repr, const gchar *oldcontent, const gchar *newcontent, void * data);

For Text nodes. Called before an element's content is changed; can veto by returning FALSE.

void (* content_changed) (SPRepr *repr, const gchar *oldcontent, const gchar *newcontent, void * data);

Called after an element's content has been changed.

unsigned int (* change_order) (SPRepr *repr, SPRepr *child, SPRepr *oldref, SPRepr *newref, void * data);

Called before a child of repr is rearranged in its list of children. oldref is the child currently preceding the child; the child will be moved to the position after newref. Can veto by returning FALSE.

void (* order_changed) (SPRepr *repr, SPRepr *child, SPRepr *oldref, SPRepr *newref, void * data);

Called once the child has been moved to its new position in the child order.

NOTE!!!!! the veto callbacks are currently not useful because some functions SPObjects register for callbacks have side-effects -- by the time the veto was made, other callbacks might already have modified things...

(Although it wasn't seen as a problem in Sodipodi, this is on my personal list of things to fix...)

-mental

On Thu, 2003-12-04 at 16:25, bulia byak wrote:

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.

Try adding an assert to sp_selection_idle_handler -- selection->idle should never equal 0 when the function is first entered (if it is, then there's a bug in your installed libgtk+).

Another possibility is that one of the handlers for either the "modifed" signal of the SPSelection, or the "selection_modified" signal is actually modifying one of the selected objects.

Try moving the assignment selection->idle = 0 until after both signals have been sent. If that prevents the idle handler from being run constantly, that is your problem...

-mental