279

This is not a ready-to-implement mockup but rather something in between a mockup and a question.

For years now I haven't found context menus to be presented in a way that invites me to use them:
1. There are often many items with large horizontal, but little vertical expansion which makes you move your cursor very carefully in order to not click the item right above.
2. The longest item determines the size of ALL other items, meaning: "This is a very long and annyoing item" gives you a context menu of, say, 400px, while the other items wouldn't need more than 180px.
This can lead to context menus whose space is used rather badly.
Example:


Much space, little content and I don't think this is only a problem of the german language.

Now my proposal is to introduce buttons (rather than list elements) that can be aligned not only vertically as it is now, but also horizontally.
To give you an idea:
Now:



Could be:


In my opinion, it is much easier now to use the upper three button elements, as they are:
1. easily visible (they now are similar to the main toolbar with icons and text combined like in KMail introduced with KDE4; I think that was a HUGE improvement over the former tiny icons)
2. easier to hit.
At the same time, no additional space is used. In fact it would be possible to decrease the amount of space a context menu needs while keeping the content and functionality the same.

Note that this could (and should) be done better if really implemented, more buttons could be put into the first row, shortcuts are not displayed now.
But before I (and others hopefully) start to think about details, I would like to know from some developers whether or not this extension is technically possible.
I am not sure if a developer actively has to implement this (to be added) feature or if KDE SC is technically able to try to decide which list elements should be used as buttons and which not; this clearly would make an adoption much easier because developers wouldn't have to know about this feature, but I guess this is not possible in a satisfying way.

Well, yes, so this is the question part of my proposal: is it possible to implement something like this? (And if not: how long will it take you to make the magic happen? )
Again: the context menu I would like to see in the future does not necessarily need to look the way I imagined here in this brainstorm. I'd primarily like to know what is possible before going on to think about something concrete.

On a final note I would like to give you another example of this context menu which I think could improve usability while decreasing complexity at the same time:


Here the two "Copy" and "Copy to..." elements are combined, thus removing one of those IMO critical expanding pop-up menus (I just can't seem to remember the proper name...).
The same could be done with "Open" and "Open with..." and some others, [EDIT] for example a combination of "Cut" and "Move to..." which Fabian Schoelzel made a quick mockup of in the comment section down below (brainstorm.php?sid=3f9fc3d0d7eeccf85c2af77736fbfc47#idea89969_comment169893) making free additional space.
Thanks for that!

[EDIT/UPDATE2]: progger1986 wrote this very nice proof of concept:
http://www.linux-ecke.de/Contextmenu.tar.gz
Thanks a lot!

Thank you for listening,
VaterGarp

I just wanted to say that is a really well presented and well thought out idea. I'm impressed. I hope it comes to something.

Good idea and good mock-up.

Would love to see this implemented. Very nice proposal.

I'm glad to hear that. Now if only a developer could make a statement on feasibility...
Is this the wrong place?

Just wait a bit, they will come if it is good idea and has many votes

Alright
It's just that I think I could and would give some deeper thought to this concept if I knew this kind of context menu is POSSIBLE.
It'd be a letdown to put much effort into it and find out it's a stillbirth.

Well, I'm gonna be patient then.

Good idea!

But I think (I'm not a kde developer) that a feature like that should be implemented in qt, not in kde.

votes++

This is a fantastic idea. Productivity would increase dramatically. The drop down menu on the copy/paste option is brilliant. It sorta seems obvious this should be done. Major kudos for this brainstorm presentation.

Brilliant idea. I also had the problem some times, that i miss the line while moving from left to right on wide context menus. Reading this, i just realise that i move the cursor along the left side, where the descriptions are - i could move it on the right side (which would be easier to open the context menu tree), but i think most people do it like me.

"Move to" (Verschieben) can be combined with "cut", too. To cut always is the first step to paste short after, which is moving. Also, favorites, that you set in the file chooser or dolphin, should be available under "favorites". Please take a look at my fast'n'ugly edit:

Thank you all for your support!

@Fabian Schölzel You're right, combining "Cut" and "Move to" would be the next step.
Maybe it is necessary to add a label on top of the "Move to..." popup menu in order to explain what it means compared to a simple "Cut" action.
I'm not sure here.

To be honest, I was too lazy to add this combination to my mockup, but now that I see yours, I see it would have been worth the time
Thanks a lot for your effort! I'll link to your mockup in the initial post, if you don't mind.

Adding Favourites is a good idea, but "Browse" shouldn't be omitted.

@mous16 You're right, Qt might be a better place to implement this due to its "parenthood". But I think KDE is a lot more versatile (can you say that about a project?) and likely to develop and introduce this kind of feature as it's a big community rather than a part of a company. This is not meant to be criticism to former Trolltech; it's just the reality (IMO).

You see, this is why Mercedes, BMW, Porsche, Audi are all German cars

Very well thought out and presented!

Very good idea!

VaterGarp wrote:
@mous16 You're right, Qt might be a better place to implement this due to its "parenthood".

i think this is already possible. there is a way to include custom qt widgets into a menu, rekonq does that.

btw, i think this is a great idea!

I think it is already possible to implement this in KDE, because KDE has its own KMenu-class, you know, KDE reimplements a couple of Qt-standard-widgets with some advanced features.
Question: Which items should be the biggest ones?
Second question: Do you think there is a chance this gets implemented if there is no configurability, see this idea?