KDevelop UI cleanup initiative

[Jens Dagerbo]

Hi,

I'm sure most would agree the default KDevelop UI is a bit "busy". This is a 
problem I think we should attempt to alleviate in KDevelop-3.1. The busyness 
is caused by several factors:

1. The default loading of all plugins.

 A new users first start of KDevelop with a C++ project loaded will have every 
available plugin under the sun loaded, including four VCS plugins and support 
for Gameboy development. It's hard to fault his/her feeling that KDevelop is 
"bloated", even if he/she is wrong.. ;)

This particular problem could hopefully be fixed with a little less 
enthusiastic loading of plugins, something I'm working on.


2. The fact that all toolviews are always shown, even when they don't contain 
anything.

It would for instance be nice if the debugger plugin didn't show all its 
toolviews when the debugger isn't running as they are completely useless 
then. And in fact, it does hide them, but they don't disappear. This is a 
problem of the isolated to the IDEAl UI mode, as the other modes can hide 
toolviews without removing them. I suspect we won't solve this, but it would 
have been nice. :)


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.


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. :)

We need to resist the urge to put everything into menus just because we can. 
For instance: there is currently at least five(!) ways of closing a file that 
is not the active document. (add at least 3 more ways to do that). Can we say 
"enough"? :)

On my personal shit list:

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

# 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.

# "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.

# 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.

# 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.

# 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!!

# 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?

# 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.

# 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.

# Tools -> Difference Viewer... - I honestly don't see what good this is. So I 
can look at a diff, so what?

# 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"?


There are probably more..

Opinions?

jd 


[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.

- 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.

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

- 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.

// tobgle