Improving the KDevelop UI
Lasse Kärkkäinen / Tronic
tronic2 at sci.fi
Fri Apr 15 18:53:04 UTC 2005
KDEVELOP UI REDESIGN SUGGESTION
-------------------------------
Major problems:
- Too many buttons everywhere (UI clutter)
* Hard to fit them on screen
* The application feels difficult to use
- Too many icons to remember, no text on buttons
* Not possible to add text because the buttons would not fit anywhere
- Right vertical tab bar is almost empty
* The main reason for the existence of this bar seems to be that there is
not enough space in the bottom one
- Vertical tab bars are difficult to use
* Tab title text is not displayed
* Setting it to display the title (of the selected tab) makes the
situation even worse
- UI is very dynamic (panels pop in and out all the time)
* Confusing and possibly annoying
The bottom bar currently includes own "tab" for every possible tool. There
is one for grep, one for CVS, one for SVN, etc. There's even a Konsole
window down there. Clearly many of these actually share their purpose. For
example, tabs that are basically terminal windows - compile logs, gdb, the
application running, ... - could mostly be combined into a single shared
tab. Further reduction of clutter can be accomplished by:
- Using dialogs for functions instead of the tab panels
* Useful for SVN/CVS commits, etc.
- Using temporary tab panels that appear only when the function is active
* Useful for Search & Replace
- Using temporary tab panels that appear when the function is activated, and
that are soon after closed by the user
* Useful for grep
Konsole tab should not be required. It is clearly a separate application, so
the user may run a real Konsole, should he need one. Maybe add a
"Terminal"-button in the menus or the top toolbars, if this seems like an
important function (to open it in project directory).
UI mode switch to reduce clutter. Many things are only needed when the app
is running in debugger and serve no purpose otherwise. Similarly, when it is
debugged, one cannot modify or rebuild it, etc, making some functions
unavailable. This clearly calls for two separate modes. There could be use
for other modes too, even now, or in the future.
Left vertical tab bar contains some functions that really belong to the file
menu and optionally to the top toolbar. New file and file selector panels
are such functions. Project file browsers could be combined into a single
panel where one can choose whether to browse by file type, or by tree.
Bookmarks panel is something that I do not understand at all (what is the
purpose of this thing?). Watches is not related to project browsing, so it
should go where the rest of the debugging stuff go.
The class browser toolbar in the top does what the class browser (tree) on
the left toolbar should be doing, and as such, should probably be removed in
favor of the tree view.
In general, hide any panels that are only used by certain functions, that
are not active right at the moment. This would especially apply to the
"Replace" panel in the bottom. The user cannot do anything with this thing
except when he is doing a search/replace.
As requested by annma (#kde/Freenode), I redesigned the UI. I chose to
follow the K.I.S.S. principle (less is more) in order to get a simple
user-interface that doesn't get into the way, but that still offers all the
functions. I also tried to follow the normal cross-platform HID that people
are familiar with (in contrast to common KDE practices).
This is by far not a complete design, but it still is something that one can
easily build on. Thus, I request feedback from all of you. If you feel that
I missed some function that you need all the time, or that there are other
points to improve, don't hesitate to post your ideas. Also, should you feel
that my design is inferior to the design in use, please let me know why.
There are currently two modes (edit mode and debug mode), which get
automatically switched whenever user starts or stops the debugger. In the
following drawing I have included "(mode selection?)" in the statusbar. This
could be a dropdown or something that simply allows getting to the other
mode without having to find the proper function to go there. However, I am
not so sure of the positioning of this control (status bar is kinda odd
place to place controls in), and thus the question mark.
The scetch drawings are a bit out of scale due to ASCII limitations (in
particular, the edit area is supposed to be significantly wider).
EDIT MODE
---------
This is the mode where KDevelop would normally be in.
[-] ExampleProject - KDevelop [_][^][X]
| File Edit (...) |
+--------------------------------------------------------------------------+
| (project toolbar) | (build/run toolbar) | (kdevelop toolbar) |
+--------------------------------------------------------------------------+
+-------+-----+-------------+ +----------------------------------------+
|Classes|Files|Files By Type| | (edit toolbar) |
+ +-----+-------------+---+ +----------------------------------------+
|+-----------------------------+| | ^|
|| [-]## Project ^|| | #|
|| [+]## FooClass #|| | #|
|| [-]## BarClass #|| | #|
|| +-## run() #|| | #|
|| #|| | #|
|| #|| | #|
|| #||=| (edit area with #|
|| #||=| its rulers, etc) #|
|| #||=| #|
|| #|| | #|
|| #|| | #|
|| #|| | #|
|| #|| | #|
|| #|| | #|
|| #|| | #|
|| v|| | v|
|+-----------------------------+| |<#####################################> |
+-------------------------------+ +----------------------------------------+
+--------+---+-------------+ |
|Messages|Log|Documentation| (possibly other tabs) |
+ +-----------------------------------------------------------------+
|+------------------------------------------------------------------------+|
|| (listbox of compile errors, or whatever is relevant at the time) ||
|| ||
|| ||
|| ||
|+------------------------------------------------------------------------+|
+--------------------------------------------------------------------------+
| (mode selection?) (status bar) |
+--------------------------------------------------------------------------+
Edit toolbar is quite obvious: it contains all functions that apply to the
document being edited under it. This would include cut/copy/paste, replace,
save, ...
Project toolbar contains similar functions on a higher level. New class,
project settings, etc. It also contains the commit/update options for
working with the repository (project settings determine which kind of repo -
no separate buttons for SVN and CVS).
Build/run toolbar contains, in addition to what the current one contains,
also options for starting in debuggers (gdb, valgrind). It also contains a
terminate-button that is greyed out if the application is not running (nor
in debugger).
Finally, kdevelop toolbar can contain functions that do not affect the
project, but that control the environment. The "Settings|Configure
KDevelop..." option would be a good candidate. What comes to the font size
buttons, those don't really belong here (one goes to the options dialog to
configure the font size, type, colors, et cetera, et cetera).
The toolbars are designed so that they can display text under the icons on
moderately sized screens. In other words, there cannot be too many options.
The purpose of a toolbar is not to duplicate all the functionality that is
already available from the menus, but to offer quick access to the commonly
requested options.
DEBUG MODE
----------
When a debugging session begins, KDevelop will move into another mode. This
mode clearly requires different set of functions, so a different set is
provided. The edit toolbar on top of the edit window will get replaced with
the debug toolbar. Also, the bottom tab selection changes heavily. Compiler
logs or errors are no longer relevant, so those should be hidden. Instead,
now we want watches, stacktrace or whatever data we may want to monitor from
the debugger. Optimally these should not only be available as tabs, but as
detachable panels. I.e. they could be inside a tab, on edge of the window
(say, on the right hand side of the edit area, that is otherwise unused), or
freely floating little windows. Dunno how flexible KDE/Qt is in these
things, though.
This mode will accept setting breakpoints by clicking on the ruler next to
the source code. The symbol (or color) to denote breakpoint is only
displayed in debug mode, not in edit mode. Editing the source code is not
permitted in this mode¹.
[-] ExampleProject - KDevelop [DEBUGGER RUNNING] [_][^][X]
| File Edit (...) |
+--------------------------------------------------------------------------+
| (project toolbar) | (build/run toolbar) | (kdevelop toolbar) |
+--------------------------------------------------------------------------+
+-------+-----+-------------+ +----------------------------------------+
|Classes|Files|Files By Type| | (breakpoint/step/debug toolbar) |
+ +-----+-------------+---+ +----------------------------------------+
|+-----------------------------+| | ^|
|| [-]## Project ^|| | #|
|| [+]## FooClass #|| | #|
|| [-]## BarClass #|| | #|
|| +-## run() #|| | #|
|| #|| | #|
|| #|| | #|
|| #||=| (edit area with #|
|| #||=| its rulers, etc) #|
|| #||=| #|
|| #|| | #|
|| #|| | #|
|| #|| | #|
|| #|| | #|
|| #|| | #|
|| #|| | #|
|| v|| | v|
|+-----------------------------+| |<#####################################> |
+-------------------------------+ +----------------------------------------+
+--------------------------------------------------------------------------+
+--------+-------+-----+ |
|Debugger|Watches|Stack| (these tabs are just examples to give the idea) |
+ +-----------------------------------------------------------------+
|+------------------------------------------------------------------------+|
|| (terminal window displaying the interface of gdb) ||
|| ||
|| ||
|| ||
|+------------------------------------------------------------------------+|
+--------------------------------------------------------------------------+
| (mode selection?) (status bar) |
+--------------------------------------------------------------------------+
One thing that I did not display in the drawings is the tab bar of the edit
area. I think that this feature should be configurable (whether to use that
bar or not). If it was used, it would work as a "favorites" bar - a quick
way to access those few files that are actively being worked on. This way
the user does not need to find the file in the class/files browser every
time. However, the management of this tab bar should be as automated as
possible, as users will never do that by hand (GNOME UI design team, among
many other people, found this out the wrong way). This could be accomplished
by setting a maximum number of open tabs (so that they still fit in there
nicely) and by always closing² the one that has not been touched for the
longest time³.
Another thing that really should be taken care of is "quick hacking".
Currently it requires a lot of work to write and compile a hello.cpp. One
has to choose license types, versioning system, etc, etc... It could be
helpful if there was a way to just edit a single source code file and then
compile it, without going thru the pain of creating a project, the autotools
stuff and everything. This would eliminate the need to use nano or emacs
along a fully featured IDE.
Footnotes:
¹) It might be helpful to be able to switch into edit mode without
terminating the active debug session, and then, later, return to the
debugger. In this case none of the changes made in edit mode would affect
the running code seen in debug mode.
²) Closing the file would merely mean removing it from the tab bar. The
editor would still remember the cursor position, the undo history, etc, as
long as the file is still part of the project.
³) A more complex system could be used too: if user opens a file (via class
browser) and makes a single edit, then goes to work on some other files and
doesn't return to that one, it is likely that he isn't going to do that
later either (any time soon, at least). Thus, it might be wiser to remove
this file instead of the one that has not been touched in the longest while.
Typical scenario: a little change that is required in every file of the
project - user will open each file, make the change, the abandon the file.
After doing them all, he wants to return to the file he was working on.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20050415/10ec6b93/attachment.sig>
More information about the KDevelop-devel
mailing list