Menu-Structure

[David Nolden]

Am Mittwoch 17 Februar 2010 13:30:20 schrieb Andras Mantia:
> On Wednesday 17 February 2010, David Nolden wrote:
> > But look into the kate "Tools" menu. Does _any_ of the entries fit
> > into the global "Tools" menu of an IDE? I think, no. It contains
> > encoding-settings within the current editor, mini-utilities like
> > "join lines" that would better fit into the "Edit" menu, and such
> > stuff.
> 
> I agree, that's why I wrote that if you focus on katepart only, it is
> possible to reorder the menus, as you know the action names, so you can
> come up with your custom XMLGUI file.  Part of the Tools are editor
> settings related, part of them are Editing related. You are at a
> Kate/KDevelop sprint, you can discuss this with the Kate guys to fix on a
> lower level. :)
Actually I've implemented the restructuring in another way: All actions that 
come from an embedded kpart are remapped to different positions according to 
specific rules. Of course, this still requires us to know about the action-
titles to correctly map specific actions into specific menus.

> > Anyway we have to do something about it. Even if the bookmarks were
> > global, then I think they are not important enough to blow up our
> > main menu by adding a new entry. In that case, they should go as a
> > submenu into "Navigation" or something like that.
> 
> Yes, I suggested that. :)
> 
> My biggest problems with editor menu (in order of importance) are:
> - there is an Edit and Editor => confusing
> - missing View menu
> - editor settings is in a place where I'd not expect to be. I'd expect
> all settings dialog that affect the app globally to be in Settings menu.
> - Editor has only a bunch of submenus

All these are really easy to fix (it just means changing a few mapping rules), 
if we would find a consensus on how it should be. I'm unsure though. Is the 
"View" menu really important enough to be a top-level menu? If we want to keep 
the top-level menu usable, we've got to keep the item-count within specific 
bounds.

And putting "Edit" into "Editor" is not an option either I think, so the only 
thing we could do to fix that problem would be giving the "Editor" menu a 
different name, but nobody came up with something better until now. Actually 
we could think about renaming "Editor" to "View", as all the items in there 
are related to the current view.

The "Configure Editor" would be easy to move into the settings menu, but I 
found it a bit strange to have it there. That item is somewhat a mix: It is on 
one hand global, but on the other hand it is highly related to the currently 
active view. For example, when I switch to another embedded view (for example 
a designer-component), I wouldn't expect the contents of the "Settings" menu 
to change due to that.

Greetings, David