EventContextGrab - Revision history

Romain2Boss at 11:27, 25 August 2013

2013-08-25T11:27:29Z

← Older revision		Revision as of 11:27, 25 August 2013
Line 1:		Line 1:
	As first discussed in [[InkscapeTamed]], keyboard events are sent to the event context handlers (both global in event-context.c and tool-specific e.g. select-context.c) ONLY when the mouse is over the canvas.		As first discussed in [[InkscapeTamed]], keyboard events are sent to the event context handlers (both global in event-context.c and tool-specific e.g. select-context.c) ONLY when the mouse is over the canvas.

	Simple experiment: move a shape by arrows. This works while the mouse cursor is over the document window but stops as soon as you move mouse away from it, even if the document window still has focus. Global verbs like + and - and ctrl-q always work. We cannot however make tool-specific shortcuts global verbs.		Simple experiment: move a shape by arrows. This works while the mouse cursor is over the document window but stops as soon as you move mouse away from it, even if the document window still has focus. [[Verb\|Global verbs]] like + and - and ctrl-q always work. We cannot however make tool-specific shortcuts global verbs.

	* Mental writes:		* Mental writes:

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

2007-04-20T15:46:44Z

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

← Older revision		Revision as of 15:46, 20 April 2007
Line 1:		Line 1:
	As first discussed in [[InkscapeTamed]], keyboard events are sent to the event context handlers (both global in event-context.c and tool-specific e.g. select-context.c) ONLY when the mouse is over the canvas.		As first discussed in [[InkscapeTamed]], keyboard events are sent to the event context handlers (both global in event-context.c and tool-specific e.g. select-context.c) ONLY when the mouse is over the canvas.

	Simple experiment: move a shape by arrows. This works while the mouse cursor is over the document window but stops as soon as you move mouse away from it, even if the document window still has focus. Global verbs like and - and ctrl-q always work. We cannot however make tool-specific shortcuts global verbs.		Simple experiment: move a shape by arrows. This works while the mouse cursor is over the document window but stops as soon as you move mouse away from it, even if the document window still has focus. Global verbs like + and - and ctrl-q always work. We cannot however make tool-specific shortcuts global verbs.

	* Mental writes:		* Mental writes:
