[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