[RFC] Context-Menu Handling in KDevelop4

[Jakob Petsovits]

On Wednesday, 9. May 2007, Andreas Pakulat wrote:
> On 08.05.07 21:22:22, Jakob Petsovits wrote:
> > Wouldn't it be possible to add a "weight" property to such an entity
> > (either menu entry or plugin, whatever is more reasonable) and sort the
> > context menu based on that property?
>
> Well, code wise no problem, however who gets to decide which entry gets
> which weight?

The plugin itself. That may not be the most ideal solution for every user out 
there, but this way we can handle grouping in a better way than alphabetical 
while providing extensibility and not having to hardcode anything in the 
shell. For the plugins maintained by the project itself, we can assign 
sensible default weights.

> > Sorting the menu dynamically will be phenomenally bad from a usability
> > point of view, you lose all reliability of what you can expect where.
>
> Well, its not completely random in kdev3 - AFAIK. After all the editor
> context menu looks the same everytime. I guess the order is set by the
> list of plugins in the profile.

Yeah, that's not what I meant anyways - I was opposing ordering the entries 
based upon how often they are selected. Ordering by plugin load order is 
certainly not optimal, but not too bad either.

> > Also, scrollable menus are ridiculous, because once you've got so many
> > menu entries that you need to scroll, your menus are a chaotic mess
> > anyways. (The rule of thumb says that menus should not contain more than
> > 7 items, if possible.)
>
> Well, then we need to make sure to never populate a context menu or menu
> in general like the custom makefile manager did in KDev3. It populates
> the targets menu under Build with all targets it can find in the whole
> project. This list is extremely huge and would clearly benefit from such
> scrolling things.

Yeah, that one's hard, because in many cases it just contains a few items.
But rather than getting it a scrollable list, we should aim to make the list 
shorter and provide a good overview - after all, even if there are many items 
provided, you don't need more than just a few in the overwhelming majority of 
all cases (statistics made up spontaneously).

So, how about
- Add a separator and a "More Build Targets..." item to the bottom of
  the menu, the latter one bringing up a menu where you can configure
  which targets you want to show up in the menu or build them right away
  directly from there.
- If there's only up to 5 targets to be shown, auto-populate the list with
  those (and show the dialog entry nevertheless).
- If there's more than 5 items to be shown, auto-populate the list with
  "all" and "clean", and leave showing more targets to the user.

> The same goes for the navigation stuff in KDev3's editor context menu
> (if that still exists, didn't check lately).

That one doesn't deserve to be a context menu, really. It always has got a 
crapload of items, and it's always too much to grasp anyways. Imho, it's 
better to get rid of it for good and add its navigation abilities into other 
facilities where appropriate, like a tool view, or QuickOpen (but I guess 
that already does the job), or some popup listview like the autocompletion 
list.