[RFC] Context-Menu Handling in KDevelop4

David Nolden david.nolden at art-master.de
Wed May 9 13:35:26 UTC 2007


On Wednesday 09 May 2007 14:51:09 Andreas Pakulat wrote:
> On 09.05.07 13:05:11, David Nolden wrote:
> Remove that stuff, for example the editor-things in there are not
> needed, IMHO (cut,copy,paste at least). Bookmarks, does anybody need the
> bookmark stuff in the context menu when we have a editor-sidebar to add
> a bookmark? I don't think so. Undo/Redo don't belong there either.

Ok that's what I think too..

> All in separate submenus.

But how will we decide which ones go into a submenu and which ones stay at top 
level? Sounds like a static version of the algorithm I was talking about ;)

There's one other thing we might do to improve usability of a big menu:
Make the text of less recently used entries more greyish, so the most 
important entries catch the eye faster, and you're less distracted.

I've seen that somewhere but cannot quite remember where, I think it was 
helpful.

That would be another reason to collect usage-statistics. We could also keep 
separate statistics for each perspective, maybe even for each project.

In the end we don't have to decide how exactly we build the menu right now 
anyway. The important thing is that the menu-building algorithm has enough 
information so we can improve it later, once we have enough menu-entries so 
it gets useful. For example we'd need a document-independent 
identifaction-string for each menu-entry. It would be easy to pass such a 
thing using QAction's data() member.

greetings, David





More information about the KDevelop-devel mailing list