[RFC] Context-Menu Handling in KDevelop4

[Andreas Pakulat]

On 09.05.07 06:02:23, Jakob Petsovits wrote:
> 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.

I guess you see my problem with that: Plugin author A thinks his plugin
is great so he gives it a weight of +20 to be found at the top of the
list... And we can't do anything about this.

> > > 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.

While I do think that having the items you use often at an easily
findable position I also do hat the windows program menu which hides
entries if you don't use them regurlarly. I do understand that its bad
if you want to point somebody at the 3rd item from the top, however I
never told that anybody. IMHO its much more common to point somebody to
the item that has label Foo and it should be in the lower or upper part. 

I don't follow David to extract items from a submenu, that will indeed
be a usability and support nightmare.

> > > 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.

That sounds like a good idea. I have to say Jakob you've got really good
ideas about usable GUI's :)

Andreas

-- 
You will lose your present job and have to become a door to door mayonnaise
salesman.