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 widget.
>>
>
> Hrm.. I guess the problem with Mozilla is that I need the keypress event
> to live on for a little while so that Mozilla can grab it. I can't just
> kill all the navigation keys -- Mozilla needs them so that it can farm
> them out to its command system.
>
> 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 user data of the
> event's any.window object).
>
> 3. The widget's key_press handler returns 0 for any keypress which is not
> something simple, like [A-Za-z0-9_-+] etc..
>
> 4. (hopefully) The key_press event travels up the window hierarchy to the
> main Mozilla window, where it is ground through the Mozilla keybinding
> system and produces some result. The event then should _die_.
>
> The problem is that, between stages 3 and 4, gtk intercepts the key press
> and changes the focus. Yuck. I don't think the fix here is going to be
> easy...
>
> Ideas??
What is it that intercepts the key presses? Is it the gtkwindow class
that is being used by the mozbox? Or is it being farmed all the way up
to the toplevel? We might need to override the keypress handler for the
mozbox class so that the default gtkwindow handler doesn't change focus
on you like it sounds like is happening.
--Chris
_______________________________________________
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
