--nextPart1239667.F9zr6oiQxF
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 29 March 2007 18:39, Ellen Reitmayr wrote:
> > Toolbars and their buttons per definition do not get focus. So what you
> > ask is not possible anyway.
>
> well, one of the reasons to start this thread was to make it possible.

The reason they do not get focus because it gets dirty really quickly=20
otherwise.
Imagine clicking on the 'Bold' button and then noticing you have to click i=
n=20
your text again because clicking on the bold button shifted the focus there=
=2E=20
So all keyboard input goes there.  We choose long ago to never make buttons=
=20
on a toolbar take focus for that reason. And I've tried to fix it in severa=
l=20
different manners, but really, that is the best way.

> > As another poster in this thread mentioned; all items in toolbars are
> > already available in the menu (including hiding/moving them)
>
> they are available in the menu, but much harder to reach.

The cost of allowing toolbuttons to take focus is higher then the benefit=20
gained to save one or two keystrokes.
And, honestly, you are asking for another keystroke to learn instead of usi=
ng=20
the already known keyboard navigation of the menu. I'm not sure that the=20
action in menu is indeed harder to reach. For a toolbar you have to apply a=
=20
new keystroke to cycle though the toolbars and dockers and then using tab o=
r=20
something to reach the actual button. Sounds harder than using the arrow ke=
ys=20
as used in the menu.

> > So I don't think we should want to navigate a toolbar.
>
> I think we want to.

I still have my doubts.
=2D-=20
Thomas Zander

--nextPart1239667.F9zr6oiQxF
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBGC/EsCojCW6H2z/QRAq6rAJ0SXkETXBlQpgMQwDDAVi3KA28yQACePIf9
4ZAvzGB7UXWuMUGp+g9wyyc=
=DiME
-----END PGP SIGNATURE-----

--nextPart1239667.F9zr6oiQxF--