Re: Impact of fix for bug 50339 on keyboard accessibility of panel

["Padraig O'Briain" <Padraig Obriain Sun COM>]

I believ that I can achieve what I want to do, allow a panel to have focus and 
then have Tab and Shift+Tab give focus to objects in the panel without resorting 
to the dummy child widget suggested by Owen below.

Initially, the PanelWidget has GTK_CAN_FOCUS flag set and this flag is unset 
when one attempts to give focus to an object on the panel.

Padraig

> "Padraig O'Briain" <Padraig Obriain Sun COM> writes:
> 
> > The fix for bug 50339, setting a focus widget in a GtkWindow if it contains 
a 
> > focusable widget, has caused me a problem with keyboard access to the panel.
> > 
> > Is it the intention of this bug fix that a GtkWindow should never have focus 
if 
> > it contains a focusdable widget?
> 
> I don't think there is any new problem. With the default GtkWindow
> code, the window itself is never in the tab chain. While the widget
> came up in a buggy "no widget has focus" state, hitting Tab any number
> of times would never return to that state.
> 
> I don't think treating "no widget has focus" as "window has focus" is
> legitimate.  Characteristics of the focus widget include:
> 
>  - Has the HAS_FOCUS flag set on it if the toplevel has focus
>  - gtk_widget_is_focus() returns TRUE for it
>  - The ->focus_widget pointer of the toplevel points to it.
> 
> In _theory_ if a widget derived from GtkWindow wants to have a focus
> state that was focus on itself, it would call gtk_widget_grab_focus ()
> on itself to do that.
> 
> In practice, I'm pretty sure GTK+'s going to blow up if you did
> that. We can fix that, and probably should. But see below for a more
> immediate workaround.
> 
> > I need keyboard focus in the panel in order to access its context menu. I 
also 
> > need keyboard focus on the objects on the panel.
> > 
> > I had done this by regarding focus on the panel as the BasePWidget, which 
> > derives from GtkWindow, having focus.
> > 
> > Would the following change to gtkwindow.c be accepted?
> > 
> > Index: gtkwindow.c
> > ===================================================================
> > RCS file: /cvs/gnome/gtk+/gtk/gtkwindow.c,v
> > retrieving revision 1.188
> > diff -u -p -r1.188 gtkwindow.c
> > --- gtkwindow.c	2002/01/30 23:35:08	1.188
> > +++ gtkwindow.c	2002/01/31 13:31:18
> > @@ -3039,7 +3039,7 @@ gtk_window_show (GtkWidget *widget)
> >    /* Try to make sure that we have some focused widget
> >     */
> >    if (!window->focus_widget)
> > -    gtk_window_move_focus (window, GTK_DIR_TAB_FORWARD);
> > +    GTK_WINDOW_GET_CLASS (window)->move_focus (window, 
GTK_DIR_TAB_FORWARD);
> >    
> >    if (window->modal)
> >      gtk_grab_add (widget);
> 
> No, I wouldn't consider it correct for a derived class to override
> ::move-focus, no.  ::move-focus is an action signal used to connect
> key bindings to behavior; it's presence in the GtkWindow vtable is
> purely accidental and results from the fact that we reuse the signal
> mechanism to do key bindings.
> 
> And isn't what you are really trying to override is the 
(!window->focus_widget)
> not the behavior of move_focus()?
> 
> I believe the simplest way of achieving your goals is to create a
> dummy child widget to represent "focus on the panel" and to position
> that at a position outside of bounds of the panel dialog widget so it
> isn't visible.
> 
> Regards,
>                                         Owen
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list