KDevelop UI cleanup initiative

[Sascha Cunz]

Hi,
On Sunday 30 May 2004 03:38, Jens Dagerbo wrote:
> 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.

Woo, you kicked that objective public. I bet you're gonna have a discussion of 
similar size that was raised related to template changes. - And i'm gonna 
start with a few of the things we talked about in irc during the last half 
year:

Well, basicly this boils down to the point: how do we know when to load which 
plugin. This in turn raises these things:

  loading "foo" could obsolete loading of "footwo"
    Could be the case, if both foo and footwo provide the same functions;
    CTAGS vs CTAGS2??

  loading "foo" could prohibit loading of "foothree"
    Could happen, if it was known that two plugins won't work together.
    i.e. "old cvs support" and "cvsservice"; maybe this is the same case as
    the first one.
    
  loading "foo" could depend on "foofour" being loaded
    No need to have a valgrind loaded, if no language part is loaded which
    creates a "valgrindable" output - i.e. an executable.

I think we all agree that the approach of a "bad-list" is not what we really 
want to have. So we should turn that into a "good-list", which contains a 
list of plugins being loaded with the project.
This list would have to be checked against the available plugins at project 
loading (to see if it is actually still a sane configuration)
Creating such a list would involve changing the DOM at project creation time - 
A thing we currently do not support. Though, it might be fun to have :)

With this approach, we could be a big step closed to have support for 
downloadable plugins. But i think there has to be a few things to be done 
before that.

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

Yes. Makes no sense to have the valgrind plugin visible unless one at least 
started one valgrinding task. Same for: grep (actually any other output view)

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

Won't we? Is there a big problem i do not see? We could create a 
slotPrepareDebugging and a slotStopedDebugging. Those slots would create the 
debugger ui or destroy it. If i'm missing something here, please tell me!

While writing this mail, i remembered my try to put all file related tool 
views into one toolview: Actually it is "the core" that says what toolviews 
are visible and which not. So i doubt we cannot hide them in IDEAl mode. We 
could at least do like we do with AutoHell Manager and QListViewItems of it's 
sub projects.

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

Agreed without any addition.

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

Where should we add our features else? Just to compare to MSVC: MSVC has a 
submenu called "special" in the edit menu. There are things like "Reformat 
source" and such. Stuff that is really rarely used. We should start using 
such.
I do not want to have lots of good features hidden in deeply in the shortcuts 
configuration ( like MSVC has on the other hand, too ). :)

> 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"? :)

Yes, we can - and should.

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

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

For Close All Others i totally agree. Close All should be available through 
window menu. I would like to have a "close" in ECM; but i am not sure, if it 
really belongs there. If we're in need of space in the ECM, we should remove 
it. If not, we should let it there.

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

Could be solved with the above debugger suggestion.

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

One should be able to configure that. People who are actually working a lot 
with plain C projects, usually will have a lot of matches to man or info 
pages. In a php project you won't ever get a match on those.

I still cannot believe that there is no way to build the ECM from XMLGUI. If 
it can't we should work for that to come in KDE4. XMLGUI is the nicest way of 
creating a gui that i've ever seen. But lacking of support for dynamic 
context menus is a damned big lack.

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

I actually use this a lot, in ECM - not via Shortcut. Most of the time i do 
not even remember the short cuts.

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

Full acknowledge! What about something like the quick-open feature? I already 
know who will implement this... :-)

> # 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, i think this is a good approach. We should stick to that new one.

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

emerge -C KMDI # then :)
But yeah, these should vanish as menu entries. But not as sbhortcuts!

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

Let us think about this issue, when we actually improve vcs support. This is a 
totally different and very complex issue.

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

hmm, never used it - does that imply it is useless?

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

What do you talk about here?

> Opinions?
Lots :)

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

So building and cleaning the API documentation is not a build proccess? i 
doubt that and think that these are good where they are and should remain 
there.

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

hmm, here it does nothing - How does it acutally work? If it is, what i think 
( "Create a new member to an existing class" ), then it should be available 
via ECM when cursor is inside a class declaration.

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

Makes sense.

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

Will be more than appreciated!

May i add:

- we should rethink all our default short cuts. There are some that are so 
damn ugly... Depending on the type of keyboard you use, Alt+Ctrl+Shift+L 
needs two persons to press :)

- File Create does IMHO no longer need an individual toolview; I recently 
changed the Toolbar action to have a popup menu. Though, it was always a good 
thing, but as ugly as can be.

Cheers Sascha