SelectionModifiedSignal - Revision history

Kris: linkfix

2012-03-01T16:40:52Z

linkfix

← Older revision		Revision as of 16:40, 1 March 2012
Line 108:		Line 108:
	[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).		[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:		[[User:JonCruz\|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.		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.

Colin Marquardt: Reverted edits by Ix7Gbb (Talk); changed back to last version by GigaClon

2007-04-20T15:47:45Z

Reverted edits by Ix7Gbb (Talk); changed back to last version by GigaClon

← Older revision		Revision as of 15:47, 20 April 2007
Line 94:		Line 94:
	Try adding an assert to sp_selection_idle_handler -- selection->idle		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		should never equal 0 when the function is first entered (if it is, then
	there's a bug in your installed libgtk ).		there's a bug in your installed libgtk+).

	Another possibility is that one of the handlers for either the "modifed"		Another possibility is that one of the handlers for either the "modifed"

Ix7Gbb at 17:59, 11 April 2007

2007-04-11T17:59:50Z

← Older revision		Revision as of 17:59, 11 April 2007
Line 94:		Line 94:
	Try adding an assert to sp_selection_idle_handler -- selection->idle		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		should never equal 0 when the function is first entered (if it is, then
	there's a bug in your installed libgtk+).		there's a bug in your installed libgtk ).

	Another possibility is that one of the handlers for either the "modifed"		Another possibility is that one of the handlers for either the "modifed"

GigaClon at 17:56, 20 June 2006

2006-06-20T17:56:16Z

← Older revision		Revision as of 17:56, 20 June 2006
Line 108:		Line 108:
	[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).		[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]~~] Jon C~~] adds:		[[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.		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.

GigaClon: Categorization

2006-06-20T17:54:35Z

Categorization

← Older revision		Revision as of 17:54, 20 June 2006
Line 23:		Line 23:

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

Line 113:		Line 113:

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

			[[Category:Wiki Attic]]

Conversion script: link fix

2006-01-22T02:33:46Z

link fix

← Older revision		Revision as of 02:33, 22 January 2006
Line 23:		Line 23:

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

Line 108:		Line 108:
	[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).		[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 Jon C] adds:		[[[JonCruz]] Jon C] 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.		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.		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.

Simarilius: removing spam

2004-08-16T20:32:11Z

removing spam

New page

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 Jon C] 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.

Matiphas: Removal of "online casino" spam

2004-07-07T13:34:24Z

Removal of "online casino" spam

New page

Buliabyak: *

2003-12-25T09:48:01Z

← Older revision		Revision as of 09:48, 25 December 2003
Line 1:		Line 1:
	There's a bunch of related bugs (852973, 857997) 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:		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:

	-----		-----

Buliabyak: *

2003-12-11T23:00:30Z

New page

There's a bunch of related bugs (852973, 857997) 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).