[RFC] Context-Menu Handling in KDevelop4

David Nolden david.nolden.kdevelop at art-master.de
Tue May 8 22:35:24 UTC 2007


On Tuesday 08 May 2007 21:22:22 Jakob Petsovits wrote:
> On Tuesday, 8. May 2007, Andreas Pakulat wrote:
> > > Can you even imagine how hard it
> > > will be to coach new users through the program or put up a FAQ
> > > considering that their GUI might be very different from yours based on
> > > their usage patterns?
> >
> > Uhm, the context menu is dynamic and as it currently stands the order
> > cannot be fixed, unless we sort the entries by alphabetic order. Else
> > the order will be the loading order of plugins.
>
> 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?
>
> Sorting the menu dynamically will be phenomenally bad from a usability
> point of view, you lose all reliability of what you can expect where.
>
> 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.)
>
> My vote goes for sub-menus with per-plugin  items, sorted by a weight
> number (say, -20 to +20).
>
> Regards,
>   Jakob

That's why I'm for a combined aproach: What about having the 5 most used 
entries at the top of the menu, then a separator, and then the per-plugin 
sub-menus?

It solves 2 problems at the same time:
1. You can find everything in a logical static position
2. When you use the same item again and again, you can find it in the dynamic 
part, and don't need to do all the mouse-navigation again and again.

If you wouldn't like it you could turn the dynamic part off, and you'd have 
exactly what you wished for. :)

I cannot guarantee that it would really be useful, but I'm sick of searching 
entries in a too long list again and again, and I don't think walking a tree 
of sub-menus again and again would make it better. So I think we should at 
least try it.

It would also be a nice experiment, because I think that the KDevelop's normal 
application-menus have the same problem.

greetings, David





More information about the KDevelop-devel mailing list