330009 - Adjusting pane boundaries by keyboard?

Status: NEW

(Thunderbird :: Disability Access, enhancement)

Description

[Joachim Lous]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I'm having to avoid mouse use these days.  With a mail client it is actually often useful to adjust the pane boundaries during normal use.  <some modifier>+ arrow keys would be a natural candidate, and both "alt" and "shift+ctrl"
seem to be free for use in thunderbird.

Mapping should be easy: there is only one vertical and one horizontal boundary in thunderbird.  One might prefer to establish a less direct but more general abstraction that will usable across applications with arbitrary pane layouts.  A fairly intuitive one might be that <mod>+up "grows" the current pane vertically, and so on.




Reproducible: Always

Comment 1

[Mike Cowperthwaite]

(In reply to comment #0)
> there is only one vertical and one horizontal boundary in thunderbird.  

In two of the provided layouts, that's true.  However, there is also a three-column layout, and requests for additional layouts including three horizontal boxes stacked on one another.

I think this would be a good extension for TB.

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Joachim,

Your idea for developing a general abstraction for resizing pane boundaries is interesting. We might want to follow GNOME convention: http://www.gnome.org/learn/access-guide/latest/keynav-11.html
(look for "When the resize handle has focus")

This might be a nice little project.

Comment 3

[Joachim Lous]

(In reply to comment #2)

I suppose it could work, but I am a bit skeptical of the gnome scheme if going for a reusable concept. First of all, f8 is not likely to be available in very many apps.

Secondly, moving the focus away from the pane and onto the divider seems like introducing uneccessary state to me, which is always a bad thing.  Lasting focus on a divider doesn't really make a lot of sense either: There is nothing to do with it except move it, and the motivation is usually to make some pane bigger. Why not consider the whole thing an operation on the pane? Quick and efficient, easy to understand, no need to render the divider as focused, and no need to find your way back to the focus you had.

There are a couple of choices in how to map it though:

My original suggestion only allows "grow" and "shrink", without reference to which side should be moved to achieve this (imagine the pane in question lies between two dividers).  This is simple to understand, but gives less control: there would have to be some automatic choice in how much to move each divider, and some states can only be reached by adjusting more than one pane.

An alternative is the way you size windows in Windows: the first cursor key of the operation indicates which side of the window you are moving, the remaining strokes move it freely back and forth.  Very efficient and precise, but might take a few tries to get the hang of the sematics (bacause again, state is introduced. But here it a would at least revert as soon as you release the modifier, so it doesn't hang around and confuse you). Ths approach also has the advantage that it is esatablished, so at least windows-based mouseless users would recognise it.