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

List:       kde-usability
Subject:    Re: KDE's menu implementation.
From:       Karol Szwed <kszwed () latcs2 ! cs ! latrobe ! EDU ! AU>
Date:       2002-05-29 4:22:33
[Download RAW message or body]


On 2002-05-28 16:31:54, Simon Edwards wrote:
>Some issues concerning how KDE renders menus. (This is all w.r.t. the 
>default widget style).
>
>1) Disabled menu item go depressed when you mouse over them!
>
>Greyed out menus item go depressed when you rollover them with the mouse. 
>'Rollovers' like this indicate that an item is in fact active and ready 
>to be used. This is a strong convention from the Web. KDE's menus should not 
>give such mixed signals.

>Recommendation: Inactive menu items should not have rollovers!
Well, this is true, however the icon is dimmed, and the text is in the 
disabled state, so its not exactly active. The mouseover effect simply 
helps guide the user through the menu. The hover effect is actually  
meant to indicate 'selected', not 'active'.

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.

>2) On/Off checkable menu items (ticks) look exactly the same as 
>radio-button menu items.
>
>Checkable menu items can be either like checkboxes, i.e. boolean, or like 
>radio-buttons i.e one from the a group can be selected (like 
>radiobuttons). KDE's renders both type exactly the same. This is bad 
>because the user now has to play with the menu items to work out which
>ones show mutual-exclusive behaviour, and which ones don't. 
>Windows actually gets this right. Boolean items have ticks, while radio
>menu items use a bullet.
>
>Recommendation: Radio menu items should be rendered with a bullet in 
>front and not a tick.

I agree, it is slightly annoying. I'll see if I can force Qt to paint 
in this way. FYI, I'm against having checkboxes/radio buttons in popup 
menus anyway, and think its bad UI design in the majority of cases where 
they're used.

>3) The state of checkable menu items (boolean) that have icons in front 
>of them is not very clear.
>
>For example "Konqueur->Window->Show Terminal Emulator".  Menu items with 
>icons show the 'checked' state by using a depressed border and white 
>background. This border easily gets visually lost amongst the icon 
>itself, and makes it hard to quickly see the state of the menu item. Menu 
>items without icons use a tick on the same depressed border to show 
>the 'checked' state. I would have thought that most people recognise
>the 'checked' state more by the tick, than by the border/background.

This was done to be consistent with Qt's styles' behaviour.
Again, checkable menu items should never have Icons.. another sign of bad 
UI design IMHO. I might simply remove painting the icons in these cases to 
force apps to comply.. I have yet to decide though. :)

P.S. Please CC any replies as I'm not subscribed to this list.

Kind Regards,
Karol.

_______________________________________________
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]