KDevelop UI cleanup initiative

[Jens Dagerbo]

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

Exactly.

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

I'm not following.. the debugger plugin is responsible for both starting the 
debugger and creating it's UI. If you suggest it should hold off creating 
most of its UI until the debugger is started (and destroy it afterwards) this 
is not only a large change, it seems like overkill for what is really just 
hiding a few widgets.

The reason hide() probably won't do (IIRC) is that, unless I'm mistaken, the 
IDEAl toolbar buttons will not disappear when we hide the widgets. We would 
still have the "GDB" toolbar button visible for instance, and hiding the 
buttons is really the real objective.

However, now that Jowenn seems to have reappeared, maybe he has some 
suggestions. :)

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

And what trick is employed in the AM? :)


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

To be honest, if we could put most of kateparts actions in a "special" 
submenu, most of the menu bloat would be gone.. ;)

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

I guess this is where we differ. I want the menus to be "usable" (noone can 
argue with that ;) ) but as they become littered with things such as the 
toolview/tooldock entries (which are really only there for the shortcuts to 
be listed somewhere), the usefullness of the menu decreases rapidly.

IMHO, we should look at removings things which are 1) the least comfortable 
when used through the menu and 2) things which are clearly context dependent 
(standard File and Edit menus not counted)

The problem with the toolview/tooldocks entries is that they are more and less 
important in the different UI modes. I guess we could make a hack to remove 
them from the menu when in IDEAl mode only.


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

Could probably be solved even easier from the debugger plugin, assuming the 
code that puts in the "watch" entry knows how to figure out if the debugger 
is 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.
>
> 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.

C is only one language of the 10+ we support, and the man and info pages are 
easily reached through the Help menu. If not at least configurable (and off 
by default), I still think these entries should go.

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

Well.. agreed. :)

I know Anders Lund started talking about a user editable context menu. I don't 
know if he was referring to a generic tool, or a katepart thing.


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

You do? Who? I know at least 3-4 people who have talked about it. Me being 
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!

See above.


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

Yes, clearly. But why keep this nonsensical entry in the Tools menu? Its 
placement is in no way related its function. 

Actually, that's my point - it's too unintuitive placed in the Tools menu when 
it is in fact related to the active file.


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

At the _very_ least we should rename it. "Inspect diff file"?


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

Never mind. This is a bad idea, I'm convinced about that now.. :)


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

No real opinion here. 


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

Create a method declaration in the header, hit F2 while on the same line 
(perhaps inside the text, don't remember) and a method definition stub will 
be created for you in the implementation file.

This is a nice feature, but I vote we put it in the ECM, and only when it 
would actually do something (which is on a method 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.

Agreed.

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

Yes! More icons! :)

On this note, maybe we should make sure the various build managers use the 
same icons to do the "same" thing? Currently, the QMake and Automake managers 
have different icons for the same actions.


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

Well.. yeah. This particular shortcut I believe is defined by KMDI, but I 
guess we could override it. We'd just have to do it in a way that maintains 
any user override, if such exist. Nasty.

In general, the way we just "get" shortcuts from embedded kparts is a problem. 
A problem that needs solving, but probably not sanely so at the KDevelop 
level. IMHO, one sane approach (at least to some degree) would be for the 
kpart to not define shortcuts for its actions and leave this up to the 
embedding app. At least a way to easily clear the default shortcuts would be 
nice (maybe this already exists, I don't know all the ins and outs of the 
XMLGUI architecture)


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

Agreed. Personally, I would be glad to see it go. 

It does already support optionally hiding that toolview, but (at least last I 
looked at it) the code doesn't look completely finished and is apparently 
unmaintained for some time now.


jd