Hi all,

I've been pondering this idea for quite a while, now, but I've never found the 
time to elaborate it in detail or even write some code. Now, perhaps, with 
google's summer of code, today may well be the best time to just give a rough 
outline of my idea, and hope somebody will find it interesting enough to pick 
up and elaborate it.

Some disclaimers first: 1) I'm programming some KDE-apps, but certainly I'm 
not a KDE-god, and it's not at all unlikely, I may be missing something 
important.
2) I'll have to admit that I limited my search on kde-devel to the bare 
minimum, so maybe this idea has come up (and was debunked?) previously.
3) I'll be using konqui as an example, but please note, that I really don't 
have any idea on how stuff is implemented there. So please take those 
examples more as a metaphor to illustrate the point, rather than a true 
observation.
Those disclaimers aside, I still think I may be onto something useful, so here 
it goes:

RMB- or context-menus are a neat thing to have. Their purpose is to provide 
easy access to functions needed in a given situation, i.e. a certain context. 
Any good application will make those functions available by other means 
(keyboard-shortcuts, regular menu-entries...), too, but the context menu 
greatly helps usability by providing those - and only those - functions the 
user might want to use in a given context. Note me stressing the word 
"context".

Next let's see, what you need to do (as a programmer) to provide a context 
menu. In the easiest case you're implementing a single widget, and every time 
the user right-clicks in that widgest it's roughly appropriate to always 
dispaly the same popup-menu. So, what you do, is to create a popup-menu, 
populate it with menu-items, and show it whenever the user performs an 
RMB-click.

Things get more complicated quickly. Suppose your widget is a treelist of 
items, and you have two different scenarios: If the user invokes the menu on 
a valid item, options A, B, C, and D should be shown. If the user invokes the 
menu on the widget-background, options C, D, and E should be shown. Of 
course, now, when the user performs an RMB-click, you'll first have to figure 
out, what context is appropriate - that's no big deal and can't be avoided. 
What's worse however, is that now you'll either have to modify your 
popup-menu "manually" according to the context (showing/hiding, 
enabling/disabling options as needed), or you'll have to provide two 
different popup-menus, which, however share some options (C and D in the 
example).

Finally, in the real world, things get nastier, yet: Suppose when browsing the 
web with konqui, you RMB-click on an link, which is an image, which is in a 
frame, which is in a web-page. Now you have four different contexts for which 
to provide options:

1) Options for links, such as bookmark, open in new tab, save as...
2) Options for an image: view image, send image as, (reload image; not yet 
existant)...
3) Options for a frame: print frame, view frame source...
4) Options for a web-page: print, view source, back, stop animations...
(And I'm not even talking about different types of links and images!)

What I imagine, how this is dealt with in konqui, is some big nasty (and 
possibly nested) construct of if-statements, enabling/disabling options. And: 
There always is the problem of context menu bloat. You'll have to be careful 
in chosing the options you provide, and any way you do it you'll disappoint 
some users (either 'cause the menu is to complicate, or 'cause vital option X 
is missing).

So that's the problem statement. Now, what's the solution?

My proposal rests on the idea, that we need a dedicated KontextMenu-class (no, 
I won't debate the K), instead of creating/modifying some popup-menus, which 
happen to be shown on RMB-clicks. We're talking about context-menus, so let's 
provide the programmer with support for dealing with _contexts_.

So, we'd have a class KontextMenu, which is derived from KPopupMenu. There 
will be an API for this class to tell it: "Ok, there is a context called 
'image'. This context is associated with the following options: A, B, C. Next 
there is a context called 'link' with options C, D, E...". Then, when we 
detect an RMB-click, and have figured out the relevant context(s), we'll 
simply tell our KontextMenu which context(s) to show. The KontextMenu will 
take care of enabling/showing the appropriate options by itself.

Ok, so we've saved a few lines of code. Now what's the big deal?

The big deal is to create a solid flexible framework for the purpose of 
providing context-dependent options. Having such a framework will not only 
make life a little easier on the programmer. It will also allow to provide 
additional generic functionality for all context menus.

For instance, I for one, have greatly mourned the disappearing of the option 
"Open link in background tab" in konqui's RMB-menu. It was removed in order 
to reduce context-menu bloat. At the same time, I can't recall an instance of 
purposefully using the option "bookmark this link" - I rather open the link 
and then bookmark it, if I like it. Now, this is not to start a flamewar on 
those two options, but I'm sure something similar has occured to you before. 
The problem being that what's a good RMB-menu for user A is not for user B 
and vice-versa. Which leads to the question, why context-menus are not 
configurable the way toolbars are. I guess, part of the answer, here, is that 
no programmer will deem it worth the effort to include additional fallible 
if-statements in their routine to "create an appropriate context menu", and 
moreover providing a GUI to configure options. If we had a generic 
KontextMenu, however, all this would be a feasible one-time effort. The 
programmer would merely call KontextMenu::createConfigurationWidget () or 
whatever.

More uses than that might be thinkable of course. Maybe one day we want to 
display "captions" for options correspondin to a context? Something like:

Page:
  - print
  - view source
Frame:
   - print
   - view source
...

Having a KontextMenu working on _contexts_ rather that _options_ would allow 
us to implement this with relatively little effort. Etc., etc.

So, as mentioned at the start, this isn't an elaborated proposal, but I still 
think it's an idea worth considering. Any fundamental objections? Anybody 
willing to elaborate on this?

Thomas

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<