Paul Davis <[EMAIL PROTECTED]> writes:
> >>>Widgets are sent key presses before GTK+ checks for focus keys. If the
> >>>widget handles the key press in its event handler and returns TRUE,
> >>>then GTK+ will not check for tab/arrows.
>
> not true in GTK+ 1.2. you have to stop the signal emissio
>>>Widgets are sent key presses before GTK+ checks for focus keys. If the
>>>widget handles the key press in its event handler and returns TRUE,
>>>then GTK+ will not check for tab/arrows.
not true in GTK+ 1.2. you have to stop the signal emission as well.
in GTK+ 1.2, the default handler is run
Ken Simpson wrote:
>>Widgets are sent key presses before GTK+ checks for focus keys. If the
>>widget handles the key press in its event handler and returns TRUE,
>>then GTK+ will not check for tab/arrows.
>>
>>For instance, this is how GtkText prevents a tab key from tabbing out
>>of the GtkText
>i.e., the order of operations should be:
>
>1. Mozilla grabs ALL gdk events and processes them in its own handler
> (i.e. gdk_event_handler_set (handle_gdk_event, NULL, NULL);)
>
>2. Events are then farmed out to the widget from which they
> originated (an nsWindow pointer is stored in the us
> Widgets are sent key presses before GTK+ checks for focus keys. If the
> widget handles the key press in its event handler and returns TRUE,
> then GTK+ will not check for tab/arrows.
>
> For instance, this is how GtkText prevents a tab key from tabbing out
> of the GtkText widget.
Hrm.. I gues
>Widgets are sent key presses before GTK+ checks for focus keys. If the
>widget handles the key press in its event handler and returns TRUE,
>then GTK+ will not check for tab/arrows.
Owen, I'm suprised! You must be too used to Gtk 1.3 :) Returning TRUE
by itself isn't enough to stop focus navigat
>I apologize if I wasn't clear in my email. The problem is that pressing
>keys such as the arrow keys, the backspace, and the tab cause my widget to
>lose focus and for its containing window to gain focus. The key press
>event first hits my widget and then, once I have returned 0 from the
>key_pr
Havoc Pennington <[EMAIL PROTECTED]> writes:
> Ken Simpson <[EMAIL PROTECTED]> writes:
> > Is this the code which performs automatic focus changing in response to
> > keypresses? It certainly seems to fit the symptoms :)
> > Hmm.. But there doesn't appear any way of "turning it off".
> >
>
>
Ken Simpson <[EMAIL PROTECTED]> writes:
> Is this the code which performs automatic focus changing in response to
> keypresses? It certainly seems to fit the symptoms :)
> Hmm.. But there doesn't appear any way of "turning it off".
>
Yep, that's the code. Writing other widget sets is not what
> Or do you mean GTK has support for moving focus via the Tab key, etc.?
> This is handled initially in the key_press_event default handler in
> gtkwindow.c and from there moves into the "focus" virtual
> function/signal on specific sub-containers.
Let's try lines 1255+ of gtkwindow.c:
c
> Or do you mean GTK has support for moving focus via the Tab key, etc.?
> This is handled initially in the key_press_event default handler in
> gtkwindow.c and from there moves into the "focus" virtual
> function/signal on specific sub-containers.
I apologize if I wasn't clear in my email. The
Ken Simpson <[EMAIL PROTECTED]> writes:
> I was told that gtk has a mechanism for automatically setting or removing
> the focus on widgets in response to events such as keypresses. I think
> this mechanism has been enabled somewhere inside Mozilla and is causing
> all kinds of focus-related probl
12 matches
Mail list logo
