KDevelop UI cleanup initiative

[Steven T. Hatton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 29 May 2004 21: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.
>
Same with documentation in the DocView, as far as I am concerned.  It might be 
useful to. All I've looked at is really very good, but I don't need perl, 
Ruby, PHP, python, GTK, etc., etc., for a Qt/KDE project.



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

Then you won't like my next idea. ;)
> On my personal shit list:

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

Those seem like a natural feature for a context menu that lives in the tab.

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

This is the part you probably won't agree with.  I think close all others 
makes most sense in a context menu because the user's focus is right there.  
I also feel that it's a good idea to keep the collection of functionality the 
same between menu section.  For example, if there are /save all/, /save as/, 
and /save/ in the file menu, I believe they should be together anywhere else 
there is an option to save a file, as in the context menu.

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

I like it.  It's a clutter, blaster.  If I end up with a dozen or so files 
open, I start to get confuse as to which ones matter to what I'm currently 
doing.  Close all others is just a nice easy way to start clean with the 
current file.


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

Agreed.

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

That might be saying something else. :-)

I
> can't see how anyone actually uses this feature. The functionality is
> great, but should be offered through other means. Remove!!

I like the way the comperable options work in the class browser.  But that has 
its own problems.


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

One way to make them more valuable would be to assign some fixed shortcuts to 
them and display the hot&keys.  Very much prefer using keystrokes to grabbing 
the mouse and clicking to open things such as the compiler messages widget.

> # Tools -> Version Control -> CVS service (or other vcs) -> action submenu
> - as a menu that acts on the active file, this is quite nuts.

You mean I'm not the only one wondering what the heck that's all about?

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

Why do I have all three of these VCS options all the time?  I will typically 
only be using one per project.  AAMOF, I have only been able to make one of 
them work for me.

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

If I can pull up a diff between the current and a previous CVS image, that is 
useful.  I use that feature in cervisia.


> There are probably more..
>
> Opinions?

I should have started looking at this earlier.  I need to look a the other 
responses.  But I want to get this off before it is completely OBE.

I have a bug in about refresh of a project. I hit another circumstance where 
that would be handy today.  The Automake Manager doesn't resynch if I go in 
and edit the Makefile.am by hand.  

One a somewhat related matter, The ability to sync the class view and the 
current document would be really nice, though with C++ that gets a bit 
complicated.  Having a way to expand the whole tree would be a helpful first 
cut.  I find it annoying to have to keep opening it.  I tend to work with the 
panel constantly opened, and try to use it to create all my member attributes 
and functions. If I could expand the tree, and browse it with keystrokes that 
would be very helpful.  I know some of that functionality is there.  And if 
you use is much you will see it needs some work.  I don't want to make a big 
long list.  That's why I say just a hotkey to expand it would be nice.

It would be really nice if there were fixed hotkeys for some of the tool 
views.  In particular, the compiler messages, and the problem reporter.  

Sometimes the pointer focus goes into a parallel universe, or so it seems, It 
would be nice if there are some kind of indicator to show what dock window 
has focus.

In general, it would be good to set more keyboard shortcuts by default.  I 
know it's a constant battle with the desktop to claim things such as 
Ctrl+Tab, or any combo with good mnemonics.

I could go on for a long time, but I think the objective is to tie up loose 
ends, not create new one.

- -- 
Regards,
Steven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAv/PwwX61+IL0QsMRArM7AKDwRzz3QqAiOqNI1q2tjLi02j+/bgCgutZ2
yT7kSvV4Oj5Kbri6321z3Xw=
=uZ5S
-----END PGP SIGNATURE-----