Action icons in menus

Celeste Lyn Paul celeste at
Fri Dec 24 18:37:13 GMT 2010

This is a very interesting concept, but not necessarily for context
menus. Imagine this design proposal as a first step towards merging
window menu and toolbars, not too disimilar from the Microsoft ribbon.
One weakness with the ribbon is that it limits the amount of
functionality by what can graphically fit in the ribbon interface.

Instead of going pure graphics, you could merge frequently used tasks
(graphics) with extended functions and features (text menu items).
This would preserve the amount of functionality in an application
(Microsoft stripped out some features or moved them to different
places in order to fit them in the ribbon). At the same time, we would
have an updated look and feel to our windowing concept that maximizes
common interactions.

I think something like this could also be an interesting alternative
to what IE7 does by providing minimal toolbar buttons and menu items,
and hiding everything else. In this design, additional functionality
would be on a true "second layer of disclosure" rather than "hidden

Anyway, just some thoughts. I don't want to discount the design simply
because of a few minor issues, because it is still in the conceptual
stage. We don't want to shoot down ideas like this too early in the
design process, otherwise we will never innovate.

Just some thoughts.

On Mon, Dec 13, 2010 at 2:56 PM, Miha Čančula <miha.cancula at> wrote:
> I have recently come across an idea on KDE Brainstorm. [1] The proposal is to change the common actions in menus (cut, copy and paste) from text lines to icons, like in application toolbars. It is currently the most popular idea there.
> Someone posted a proof-of-concept example of how this can be achieved, and I used it for Dolphin's popup menu. [2] Code-wise, this change is very simle (5 lines of code at most). Qt can embed custom widgets to menu via the QWidgetAction class, and this class can contain a KToolBar. It has to be done for each application, but there's very little work involved. If the idea is accepted, a convenience method or two would be added to KMenu and/or KStandardAction, so there could be a global settings to fall back to current mode.
> However, it is a major change for user interaction. So I'd like to start a discussion whether such a change is desired for KDE applications or not. The pros and cons I can think of right now are:
> Pro:
>  1. Biger clickable area => less chance of misclicks
>  2. Icons, when they are intuitively identifiable with an action, can be recognised by humans faster and much easier.
> I think the above makes it better from a usability standpoint, but as a programmer I wouldn't know much about that.
> Con:
>  3. For actions that are not easily identifiable by an icon, this is very bad. This is the reason only some of the actions would be converted to icon display, as you can see from the mockups and screenshots.
>  4. It looks (a little) like the ribbon UI.
> I personally believe such a change is a good thing. However, there must be limits. Using it in right-mouse-button menus is one thing, using it in the File menu is another. I would very much like to know how you feel about this.
> Thank you,
> Miha Čančula
> [1]:
> [2]:

Celeste Lyn Paul
KDE Usability Project
KDE e.V. Board of Directors

More information about the kde-core-devel mailing list