Line 17:		Line 17:
	I cannot make it work. I added		I cannot make it work. I added

	gtk_widget_grab_focus (		gtk_widget_grab_focus (&(dtw->canvas->widget));

			into sp_desktop_widget_new in desktop.c. For debugging, I also added

			gtk_signal_connect (GTK_OBJECT (&(dtw->canvas->widget)), "event", GTK_SIGNAL_FUNC (sp_canvas_event_handler), &(dtw->canvas->widget));

			and put some debug output into sp_canvas_event_handler. With or without the
			grab, it looks like the canvas widget gets keypresses, but does not pass
			them on to the event context. That is, it does pass it to the event context
			but only when the mouse is within the canvas.

			Maybe we need to grab focus on the event context, not on the canvas? But how
			to do that? I think the event context is not a GTK widget.

			* Mental responds:

			Well, grab_focus() isn't like a window "grabbing" focus;
			gtk_widget_grab_focus() is the normal mechanism for widgets handing
			focus off to one another.

			_new() likely isn't the time to call it, because its effect is not
			persistent.

			So it would need to be called e.g. when the canvas widget is clicked or
			moused over or something like that.

			Thinking about it, I _believe_ (I will have to double-check) that
			events are actually passed to the event context by the enclosing
			[ventBox (GtkDesktopWidget is a descendant of GtkEventBox).

			* and then adds:

			Ick.

			To be honest I still don't totally understand how events are handed off
			to event contexts in Sodipodi/Inkscape. :/

			> Maybe we need to grab focus on the event context, not on the canvas? But how
			> to do that? I think the event context is not a GTK widget.

			Well, ultimately _some_ widget must receive the events and passing them
			on to the event context. We need to figure out which widget that
			is/should be.

			-----

			UPDATE: OK, I think I fixed that. Now the canvas always gets all keys, including arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the document window has focus. This closes a sore "known problem" from 0.36 release notes.

			I'm not sure if my fix is "correct" but it seems to work. Previously, event contexts received events only from the "acetate" item on the canvas (this is an invisible item covering the entire canvas), and this item obviously can only have focus when mouse is over it. We have tried putting event grab on the canvas widget, but this apparently did not affect the acetate which, not being a GTK widget, cannot have a grab. My solution is simply to call sp_desktop_root_handler() from within the sp_desktop_widget_event() handler (which receives all desktop widget events regardless of mouse position) but only for GDK_KEY_PRESS events and only if the desktop's canvas has no current item (because in that case, an item handler must be called instead of root handler, and I don't need to do that anyway because this can only happen when the mouse is over the canvas).

			[[Category:Wiki Attic]]

St8Yqb at 12:24, 11 April 2007

2007-04-11T12:24:23Z

← Older revision		Revision as of 12:24, 11 April 2007
Line 1:		Line 1:
	As first discussed in [[InkscapeTamed]], keyboard events are sent to the event context handlers (both global in event-context.c and tool-specific e.g. select-context.c) ONLY when the mouse is over the canvas.		As first discussed in [[InkscapeTamed]], keyboard events are sent to the event context handlers (both global in event-context.c and tool-specific e.g. select-context.c) ONLY when the mouse is over the canvas.

	Simple experiment: move a shape by arrows. This works while the mouse cursor is over the document window but stops as soon as you move mouse away from it, even if the document window still has focus. Global verbs like + and - and ctrl-q always work. We cannot however make tool-specific shortcuts global verbs.		Simple experiment: move a shape by arrows. This works while the mouse cursor is over the document window but stops as soon as you move mouse away from it, even if the document window still has focus. Global verbs like and - and ctrl-q always work. We cannot however make tool-specific shortcuts global verbs.

	* Mental writes:		* Mental writes:
Line 17:		Line 17:
	I cannot make it work. I added		I cannot make it work. I added

	gtk_widget_grab_focus (~~&(dtw->canvas->widget));~~		gtk_widget_grab_focus (

	~~into sp_desktop_widget_new in desktop.c. For debugging, I also added~~

	~~gtk_signal_connect (GTK_OBJECT (&(dtw->canvas->widget)), "event", GTK_SIGNAL_FUNC (sp_canvas_event_handler), &(dtw->canvas->widget));~~

	~~and put some debug output into sp_canvas_event_handler. With or without the~~
	~~grab, it looks like the canvas widget gets keypresses, but does not pass~~
	~~them on to the event context. That is, it does pass it to the event context~~
	~~but only when the mouse is within the canvas.~~

	~~Maybe we need to grab focus on the event context, not on the canvas? But how~~
	~~to do that? I think the event context is not a GTK widget.~~

	* Mental responds:

	~~Well, grab_focus() isn't like a window "grabbing" focus;~~
	~~gtk_widget_grab_focus() is the normal mechanism for widgets handing~~
	~~focus off to one another.~~

	~~_new() likely isn't the time to call it, because its effect is not~~
	~~persistent.~~

	~~So it would need to be called e.g. when the canvas widget is clicked or~~
	~~moused over or something like that.~~

	~~Thinking about it, I _believe_ (I will have to double-check) that~~
	~~events are actually passed to the event context by the enclosing~~
	~~[ventBox (GtkDesktopWidget is a descendant of GtkEventBox).~~

	* and then adds:

	~~Ick.~~

	~~To be honest I still don't totally understand how events are handed off~~
	~~to event contexts in Sodipodi/Inkscape. :/~~

	~~> Maybe we need to grab focus on the event context, not on the canvas? But how~~
	~~> to do that? I think the event context is not a GTK widget.~~

	~~Well, ultimately _some_ widget must receive the events and passing them~~
	~~on to the event context. We need to figure out which widget that~~
	~~is/should be.~~

	~~-----~~

	UPDATE: OK, I think I fixed that. Now the canvas always gets all keys, including arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the document window has focus. This closes a sore "known problem" from 0.36 release notes.

	I'm not sure if my fix is "correct" but it seems to work. Previously, event contexts received events only from the "acetate" item on the canvas (this is an invisible item covering the entire canvas), and this item obviously can only have focus when mouse is over it. We have tried putting event grab on the canvas widget, but this apparently did not affect the acetate which, not being a GTK widget, cannot have a grab. My solution is simply to call sp_desktop_root_handler() from within the sp_desktop_widget_event() handler (which receives all desktop widget events regardless of mouse position) but only for GDK_KEY_PRESS events and only if the desktop's canvas has no current item (because in that case, an item handler must be called instead of root handler, and I don't need to do that anyway because this can only happen when the mouse is over the canvas).

	~~[[Category:Wiki Attic]]~~

GigaClon: Categorization

2006-06-20T18:11:33Z

Categorization

← Older revision		Revision as of 18:11, 20 June 2006
Line 6:		Line 6:

	Grabbing focus between widgets is accomplished via		Grabbing focus between widgets is accomplished via
	gtk_widget_grab_focus(). The widget will need to have the [[GTK_CAN_FOCUS]]		gtk_widget_grab_focus(). The widget will need to have the GTK_CAN_FOCUS
	flag set, however. I've taken care of the latter half in desktop.c now (setting the		flag set, however. I've taken care of the latter half in desktop.c now (setting the
	[[CAN_FOCUS]] widget flag).		CAN_FOCUS widget flag).

	I guess what remains is just determining when it would be appropriate to		I guess what remains is just determining when it would be appropriate to
Line 21:		Line 21:
	into sp_desktop_widget_new in desktop.c. For debugging, I also added		into sp_desktop_widget_new in desktop.c. For debugging, I also added

	gtk_signal_connect ([[GTK_OBJECT]] (&(dtw->canvas->widget)), "event", [[GTK_SIGNAL_FUNC]] (sp_canvas_event_handler), &(dtw->canvas->widget));		gtk_signal_connect (GTK_OBJECT (&(dtw->canvas->widget)), "event", GTK_SIGNAL_FUNC (sp_canvas_event_handler), &(dtw->canvas->widget));

	and put some debug output into sp_canvas_event_handler. With or without the		and put some debug output into sp_canvas_event_handler. With or without the
Line 45:		Line 45:
	Thinking about it, I _believe_ (I will have to double-check) that		Thinking about it, I _believe_ (I will have to double-check) that
	events are actually passed to the event context by the enclosing		events are actually passed to the event context by the enclosing
	[~~[EventBox]]~~ ([[GtkDesktopWidget]] is a descendant of [[GtkEventBox]]).		[ventBox (GtkDesktopWidget is a descendant of GtkEventBox).

	* and then adds:		* and then adds:
Line 52:		Line 52:

	To be honest I still don't totally understand how events are handed off		To be honest I still don't totally understand how events are handed off
	to event contexts in Sodipodi[[/Inkscape]]. :/		to event contexts in Sodipodi/Inkscape. :/

	> Maybe we need to grab focus on the event context, not on the canvas? But how		> Maybe we need to grab focus on the event context, not on the canvas? But how
Line 65:		Line 65:
	UPDATE: OK, I think I fixed that. Now the canvas always gets all keys, including arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the document window has focus. This closes a sore "known problem" from 0.36 release notes.		UPDATE: OK, I think I fixed that. Now the canvas always gets all keys, including arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the document window has focus. This closes a sore "known problem" from 0.36 release notes.

	I'm not sure if my fix is "correct" but it seems to work. Previously, event contexts received events only from the "acetate" item on the canvas (this is an invisible item covering the entire canvas), and this item obviously can only have focus when mouse is over it. We have tried putting event grab on the canvas widget, but this apparently did not affect the acetate which, not being a GTK widget, cannot have a grab. My solution is simply to call sp_desktop_root_handler() from within the sp_desktop_widget_event() handler (which receives all desktop widget events regardless of mouse position) but only for [[GDK_KEY_PRESS]] events and only if the desktop's canvas has no current item (because in that case, an item handler must be called instead of root handler, and I don't need to do that anyway because this can only happen when the mouse is over the canvas).		I'm not sure if my fix is "correct" but it seems to work. Previously, event contexts received events only from the "acetate" item on the canvas (this is an invisible item covering the entire canvas), and this item obviously can only have focus when mouse is over it. We have tried putting event grab on the canvas widget, but this apparently did not affect the acetate which, not being a GTK widget, cannot have a grab. My solution is simply to call sp_desktop_root_handler() from within the sp_desktop_widget_event() handler (which receives all desktop widget events regardless of mouse position) but only for GDK_KEY_PRESS events and only if the desktop's canvas has no current item (because in that case, an item handler must be called instead of root handler, and I don't need to do that anyway because this can only happen when the mouse is over the canvas).

			[[Category:Wiki Attic]]

Conversion script: link fix

2006-01-22T02:32:59Z

link fix

← Older revision		Revision as of 02:32, 22 January 2006
Line 1:		Line 1:
	As first discussed in InkscapeTamed, keyboard events are sent to the event context handlers (both global in event-context.c and tool-specific e.g. select-context.c) ONLY when the mouse is over the canvas.		As first discussed in [[InkscapeTamed]], keyboard events are sent to the event context handlers (both global in event-context.c and tool-specific e.g. select-context.c) ONLY when the mouse is over the canvas.

	Simple experiment: move a shape by arrows. This works while the mouse cursor is over the document window but stops as soon as you move mouse away from it, even if the document window still has focus. Global verbs like + and - and ctrl-q always work. We cannot however make tool-specific shortcuts global verbs.		Simple experiment: move a shape by arrows. This works while the mouse cursor is over the document window but stops as soon as you move mouse away from it, even if the document window still has focus. Global verbs like + and - and ctrl-q always work. We cannot however make tool-specific shortcuts global verbs.
Line 6:		Line 6:

	Grabbing focus between widgets is accomplished via		Grabbing focus between widgets is accomplished via
	gtk_widget_grab_focus(). The widget will need to have the GTK_CAN_FOCUS		gtk_widget_grab_focus(). The widget will need to have the [[GTK_CAN_FOCUS]]
	flag set, however. I've taken care of the latter half in desktop.c now (setting the		flag set, however. I've taken care of the latter half in desktop.c now (setting the
	CAN_FOCUS widget flag).		[[CAN_FOCUS]] widget flag).

	I guess what remains is just determining when it would be appropriate to		I guess what remains is just determining when it would be appropriate to
Line 21:		Line 21:
	into sp_desktop_widget_new in desktop.c. For debugging, I also added		into sp_desktop_widget_new in desktop.c. For debugging, I also added

	gtk_signal_connect (GTK_OBJECT (&(dtw->canvas->widget)), "event", GTK_SIGNAL_FUNC (sp_canvas_event_handler), &(dtw->canvas->widget));		gtk_signal_connect ([[GTK_OBJECT]] (&(dtw->canvas->widget)), "event", [[GTK_SIGNAL_FUNC]] (sp_canvas_event_handler), &(dtw->canvas->widget));

	and put some debug output into sp_canvas_event_handler. With or without the		and put some debug output into sp_canvas_event_handler. With or without the
Line 45:		Line 45:
	Thinking about it, I _believe_ (I will have to double-check) that		Thinking about it, I _believe_ (I will have to double-check) that
	events are actually passed to the event context by the enclosing		events are actually passed to the event context by the enclosing
	EventBox (GtkDesktopWidget is a descendant of GtkEventBox).		[[EventBox]] ([[GtkDesktopWidget]] is a descendant of [[GtkEventBox]]).

	* and then adds:		* and then adds:
Line 52:		Line 52:

	To be honest I still don't totally understand how events are handed off		To be honest I still don't totally understand how events are handed off
	to event contexts in Sodipodi/Inkscape. :/		to event contexts in Sodipodi[[/Inkscape]]. :/

	> Maybe we need to grab focus on the event context, not on the canvas? But how		> Maybe we need to grab focus on the event context, not on the canvas? But how
Line 65:		Line 65:
	UPDATE: OK, I think I fixed that. Now the canvas always gets all keys, including arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the document window has focus. This closes a sore "known problem" from 0.36 release notes.		UPDATE: OK, I think I fixed that. Now the canvas always gets all keys, including arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the document window has focus. This closes a sore "known problem" from 0.36 release notes.

	I'm not sure if my fix is "correct" but it seems to work. Previously, event contexts received events only from the "acetate" item on the canvas (this is an invisible item covering the entire canvas), and this item obviously can only have focus when mouse is over it. We have tried putting event grab on the canvas widget, but this apparently did not affect the acetate which, not being a GTK widget, cannot have a grab. My solution is simply to call sp_desktop_root_handler() from within the sp_desktop_widget_event() handler (which receives all desktop widget events regardless of mouse position) but only for GDK_KEY_PRESS events and only if the desktop's canvas has no current item (because in that case, an item handler must be called instead of root handler, and I don't need to do that anyway because this can only happen when the mouse is over the canvas).		I'm not sure if my fix is "correct" but it seems to work. Previously, event contexts received events only from the "acetate" item on the canvas (this is an invisible item covering the entire canvas), and this item obviously can only have focus when mouse is over it. We have tried putting event grab on the canvas widget, but this apparently did not affect the acetate which, not being a GTK widget, cannot have a grab. My solution is simply to call sp_desktop_root_handler() from within the sp_desktop_widget_event() handler (which receives all desktop widget events regardless of mouse position) but only for [[GDK_KEY_PRESS]] events and only if the desktop's canvas has no current item (because in that case, an item handler must be called instead of root handler, and I don't need to do that anyway because this can only happen when the mouse is over the canvas).

Buliabyak: *

2004-01-02T11:10:37Z

← Older revision		Revision as of 11:10, 2 January 2004
Line 60:		Line 60:
	on to the event context. We need to figure out which widget that		on to the event context. We need to figure out which widget that
	is/should be.		is/should be.

			-----

			UPDATE: OK, I think I fixed that. Now the canvas always gets all keys, including arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the document window has focus. This closes a sore "known problem" from 0.36 release notes.

			I'm not sure if my fix is "correct" but it seems to work. Previously, event contexts received events only from the "acetate" item on the canvas (this is an invisible item covering the entire canvas), and this item obviously can only have focus when mouse is over it. We have tried putting event grab on the canvas widget, but this apparently did not affect the acetate which, not being a GTK widget, cannot have a grab. My solution is simply to call sp_desktop_root_handler() from within the sp_desktop_widget_event() handler (which receives all desktop widget events regardless of mouse position) but only for GDK_KEY_PRESS events and only if the desktop's canvas has no current item (because in that case, an item handler must be called instead of root handler, and I don't need to do that anyway because this can only happen when the mouse is over the canvas).

Buliabyak: *

2003-12-11T22:55:20Z

New page

As first discussed in InkscapeTamed, keyboard events are sent to the event context handlers (both global in event-context.c and tool-specific e.g. select-context.c) ONLY when the mouse is over the canvas.

Simple experiment: move a shape by arrows. This works while the mouse cursor is over the document window but stops as soon as you move mouse away from it, even if the document window still has focus. Global verbs like + and - and ctrl-q always work. We cannot however make tool-specific shortcuts global verbs.

* Mental writes:

Grabbing focus between widgets is accomplished via
gtk_widget_grab_focus(). The widget will need to have the GTK_CAN_FOCUS
flag set, however. I've taken care of the latter half in desktop.c now (setting the
CAN_FOCUS widget flag).

I guess what remains is just determining when it would be appropriate to
call gtk_widget_grab_focus() on the canvas widget.

* bb writes:

I cannot make it work. I added

gtk_widget_grab_focus (&(dtw->canvas->widget));

into sp_desktop_widget_new in desktop.c. For debugging, I also added

gtk_signal_connect (GTK_OBJECT (&(dtw->canvas->widget)), "event", GTK_SIGNAL_FUNC (sp_canvas_event_handler), &(dtw->canvas->widget));

and put some debug output into sp_canvas_event_handler. With or without the
grab, it looks like the canvas widget gets keypresses, but does not pass
them on to the event context. That is, it does pass it to the event context
but only when the mouse is within the canvas.

Maybe we need to grab focus on the event context, not on the canvas? But how
to do that? I think the event context is not a GTK widget.

* Mental responds:

Well, grab_focus() isn't like a window "grabbing" focus;
gtk_widget_grab_focus() is the normal mechanism for widgets handing
focus off to one another.

_new() likely isn't the time to call it, because its effect is not
persistent.

So it would need to be called e.g. when the canvas widget is clicked or
moused over or something like that.

Thinking about it, I _believe_ (I will have to double-check) that
events are actually passed to the event context by the enclosing
EventBox (GtkDesktopWidget is a descendant of GtkEventBox).

* and then adds:

Ick.

To be honest I still don't totally understand how events are handed off
to event contexts in Sodipodi/Inkscape. :/

> Maybe we need to grab focus on the event context, not on the canvas? But how
> to do that? I think the event context is not a GTK widget.

Well, ultimately _some_ widget must receive the events and passing them
on to the event context. We need to figure out which widget that
is/should be.