Re: [gtk-list] Re: Mouseless GTK+

[Kent Schumacher <kent structural-wood com>]

Preben Randhol wrote:

> "Jon K. Hellan" <Jon.K.Hellan@item.ntnu.no> writes:
>
> | --
> | I am slightly frustrated about trying to interact with GTK+
> | applications without a mouse. Before blaming anybody, I would like to
> | know how responsibility is divided between the widget set and
> | applications.
>
> One annoying keybinding is that one can use the arrow keys to jump
> between the different widgets. I know it sounds odd that this is
> annoying, but let me explain.
>
> If one press the down arrow to jump from one widget to another, what
> happens when on get to a text widget or a scrollable widget of some
> kind? Then there is an inconsistency in the behaviour of the arrow
> keys. If there is something that scrolls one normally expects the
> arrow keys to do this. But one first have to roam through all the
> other widgets to get there one gets confused. I think it is better to
> turn off the navigation with arrows between widgets except for the
> menus.

I disagree with this.  Users naturally reach for the arrow keys, and
have some pretty firm expectations on how they should operate.

In a former window system design I set it up so that an arrow key press would move
focus to the next widget in the direction of the arrow key.  I determined the next
widget by scanning through the editable widget list and finding the widget that was
most pointed at by the arrow (i.e.  I calculated some fudge factor based on
in line and perpendicular distances, and then chose the widget that had
the most 'worthy' value).

When an arrow key 'stalled' in a widget (for example a text widget), I would let
the arrow key move the cursor through the widget as expected until it hit the end
position.  I would then eat one arrow key press (to let the user have a palpable
'stop'), and then move to the next widget in the direction of the arrow key.  If
the widget that 'stalled' the focus was not changed as it was traversed, I made
a reasonable attempt to restore the look of the widget to what it was before
it was traversed.

This was (and is, I guess) a pretty well liked navigation strategy.


>
>
> The other problem is TAB. TAB is usually used for jumping between
> widgets, but it is also used for completion. If one wants to have a
> TAB-completion in a combo-box it will be confusing, as TAB doesn't
> work as expected. It think in this respect it is better to use
> Ctrl-TAB for completion. The reason I don't like Alt-TAB is that this
> is much use to cycle windows in windowmanagers.
>
>

This I completely agree with.


> The best would of course, be if all keybindings where configurable, but
> that does not make the problem of having a good set of default
> keybindings go away.
>

And this as well.

>
> --
> Preben Randhol             oO     "Don't think about domination,  think
> [randhol@pvv.org]        .`  ;     about freedom, it doesn't dominate."
> [www.pvv.org/~randhol/]   \ G                  -- RMS, LinuxWorld 1999.
>                            `_) n o m e
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null

Kent

--
If I had a signature, do you think I'd let YOU see it?