[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Context menus (an idea for summer of code?)
From: Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date: 2005-06-13 19:39:39
Message-ID: 200506132139.39308.thomas.friedrichsmeier () ruhr-uni-bochum ! de
[Download RAW message or body]
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 <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic