Re: Automatic focus handling? How do I turn it off?
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. Yep, that's the code. Writing other widget sets is not what GTK is made for, so we don't have an easy way to change this. ;-) That's why Chris was working on Xlib Mozilla for a while I imagine. However you can do a hack to GtkWindow - connect to key_press_event, when you see one of these keys call gtk_signal_emit_stop_by_name to kill the event. Or subclass GtkWindow and override the default signal handler and do something a bit differently there. Should be able to get it working. You could possibly also override set_focus or grab_focus and do some sort of hack. You may well have weird interactions with GtkMozEmbed and apps like Galeon... You shouldn't need anything this complicated, or this likely to break stuff. 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. Regards, Owen ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
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_press handler, control returns to gtk, the focus is removed, and the event is propagated to the containing window where it is handled. So I suppose it could have something to do with gtk's support for moving the focus with tab, etc.. How does one turn this functionality off? you can't turn it off per se. you have two choices: 1) on a per-widget basis, catch key_press/key release events. if they are for one of the navigation keys, do nothing except: gtk_signal_emit_block_by_name (...); return TRUE; 2) install a global key snooper, inspect all key press events, and discard or translate the navigation keys. and yes, i don't like it any more than you do :) --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
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 navigation under 1.2 ... ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
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?? TTUL Ken -- New! ASPN - ActiveState Programmer Network Essential programming tools and information http://www.ActiveState.com/ASPN ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
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... use a key snooper instead of an event handler. --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
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
Re: Automatic focus handling? How do I turn it off?
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 regardless of the return status of other connected handlers. the docs for GTK+ 1.2 do not make this particularly clear. i believe that in GTK+ 1.3/2.0, this is no longer true, and things work the way the docs tend to suggest. its the default handler for key press events in a GtkWindow that controls the movement of focus between widgets in that window. the handler is executed unless you block the emission in the widget that currently has focus (i.e. the one that the window directs the events to). as i've mentioned, i find it easier to do all this stuff using a key snooper, which allows you to completely bypass all of GTK+'s builtin key handling. --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
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 emission as well. in GTK+ 1.2, the default handler is run regardless of the return status of other connected handlers. the docs for GTK+ 1.2 do not make this particularly clear. i believe that in GTK+ 1.3/2.0, this is no longer true, and things work the way the docs tend to suggest. In this case, what was being discussed was the return value of the default handler, so stopping emission isn't necessary - if someone connects another signal handler using gtk_signal_connect_after() they mean to override the return value. its the default handler for key press events in a GtkWindow that controls the movement of focus between widgets in that window. the handler is executed unless you block the emission in the widget that currently has focus (i.e. the one that the window directs the events to). This isn't quite right. In GTK+-1.2 - for every time a signal is run, up to three things may happen: 1) signal handlers run 2) the default handler runs 3) Signal handlers connected with gtk_signal_connect_after run. The return value from the signal is the return value from the last of these; so if 1) returns TRUE meaning handled, 2) will still be run and override this unless gtk_signal_emit_stop_by_name() is called. In GTK+-2 a TRUE return immediately stops emission. However - this all only applies to a SINGLE signal emission - even in 1.2, if the result of sending the widget to the focus widget is TRUE, no further handling will be done. http://people.redhat.com/otaylor/tmp/key-handling.eps is a diagram of key handling in GTK+-1.2 which may help (or may further confuse) as i've mentioned, i find it easier to do all this stuff using a key snooper, which allows you to completely bypass all of GTK+'s builtin key handling is quite complicated enough without getting key snoopers involved! The idea of key snoopers was to handle hotkeys that would work in any window - like the hotkey to invoke the GLE widget tree debugger. If you have a particular GtkWindow, a connection to key_press_event on the toplevel already allows you to override all key handling behavior. Regards, Owen [ Actually the situation with Komodo is rather more complicated again - having GTK+ widgets inside mozilla is basically two inter-toolkit widget embeddings. GtkWindow Mozilla content area GtkMozBox holding GTK+ widgets (GtkMozBox derives from GtkWindow!) ] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
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 problems with Mozilla plugins. Can anyone tell me where I can look in gtk to find this automatic focus setting code? I don't really understand the question - do you mean GTK widgets take focus when clicked? That code is per-widget, e.g. GtkEntry will call gtk_widget_grab_focus() if it gets a button click. 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. Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn it off?
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 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_press handler, control returns to gtk, the focus is removed, and the event is propagated to the containing window where it is handled. So I suppose it could have something to do with gtk's support for moving the focus with tab, etc.. How does one turn this functionality off? Thanks very much for your help, Havoc. Regards, Ken ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Automatic focus handling? How do I turn 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 GTK is made for, so we don't have an easy way to change this. ;-) That's why Chris was working on Xlib Mozilla for a while I imagine. However you can do a hack to GtkWindow - connect to key_press_event, when you see one of these keys call gtk_signal_emit_stop_by_name to kill the event. Or subclass GtkWindow and override the default signal handler and do something a bit differently there. Should be able to get it working. You could possibly also override set_focus or grab_focus and do some sort of hack. You may well have weird interactions with GtkMozEmbed and apps like Galeon... Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
