Re: The state of keyboard navigation

[Soeren Sandmann <sandmann daimi au dk>]

Calum Benson <calum benson sun com> writes:

> I've just updated the keynav proposal tables at
> http://developer.gnome.org/projects/gap/keyboardnav.html with an extra
> column, listing what keynav seems to be in place as of Tuesday. 

The patch for paned keyboard navigation doesn't work very well. It is
possible to do much better, but there is a problem: Suppose we have
this construction:

        ------  ------  ||  ------ ------
        | a  |  | b  |  ||  | c  | | e  |
        |    |  |    |  ||  ------ |    |
        |    |  |    |  ||  ====== |    |
        |    |  |    |  ||  ------ |    |
        |    |  |    |  ||  | d  | |    |
        ------  ------  ||  ------ ------

double lines indicate a splitter bar, single lines are borders of
buttons (or other widgets). How would f6 navigation work in this
construction? My suggestion is

        a->c->d->e->a.

An alternative would be

        a->c->d->a,

but what should then happen if the user gives focus to e and presses
f6 a few times? 

e->a->c->d->a->... is not good, because then the user can't get back
to the original focus only by using f6 and shift-f6.

e->a->c->d->e->a->... is better, but then the number of widgets in an
f6 cycle would depend on where the cycle started. I actually tried
this, and it feels completely wrong (to me) that the widget is
sometimes included in the cycle and sometimes not. It is easy to
forget that you some time back gave focus to e and that the widget
is therefore included.

                             .... C ..............
                             .                   .
        ------  ------  ||   .   ------ ------   .
        | a  |  | b  |  ||   .   | c  | | e  |   .
        |    |  |    |  ||   .   ------ |    |   .
        |    |  |    |  ||   .   ====== |    |   .
        |    |  |    |  ||   .   ------ |    |   .
        |    |  |    |  ||   .   | d  | |    |   .
        ------  ------  ||   .   ------ ------   .
                             .                   .
                             .....................

The problem with my suggestion (a->c->d->e->a) is that I can't find a
way to implement it. The widget e is included in the cycle because it
is "some widget in container C's tab-chain that is not inside a pane".

I can't find a way to get that information without simulating a
tabbing though the container, and I don't think that is a good way to
do it.

It may be possible to get away with an extra internal method on
GtkContainer, _gtk_container_construct_tab_chain(), that would return
the container's tabchain whether or not it was created by the
application programmer. 

Another solution would be to change the semantics of
gtk_container_get_tab_chain() so that it never returns NULL.


Søren