KDevelop UI cleanup initiative

[Alexander Dymo]

> 1. The default loading of all plugins.
> This particular problem could hopefully be fixed with a little less
> enthusiastic loading of plugins, something I'm working on.
Totally agree with your point.

> 2. The fact that all toolviews are always shown, even when they don't
> contain anything.
In case of debugger, agree. See my comments below.

> 3. The toolbar mess.
> We have a lot of bugs related to the toolbars (for instance:
> http://bugs.kde.org/show_bug.cgi?id=79793). I have no idea if we're doing
> something fundamentally wrong somewhere or if the framework is busted, but
> we sorely need someone who understands this issue to take a look at it.
Something is really broken here. I'll try to investigate if this is our fault.
I refer here to following problems:
- after project reload actions disappear from build toolbar
- toolbar configuration/position is not saved properly

> 4. The large amount of menu entries, many of which are confusing and
> perhaps in the wrong place. This is the main point of this mail. :)

> # The Closer plugin - this serves no purpose now that the FileList can do
> the same thing (and more). I say we kill it.
I'd say we disable it for compilation.

> # Close, Close All, Close All Others are in both the File and Window menu.
> Close and Close All Others are also in the Editor Context Menu  (ECM).
> I guess the File menu is more or less standard, I wouldn't mind them gone
> from the Window menu and at least the "Close All Others" form the ECM.
> Given that "Close All Others" is a special case of selective close anyway,
> we could just dump it completely and refer to the FileList for this
> functionality.
Remove from window menu: I agree.
Remove from ECM menu: veto ;) Close all others is a very special case of
selective close and file list won't help. File menu is too far from the mouse
position. Close should stay too because we don't offer context menu on
tabs due to kmdi. I've tried to do that and experienced tons of
problems ;).

> # "Watch" in the ECM. How often is that used? Very close to never. At least
> it should be made to only appear when the debugger is actually running.
I object. It should be possible to create a list of watch variables before
running the debugger. I consider this as a normal practice. More to say,
watch tree shouldn't be disabled even if the debugger is not active.
The same applies to breakpoints view. 
Summary:
debugger views which should be always visible:
	variable/watch
	breakpoints
debugger views which should be hidden if debugger isn't started:
	frame stack
	disassemble
	gdb
	

> # The new Documentation plugin is very cool, but what are the chances that
> the current word will actually find a match in a man or info page? IMHO,
> "Manpage", "Infopage" and "Look in index" should all be gone from the ECM,
> they are simply going to match too rarely to justify a context menu entry.
> "Search" is different.
Look at manpage and infopage can be removed, i agree. I will remove them and
use current selection in editor in manpage and infopage dialog available from
help menu.
Remove "Look in index" - I object, in fact this is more usable than search.

> # Switch Header/Implementation - a fantastically useful action, one which I
> use all the time as a shortcut, but it's of debatable value in the ECM. I
> say we remove it.
No, I'd say ECM is the natural place of such an action. It is really the
context action for current file.

> # Go to Declaration & Go to Definition in the ECM - this is quite horrible.
> I use a 1600x1200 resolution, and most of the time it fills my screen. I
> can't see how anyone actually uses this feature. The functionality is
> great, but should be offered through other means. Remove!!
Wait ;) I'll come with a better solution, this is in my plan.

> # Go to ctags Declaration & Go to ctags Definition in the ECM- these are
> actually not too bad, but will automatically disappear with the retirement
> of the old CTAGS plugin. Should the new plugin offer both entries?
> Currently it only adds one entry, and only if the current word is actually
> a known tag. Is this a good approach?
Yes, should be implemented. Very usefull. If the current word is not in the
tags database, there is no necessity to put "go to..." entry.

> # View -> Tool Views / Tool Docs and whatnot - of very questionable value
> in IDEAl where toolviews can't be hidden, only undocked and the tooldocks
> are readily available through buttons and shortcuts (such as they are). I'm
> not sure we can remove these though, IIRC they are merged in from KMDI.
Then we let them stay ;)

> # Tools -> Version Control -> CVS service (or other vcs) -> action submenu
> - as a menu that acts on the active file, this is quite nuts. The VCS menu
> is already accessible through the ECM and the FileContext (which is almost
> everywhere). I say we remove it from the already crowded Tools menu.
Don't know.

> # Tools -> Difference Viewer... - I honestly don't see what good this is.
> So I can look at a diff, so what?
Maybe that can be of any help. Don't know.

> # There are at least seven (eight with the old CTAGS part - I guess the new
> one should have one as well) actions in the menus that are various forms of
> navigation, more will probably come. Perhaps a seperate menu -
> "Navigation"?
Maybe we can have separate "Code edit", "Code  navigation" and
"File navigation" menus. But maybe this is not a good idea, we should just
clean the existing menu structure.

> [Yup.. more. the following added by Tobias Gläßer]
> - The 'Build' - and 'Clean API Documentation' entries make more sense in
> the Project than in the Build menu. The build menu should be reserved
> for the actual code building proccess. API documentation is closely
> related to projects.
No, building documentation is build action, it's done not by KDevelop.
And in fact, it builds documentation from code ;)

> - The 'Make Member' in the edit menu is useless, because Joe developer
> won't find out how it works. Its functionality is context related,
> therefore it may be considered to put it into the context menu. The
> functionality will, if discovered, by the most developers used with a
> shortcut. Letting it in the 'edit' menu just for the possibility that
> someone discovers it is not a good reason and therefore I want to get
> rid of the menu entry.
Remove is not a good solution. Other places aren't as good as edit menu.
Let it stay.

> - The 'Project Distribution & Publishing' entry should be moved from the
> 'Tools' to the 'Project' menu. It should then be renamed to
> 'Distribution & Publishing'.
Agree.

> - The 'Tools' toolbar is useless at the moment, therefore I want add
> icons for some of the entries in the 'Tools' menu, like valgrind, and
>  add this to the toolbar.
I'd say remove the toolbar.

-- 
Alexander Dymo
ICST Department, National University of Shipbuilding, Mykolayiv, Ukraine