SelectionModifiedSignal

There's a bunch of related bugs (852973, 857997, 865627) that are caused by the fact that the node editor does not respond by updating its own nodepath data and display when the object is modified outside of the node editor. There is simply no handler for the selection_modified signal in the node editor. When trying to add such a handler, bb ran into problems:

---

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.

---

Mental writes:

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 adds:

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

---

[bb] More concerns: Even if I fix selection_modified, this will not fix node editor, because when you're dragging a node, this signal is fired on each smallest mouse move. So if we update node display on each such signal, this will slow down dragging dramatically and even deselect the node being dragged (unless special action to restore selection is taken). So dragging a knot in the node editor itself must be somehow prevented from issuing this signal, or issue it within a block/unblock pair that will block the node editor's own handler (again, the feedback problem as recently discussed for the color picker).

JonCruz adds:

Actually, the problem with color picker events are not quite the same (as detailed under bug 859973). However, in working in this area a problem was noticed that might have some bearing on the edit problem. When a color was changed, it was being set twice, once by the color selector, and then again by a consuming widget. It turned out that the color selector would generate a change event that would be picked up by the paint selector. That would modify the style on the current element. In turn, that style modification would generate change events itself which would be detected by the paint selector. That, in turn, would the set the color in the color selector to a new value. Since all RGB components are float, but the style is only three 8-bit integer values, non-visible changes would propogate and double the events being generated.

In the case of the color selector, a simple fix was to ignore change events on the styles that did not actually result in any meaningful changes (ignore the event if the new RGBA 8-bit-each value would be the same as the old). This might be applied to other areas of the program as a general review of signal propogation and reducing unwanted 'noise' events.