18

Hi!

You can ofte read suggestions for new kind of menus in some specific contexts. E.g. somebody wants to have context-menus with bigger icons, other people want to use circla-menus, and for the app-launcher there are the “traditional” and the “kickoff” style. I think KMenu should be implemented in a flexible way making it possible to choose between different menu-styles in context-menus, menubars and probably also at other locations. The user should be able to write rules (maybe a small script) determining which kind of menu should be used. Such rules could care eabout the current application, the number of items, the location (menubar/contextmenu) etc. and could also determine some parameters (geometry etc.). When looking at Lancelot we see that great new menu-designs are possible, but why shouldnâ��t they be availible everywhere?

Regards
The User

To answer the question of "why shouldn't they be available everywhere" is because the user doesn't want the level of complexity of kickoff or lancelot in most of the menus they use. Those menus are great for managing multi-level nested actions, allowing searching, organizing favorites, etc - things that are necessary because of the shear number of possible actions available from the main application menu.
As for the majority of menus available, I can see the possibility of allowing switching between rectangle/linear and circular. However, I am doubtful as to if there are really that many options for menu styles that will be usable or efficient enough for the relatively short menus we generally use (typically less than 12 items with maybe 1 level of nesting) to warrant providing them as alternative options.

Another problem that I see is that giving the user that fine-grained control over where which menu styles are used will be quite overwhelming, especially when most of the time the user will set one style globally and leave it at that (or maybe one style for application menus and another one for context menus). Rarely would a user set different styles for different applications, and setting different styles based on number of items or other criteria will only lead to confusion (config overload). The idea of providing a scripting interface to configure anything seems ludicrous to me.

On the other hand, letting application designers determine the rules is a possibility; though they do already have that control. Those that understand that they do have the option to set up different style menus generally don't because the default rectangular menu is the most efficient (if at least most familiar) implementation for most cases.

E.g. I would prefer Kickoff-style (not searching etc., but the way submenus are displayed) everywhere. Have you read the suggestion to make some menu-items bigger? For such stuff you would really need flexible rules. And maybe somebody invents a great new ordering of items and instead of long discussions and proof-of-concepts we could just implement and test it everywhere.
Instead of scripts small .so-files contaning a function could be loaded, too.
Maybe most users would choose one style globally, but it could still be great for a lot of users to be able to change it somewhere.
I do not know any KDE-application where traditional, linear, non-kickoff menus have been replaced by something else. Application developers do not control all places where KMenu is used, sometimes KMenus are generated by a library like Plasma or KXmlGui or there is a KPart containing context-menus.

This seems to be two related ideas in one (not that they can be presented in two separate topics):
A) The ability for menu designers to create different menu implementations and distribute these implementations.
B) The ability for the users to select different menu implementations via a config setting (most likely global or per location (context vs. menu bar), possibly per application).

And possibly per number of items or something special�

I'm against this idea. This would lead to a huge amount of non-unified interfaces, hard to track bugs, and a general increase in complexities. Dropdown menus are dropdown menus. Let's keep it that way.

Well, but many people are not that happy with it. E.g. I think that Kickoff-style-nested-menus are more comfortable, because it happens quite often that you lose the focus and the sub-menu you reached has gone. Other people think that it is difficult to hit the items, so it may be good for them to have some bigger items, or some iconified items,or somebody wants to minimize mouse-movement or wants to have better accessibility on touch-devices and would probably prefer a circle-menu�
But it is impossible to find a solution were everybody would agree, either we make it configurable, or there will never be any improvements in that menus.