[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Context menus (an idea for summer of code?)
From:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2005-06-15 11:10:41
Message-ID: 200506151310.41365.thomas.friedrichsmeier () ruhr-uni-bochum ! de
[Download RAW message or body]

> > void KontextMenu::popup (SomeType list_of_contexts_to_show, QPoint
> > position);
>
> Where do you define how to handle that list?

Not sure, what you're asking. I'll answer the question below instead. If this 
is a separate question, please reword.

> Or a different question:
> Lets say you have four types of contexts in Konqueror and you have four
> context menus in the XML GUI file.
> Wouldn't that be a lot easier to handle than some abtract context thing?

Yes and no. on the one handit would indeed be easier to implement in the first 
place. On the other hand you now have four context-menus to maintain, with a 
considerable number of options which are in fact overlapping between the four 
contexts. That's why I'm rather thinking about defining options structured by 
context and then to have a generic mechanism for "merging" those contexts on 
the fly. This mechanism would be provided by the KontextMenu-class, and all 
the application programmer would have to do is call something like the 
function-mockup above.

I simply think, introducing an organization by contexts is the most natural 
thing to do. A context menu for context(s) "link and image and frame and 
web-page" is neither just an unstructured collection of menu-entries, nor is 
it a static list which is completely unrelated to the menu for context(s) 
"link and image and web-page (no frames)".

Also, as mentioned in another mail, this sort of organization will allow for 
an easy way to change certain aspects by configuration, like having captions 
in the menu for each context, or to e.g. place the image-related options in a 
submenu instead of placing them inline in the context menu, etc.

Of course there are many ways to conceptualize the same idea. It would also be 
possible, for instance, to create a context menu that just contains 
everything, but assign some flags/tags to each option, and add a mechanism to 
"filter" the menu according to those flags/tags.

As I said, this idea is not elaborated at all, but I hope somebody else will 
find it interesting enough to turn it into well thought out concept.

> Btw.: you seem to have replied to your own posting instead of mine. Maybe
> you didn't use the "reply to mailinglist" action (shortcut L)?

Yes, that's true. The reason is, that I was not subscribed to the list (too 
much traffic), and hence did not receive a copy of your posting. So instead I 
just replied to the mail I sent myself and copied your reply from the 
web-archive. Now, for the purpose of discussing this idea, I have subscribed.

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]