Action icons in menus

[Aaron J. Seigo]

On Monday, December 13, 2010, Dan Meltzer wrote:
>  If common actions were all handled in this way, then it might
> actually lead to more consistancy, 

consistency with what? certainly not with the menus, where we will now have 
items that behave differently.

(as a side note: this will break with dbusmenu; so it can't find its way 
easily into the system tray icon menus, for instance)

> and ease of access. 

i still have reservations about this given the introduction of a second axis 
of freedom within the menu.

> Actions are
> not particuallarly consistant across applications, and so it becomes
> necessary to read the entire list to find the item you are looking
> for.  If cut/copy/paste were always found as icons at the top of the
> menu in applications that support them, it would probably lead to
> accessing them quicker.  

if they were always in the same place in the menu, regardless of presentation, 
it would help. the questions that remain would be:

* are they important enough to always be at the top of the menu in all 
applications? if not, which applications / use cases does it make sense to do 
so?

* what is the actual amount of time / effort spent locating these items in 
menus as it stands now?

> Of course, I'm not sure how many people would
> do this vs. the shortcuts that are also well known, but if this was
> done for other actions as well, perhaps it would be beneficial?  The

putting the most common actions at the top of the menu is useful regardless of 
layout.

> icons should probably always be at the top of the menu, to add that
> consistancy, and I'm not sure if there are enough actions out there to
> merit the additional code path, but I think that this might actually
> be able to develop into something unique and useful.

i'm happy to change my mind in the presence of compelling demonstrations :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101213/8c3e4579/attachment.sig>