279

1. Which items should be the biggest ones?
While at first I thought it might be nice to have a way to let KDE 'guess' which items should be the big ones, I now doubt that there is any satisfying way to accomplish and manage this 'auto-detection' (I'd gladly be proven wrong here).
Thus I think a developer should decide what menu entries are the most suitable ones, probably supported by HIG (How many icons? Which should I choose?).
Only he (or she!) knows his (or her!) application and has an idea about which entries transformed into icons would be most useful.
Also, combinations of entries like "Open" and "Open with..." or "Cut" and "Move to..." don't seem to be possible otherwise.
The question "Which should I choose?" could be answered with: the most often used ones, which mostly will be the upmost ones making it easy to convert menus.
For "How many icons?" a percentage could be given, but I really think developers will make the right decision in most cases.

2. I don't see how configurability of context menus in general affects feasibility of this certain implementation.
Could you explain this a bit further?

First of all: I do not think it could be implemented in Qt, Qt wants to be a good GUI-toolkit, it does not want to provide a fancy new look&feel.

I do not think that there is a perfect layout for everybody on every device in menubars and context-menus. There will be a lot of people wanting just a normal context-menu, some beginners may be confused by the icons, some developers may want to have some other stuff in their application, some KDE-software may be used in non-KDE-environments and the user may want to have consistent menus. Other users may want to minimize mouse movement or do not want any textual items at all�

Should such menus be used in menubars, too?

I like your idea but it doesn't solve problem completely.
You idea of buttons is kinda Chrome menu. It works best for basic entries ie cut, copy and paste - it'd be nice to see them merged.

But what about other entries?
"Extract files here, detect sub directories automatically" (don't know exact translation) is quite long in English, Polish and I guess in German.

I agree that the context menu width should be fixed. So except buttons on the top other entries that don't fit should be scrolled horizontally.

@The User: I don't know what you're trying to say with "fancy new look&feel". This is not about adding crazy blingbling nobody can use nor wants to see, but about improving usability.
Good usability definitely is part of a "good GUI-toolkit".
I like your idea of using this kind of menus in menubars.
"Redo" and "Undo" for example could be combined, and I've seen many options in different applications in the last few days that would benefit a lot.

@RRH: I don't use Chrome and couldn't find screenshots that made it clear to me what you are refering to. Could you give me a link?
You are right when you're saying that it does not solve the problem of some entries being longer than others, but I guess there isn't really a way of completely solving this.
After all there will be actions that consist of just one short verb, while others need a certain description you cannot omit.
The only thing a developer can improve is to combine standard actions which are often used and don't need a long explanation, and put them together in a prominent position, making it easier and faster to hit them.

VaterGarp: here you go:

I like this idea, and i think it is definitely doable. KDE uses KMenu and KAction to draw the contextmenus and, though i never ditched in them, i think it would be fairly simple to add this feature.

I Think you can move the "Move to..." Item to a subitem of "Cut" as you did with the "Copy to..." item.

While i did a small test i came with the idea to make the renaming directly in the context-menu.

It seems to be very easy to implement this. Qt has QWidgetAction wich makes it very easy to put anything to a menu.

Your idea is really good, i think that the button which are listed on top can be choosen from a configuration dialog of dolphin..However the most used fuction are copy\paste \ remove..

I have made a small programm that shows my ideas to this idea.
The code is a small Quick&Dirty hack to realize it. currently it has no fuctionality.

Screenshot: http://www.linux-ecke.de/context.png
Source: http://www.linux-ecke.de/Contextmenu.tar.gz

@progger1986 Very nice. I don't have time to look at the code right now, but some 'proof of concept' is very valuable. Thanks a lot!
By the way, your idea of combining "Cut" and "Move to" is part of the original idea already, Fabian Schoelzel made a mockup of it.

Great idea!

Would like to see this enhanced context menu in a future release of KDE.

An other idea from me completes the convertion of small entries to bigger icons:
http://www.linux-ecke.de/context2.png

Advantages: A Bit smaller, better usable with Touchscreens.

The Point "Others" is mean for the old "Actions" wich contains "Encrypt", "Burn with K3B", etc. and other stuff that does not fit to the other options.

What I liked about the original idea is that it created a hierarchy between functionnalities. The most used were the easiest to identify.

With your proposition progger1986, there is no more hierarchy, and the user has to look vertical and horizontally to get what he wants. This is more confusing than the current menu.

I think we should keep the first proposition.

That's what I definitely would want to keep - the hierarchy.
There might be special touchscreen context menus using the "make everything an icon" but for a usual mouse interface, offering just 3 to 4 icons (depending on the total number of items) will make clear where the requested action most likely will be.

@progger1986 Your proof of concept is just great. I wouldn't have thought that it was going to be this easy. As far as I can tell, there was not even a new class introduced. It seems like this context menu can be used in applications already without further ado. I am not sure about the Rename item as I personally think it creates clutter, but that's just my personal opinion and it's the kind of fresh idea the context menu could do with.

in the PoC i had to do some tricks to have it looking nice. For exmaple the rename Icon has a fitting size, so it look like a normal Menu entry with icon.
And if you make the icons for "Cut/Copy/Paste" smaller they do not use the whole width of the menu.
So i would preffer to hide such tricks in an own class to have a clear App-code.
What i did was:
In the C/C/P: It is a QWidgetAction wich has a QToolBar, wich contains all three Actions.
The Rename: It is a QWidgetAction wich contains a QWidget with a QHBoxLayout with the Elements: QLabel as Icon, QLabel and QLineEdit.
To let it behave like an Action: connect(lineEdit, SIGNAL(returnPressed()), widgetAction, SIGNAL(triggered())).