[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KDE's menu implementation.
From:       Troels Tolstrup <troels () tolstrup ! org>
Date:       2002-05-29 14:03:10
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I'll give another example why we need the hover effect: Take the case
> where a user is navigating the menus with a keyboard. They navigate
> onto disabled menu items (yes, Qt allows this!), and with your
> recommendation, they would have no feedback showing them what menu
> item they're currently at.. So I'm sorry but this must stay as is for
> now.

I just did a quick test.

Mozilla behaves in the same way as kde currently does.
Gnome 1.4 does not give any visual feedback when the mouse enters a 
disabled menu, nor does it let you select disabled entries with the 
keyboard.

I can't say that i have performed any user tests on this, but i can't 
help but think that gnomes behavior is the most logical. The menu item 
is disabled, trying to select it doesnt make much sense.

The only argument i can come up with in favor of the current behavior is 
that users that rely on strange keyboard navigation would get burned if 
disabled items are skipped. Strange keyboard navigation as in 
"alt-right-down-down-down-down-down-down-down" to search in kmails 
composer window.

- -Troels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE89PtFmTmAA3i3lrERAjOBAJ4hTOa7mHhCZe+YFaLGsCQy5G8xjgCfcZGd
69MMEluCTyaurOxVnnLZTWI=
=Ywt1
-----END PGP SIGNATURE-----

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]