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

[Owen Taylor <otaylor redhat com>]

Bill Haneman <bill haneman sun com> writes:

> Owen replied to 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. 
> 
> ...
> 
> > 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.
> 
> Ah, I really don't want to be rude, but that just feels daft to me...
> maybe I'm missing something?
> 
> To create an invisible child for focus when there's a perfectly real
> widget occupying the 'focussed' area of screen real estate seems
> obfuscatory.  I understand, sort of, the rationale but the conclusion 
> seems awkward.  And dealing with things like invisible children
> with focus tends to create drudgery for accessibility...
> 
> If toplevels really truly don't get focus in GTK+ for architectural
> reasons, why not just put a GtkBox of some kind in between the GtkWindow
> and the panel objects, and focus the box?

 * A request for a feature that GTK+ has never supported came up (allow
   widgets derived from GtkWindow to take focus themself.)

 * We are in API freeze

 * At least one workaround exists

Hence I suggested a workaround. 

You could also use an intermediate container widget ... that would be
a bit cleaner, but would require creating an additional custom widget
type since the standard GTK+ containers can't focus; so it would
be a fair bit more work as well to do things that way.

                                                   Owen