KDevelop UI cleanup initiative

[Sascha Cunz]

On Sunday 30 May 2004 14:44, Jens Dagerbo wrote:
> However, now that Jowenn seems to have reappeared, maybe he has some
> suggestions. :)
He said, he will have no time before linux-tag in Karlsruhe is through. That 
will be about a month.

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

Agreed.

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

Actually, i can see your points more cleanly now. Yeah, i think you're right.

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

Also agreed.

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

That is acutally not true. several standard indentifiers of several languages 
have man pages. As i remember from the top of my head: perl, tcl, python. For 
writing a bash script it might be the kicking feature.
Also: If i have to open the help menu and enter the identifier, then i could 
as well click on my kicker, open a konqui and enter the identifier there. I 
would automatically get a much better ui for browsing than kdevelop as to 
offer. So, if we move it to only appear in Help menu, we could as well 
scratch it completely.

It was just yesterday, that i discussed with a german sysadmin about writing 
bash scripts with VIM or kdevelop. Context related man page viewing was one 
of my best arguments for kdevelop - and you know, that vim is the executable 
on my system that gets most CPU cycles just below gcc...

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

Good to hear!

I just remeber myself saying, that if we ever happen to get good context 
menus, one of the kdevelop-devs will become a XMLGUI guru. I think this still 
applies.

> > > # 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. :)
Well, i assumed it would be the same person, that invented quick open :)

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

Yes. VSS Integration into MSVC is done by adding a submenu to the tools menu 
and some context menus. That is a horror to use. What i really want is a 
"VCS" menu. This should be the same as cervisia's "Advanced" menu. Maybe a 
little less, but i think you get the point.
Poorly, we will be able to adress this "in the right way" only after we did 
the VCS stuff.

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

Agreed.
Just a note: I was always thinking, if i could make the diff tool view to 
"undock" it's content into a new window in the main area. I never got the 
time for doing it, though.
But it is just plain imposible to view 2 diffs at the same time. Which is IMHO 
important, because i know no way (using the cvsservice plugin) to select more 
than one file and do a diff based on that selection.

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

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

Total agreement.

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

Hm, who was the guy that offered a new kdevelop logo few months ago? cies 
IIRC. Maybe we should ask him, if he can help.

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

Agreed. I do not start thinking about a unified project manager at this point. 
It would be a useless discussion :) But acutally, that would be the "sane" 
way to do it.

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

hmm, this sounds like you want to add a big constraint to what a KPart may 
expose. Maybe this could break a lot of stuff; even outside kdevelop.

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

Haven't seen that code yet. But also have never seen a ui for it - well, this 
means nothing in file-create. Who acutally knows that there is a completely 
different ui implementation, which is just imposible to activate.... :-)

Sascha