[RFC] Context-Menu Handling in KDevelop4

[Jakob Petsovits]

On Wednesday, 9. May 2007, Andreas Pakulat wrote:
> 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.

I don't think this is the problem that you assume it to be.
After all, external plugin authors are supposed to be just as sensible and 
caring as we (the KDevelop plugin people) are, and I think we should not 
expect them to be egoistic about their plugins. They write plugins not only 
for themselves and their greatness but for their userbase, just like we do.

Besides, most (if not all) important plugins are residing in KDevelop's own 
repository, so one or two corner case I-am-so-great plugins won't make much 
of a difference, imho. If a plugin is going on someone's nerves by being 
placed on the top even if very unimportant, the users can still file a bug 
report against that one, and if it's external to KDevelop then I'd say it's 
not our responsibility to force them to not fuck up.

We could also issue guidelines, like, -20 to -10 for text editing 
functionality, -10 to 0 for code navigation, 1 to 13 for code modification / 
generation, and 14 to 20 for file and source code management / VCS.
(Just guidelines - they can be ignored if there's a good reason for it.)
That would make for a good start with outside developers who didn't take a 
closer look at the shipped plugins.

And if the plugin "default" really shouldn't suffice, we can still throw up a 
menu sorting dialog that can shuffle weight values, starting off with the 
plugin's given weight. But I'm quite confident that this won't be necessary 
here.

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

If I understand correctly, this feature is neither loved by users (e.g. 
http://discuss.fogcreek.com/joelonsoftware3/default.asp?cmd=show&ixPost=94078) 
nor by usability people. I am not a usability expert myself, so I might be 
wrong, but if we are to include something like this then I'd like to consult 
the kde-usability list beforehand.

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

Sure. If a plugin can be enabled and disabled, you can't make any definitive 
statement on where exactly the menu appears anyways.

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

So we agree on this one.

> > 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 :)

Nah, not really.
Just steal some good ideas from Eclipse, Drupal or whatever you're involved 
with, and think about how it fits into KDevelop ;)

Sincerely,
  Jakob