Zwabel’s Weblog

June 21, 2009

KDevelop4 UI: Areas, Working Sets, etc.

Filed under: KDE,KDevelop — zwabel @ 9:58 pm
Tags: , , , , , ,

General Progress
A lot is happening in KDevelop4 these days. Now it’s nearly already 2 Months ago that we had our developer meeting in Ukraine. We had a lot of fun, although for me the trip started two days late. I didn’t get my passport in time, damn. But once there, I got quite productive. Since I have limited time these days, that hack sprint motivated me to touch the one big outstanding architectural issue yet existent in the duchain. I knew it was a painful mammooth task, that’s why I kept my fingers off it for a long time.

I have implemented a special reference-counting mechanism for the duchain that uses the standard convenient C++ way of achieving the thing: In the constructor of an object, increase a counter, and in the destructor of an object, decrease it again. Now finally _everything_ in the duchain is reference-counted, even extreme light-weight objects like “IndexedString”, which is nothing more than a wrapper around an integer representing a string.

That object is used everywhere, and since the reference-counts are disk-persistent, increasing them is not as cheap as usually. So here’s the clue: It is only done when the memory-area the constructed/destructed object is in is actually marked as a “disk persistent” area, that will be stored to disk later, or is already on-disk. That means that it has near-zero runtime overhead for most of the object usages. During shutdown the objects are all sweeped, and the ones without a persistent reference-count are cleared away. The most complicated task was getting all the already existing duchain storage schemes work nicely together with such reference-counted containted objects.

I got it ready about 1 week after I was home again. Two weeks later it actually was stable. Anyway, it was worth it. :-)

Apart from this architectural thing, the focus is mainly on polishing now. Tons and tons of bugs and crashes were fixed.

Apart from bug-fixing, I’m trying to use my limited time to move KDevelop4 forward in some of the other areas that need it most. After all, a good C++ support alone is not enough of a selling point for an IDE, and I have some ideas about how KDevelop 4.0 should look. Also, I sometimes feel the intense need to do something “creative”.

Areas
Now KDevelop4 has a feature called “Areas”. From what I know it’s comparable to the Eclipse “Perspectives” feature with some slight differences.

Each area contains a distinct set of tool-views, and toolbars, tailored for a specific task (Currently we have “Test”, “Debug”, and “Code”). In difference to Eclipe Perspectives, areas may also contain different sets of files. We actually thought about renaming them to “Perspective” for consistency, but then again “Perspective” implies looking at the same thing just from a different direction, while an “Area” is actually a different working-space, like a different table, where you use different tools to work on different items. So we’ll probably stick with this terminology for now.

Before the hack sprint, there was a little dropdown list in the toolbar to switch areas. But in our opinion this was not very usable, given that we want areas to be a central part of our UI concept. You could never see what other areas there was, and you always needed one click too much to switch them. So we discussed different mechanisms for area-switching. My initial idea was quite simple: Use tabs. It’s the concept that fits best. Just some additional non-removable tabs somewhere at the top, and areas would be totally intuitive and logical to use. The others were a bit more in favor of using separate toolbuttons, and after I wasted a few hours trying to hack something together with tabs, I gave it up. Alexander Dymo then created area-switcher toolbuttons, probably similar to the way Eclipse does perspective switching.

However a few weeks after being home again, I started feeling that these toolbuttons don’t work. How is it intuitive that you click a toolbutton, and suddenly you have completely different files open? And how could we automatically switch the area when we start debugging, without making the user crazy? Also, toolbars are generally “optional”. And if we want to make Areas a central concept, we cannot make the area-switching optional. We shouldn’t give the user a chance to break his UI. :-)

So I started again doing mockups about how the UI could look, here’s the evolution:
http://zwabel.files.wordpress.com/2009/05/mockup.png
http://zwabel.files.wordpress.com/2009/05/mockup.png
http://zwabel.files.wordpress.com/2009/05/mockup3.png
Niko:
http://www.vivid-planet.com/upload/vertical-tabs2.png
Me again:
http://zwabel.files.wordpress.com/2009/05/vertical-tabs3.png
And the final version:
Mockup
Just by the way you may be wondering why there suddenly is so few wasted space: On the hack sprint, Alexander Dymo removed both status-bars, moved the editor-information(line+column) into the file-tab line, and moved status indication in the bottom toolbar into the bottom dock switcher, so both status bars are gone.

If you’re wondering about the additional highlighting of the current area tab: We were a bit worried that tabs in the top-right would be somewhat out of user focus, the user might not notice when the area automatically changes, and that it might also be a bit confusing having multiple levels of tabs in the same user-interface. The highlighting moves the thing more into the user focus so changes are directly recognized, increases general awareness, and makes it generally look like a different widget then the document tabs, which reduces confusion.

Now after all the mocking, which I actually just did to start some discussion and gather some ideas+opinions, I suddenly found the hidden QMenuBar::setCornerWidget function, which actually allows implementing the last mockup in a relatively clean way. I sat down for an evening, and ended up with exactly what you see on the last mockup. It needed some additional hacking to get the added highlighting, to have the icons on the left side while having a general right-to-left layout, and to make the tab separator line fade out to the left, but it works, and it is solid. And at least my personal experience shows, that this is very usable and very intuitive, while not wasting a single pixel.

So far so good.

Working Sets
A few years ago, shortly after I joined the KDevelop project, there was a lengthy discussion about tabs in general, and whether/how they could be made useful. The problem: From a specific count of documents upwards, tabs are completely useless to get an overview. And due to the easy navigation in KDevelop, it easily happened (and still happens) that suddenly 20 documents were open, making tabs completely useless. At the beginning of KDevelop4, some developers were tired of the uselessness of tabs, and completely removed them in favor of a dropdown list. However me and some others couldn’t live with that. The problem: You replace something that sometimes becomes useless with something that is always useless. There has always also been a document list toolview, that shows all currently open documents. Those who don’t want tabs probably use that. However, as I know from using kate, even a document-list becomes nearly useless from a specific count of documents on.

So at that time, I had the idea that instead of trying to create an utopic widget that allows easily managing an infinite amount of open documents, just allowing the user better ways of managing the set of documents he is currently working on, so he can easily keep the count of open documents in a tab-manageable area. My idea of achieving this at that point was using working sets. A working set is a specific set of files, the files you really work on. For me, when the open document-count grows into an unmanageable area, that usually comes from either working on multiple problems at the same time, or from a lot of browsing through different documents. The core development activity is usually only focused on a relatively small set of documents. A working set allows grouping small lists of documents together, archiving and restoring them, easily merging, splitting, duplicating, and easy moving of files from one working-set into the other. Such a mechanism would allow keeping the count of files manageable: As soon as you start working on another task, just close the whole current working set, and start your new task with a clean list of documents. As soon as you want back one of the old files or the old working-set, just restore it. Paired with a good user-interface, this might well create a new and more efficient paradigm of working.

My idea was that each working-set would be represented by a unique icon somewhere in a permanently visible part of the UI, so you can easily access them.

However since I was very busy with C++ support, I never came back to this idea. But now suddenly, that I was doing that area-switching stuff, it came back into my mind:
- Areas have different sets of documents, so if they should be really easily usable, it should also be easy to transfer files from one area into the other.
- Due to the area-tabbar I have added, there suddenly is a perfect place where those working-sets could live: At the left side of it.
- KDevelop4 also supports multiple main-windows. How to synchronize or move documents between them? Working-sets would make it a breeze.

Combined with the advantages above, this just created too much temptation for me not to try it. So within the last weeks I piece by piece created full working-set support in KDevelop4.

The hardest part was adapting the background management part of KDevelop4′s UI framework, and until a few days ago it suffered from frequent crashes. But now it seems to finally be stable, so I can announce it for you to try out.

How the UI looks now:
kdev4_ui_working_sets
At the left side of the area-switcher, you see the icons for all existing working-sets. Currently that is only two. The icons are taken from several other KDE Applications. In long term, we need a unique set of icons that are totally association-free in the software world for usage in the working-sets. But for now, the most important thing is that each set has a different icon. The area-switcher itself shows the currently active working-set within the switcher, so you see which working set is active in which area. Also there’s an additional working set icon left to the document tabs, to make clear that they belong to each other, and make it yet a bit clearer and easier to use.

When you click onto one of those icons, the clicked working set is loaded into the current area, or it is closed if it is the current set, allowing you to create a new one by opening a new document.

kdev4_working_set
When you hover a working set icon, you get a very useful tooltip, showing you the contained documents, allowing you to load or unload single documents with one click, and to delete or close the entire working set.

kdev4_working_set_2

kdev4_working_set_3
This is how it looks when you’re in the debug area, with a different working set open than in the code area. Working-sets are fully synchronized, so if you activate the same working-set within both areas, the areas transform into Eclipse perspectives, as they both always contain the same documents.

KDevelop4 Beta4
On Monday KDevelop4 will go into a mini-freeze with only bugfixes allowed, before releasing the next beta middle of the week. We want to make sure to release a high-quality and stable beta. We have released beta3 just a week ago, but that was a bit premature, as it doesn’t contain some features that we want feedback about, and there were quite a few important last-minute bug-fixes that we would have liked to add, but the release process was already a bit too far at that point.

31 Comments »

  1. Hi, I like a lot what I’m seeing in those screenshots, really. I might even try to copy some ideas for konqueror. But there just only one little thing I’d like to brought attention about and it’s the code coloring for syntax highlighting: having so many colors distracts the developer: I start to see colored glyphs instead of lines of code, and when I try to read something the color gets in the way, my brain can’t help it: when processing the input of my eyes, it processes so much color information that the code itself is more difficult to process.

    I know that the coloring is an easy way in katepart to tell the user that the parser is very advanced and thus can tell the difference about a lot tokens, I developed coloring support for a language, I added support for syntax highlting for LEA, see http://www.flickr.com/photos/17901580@N00/14917989/sizes/o/ . Too many colors there too. I suggest you take current kate syntax highlighting colors for C/C++ as a base, it gets less in the way for the developer. Then maybe use shades of gray for distinguishing vars from types and that’s it, italics and bold, etc.

    Comment by edulix — June 21, 2009 @ 11:10 pm

  2. This is some seriously awesome stuff you are doing. Thanks wo all the KDevelop developers for thair hard work. Can’t wait for KDevelop 4 to be released.
    BTW, wouldn’t it be more consistent to name Areas as Activities, at least the concept is very similar, if not the same, as Activities in Plasma.

    Comment by Tsiolkovsly — June 21, 2009 @ 11:13 pm

  3. @edulix: You can shut all the additional highlighting off in the options. You can also tune it to the intensity level you like best. But as a regular user, fact is, it _helps_ you reading the code. Even if it is a lot of color, but it contains information,.

    Comment by zwabel — June 21, 2009 @ 11:14 pm

  4. At first I was also put off by that much color simply because I was used to coloring systems similar to kate or vim, but after a while I really started liking it.

    It helps you so much in reading code and getting information e.g. is a variable a local variable, a member variable or a member of the parent-class all this with just a glimpse at the color.

    @zwabel I have not found a setting for it but it would be great to be able to specify in which way new functions/methods get added, so far it is e.g.
    void myMethod(const int& value)
    but I’d like to be able to have it this way: “…const int &value…”
    I know that is nitpicking to some degree, but that only shows how far you (as KDevelop team) have got.

    Comment by mat69 — June 21, 2009 @ 11:38 pm

  5. Wonderful stuff!
    I hope the oxygen guys can churn out some awesome icons for this, not too far into the future.
    KDevelop has so many killer features now, it’s a dream to use (except when it crashes, but I guess that will be less of an issue now that you’re moving into that mini-freeze).
    duchains is an extremely good concept, and fantastically executed, imho, I’m seriously addicted.
    Keep up the awesome work!
    Only question I have is if the custom highlighting stuff looks OK with other widget styles and color schemes?

    Comment by sandsmark — June 21, 2009 @ 11:39 pm

  6. Its really amazing to see such an effective UI focus put into practice. Many kudos’.

    Comment by Lindsay Roberts — June 21, 2009 @ 11:46 pm

  7. hello, I was wondering how integration of php and hacking on websites in general fits into this scheme .. since it seems quanta is waiting on KDevelop for some things.

    Comment by vlad — June 22, 2009 @ 2:32 am

  8. @vlad Quanta is waiting for nothing more than developers :D
    But you can use KDevelop with the php plugin from playground.

    Comment by niko sams — June 22, 2009 @ 5:26 am

  9. Yes the new UI seems really clear, and don’t use too much space.
    I know you won’t like this, but it’s looking more and more like Eclipse :). But from an eclipse lover like me, this is a great compliment.
    Now it’s time to focus on an awesome 4.0 release !

    Comment by shamaz — June 22, 2009 @ 8:04 am

  10. If you publish the mockups/screenshots in the future, try without the default toolbar. The [new] [save] [undo] etc. bar takes up a lot of space and makes the UI look wasteful of space. Moreover, the tabs for documents and spaces will be visually more connected (closer) which will help bring across the concept.

    Even the novice computer user will use Ctrl-N / Ctrl-S / Ctrl-Z for this.

    Great job.

    Comment by Snirp — June 22, 2009 @ 8:24 am

  11. Great overall job on KDevelop there, again :). But, the idea of working sets seems to me as too much manual handling of files. The only thing I need to efficiently code with lots of files open is what is described in bug 115623 and 104997. This system is as simple as it is useful. And it would even work on top of your workspace system. Please consider adding it David. Someone proposed a patch for this for KDevelop3 and sadly it was rejected because it was not very integrated, but I used it nevertheless as long as I could. Thanks for your time :)

    https://bugs.kde.org/show_bug.cgi?id=115623
    https://bugs.kde.org/show_bug.cgi?id=104997

    Comment by Jörg Rüppel — June 22, 2009 @ 9:30 am

  12. @sandsmark: Custom highlighting works with other window color schemes, but still has problem if the kate color-scheme does not match the window color scheme.

    @mat69: Everything is mangled through the currently active source code formatter before it is inserted. So if you can convince astyle to do it the way you want, it will work. Otherwise, I think we need support for the ‘uncrustify’ formatter, as that one seems to have much more options.

    @Snirp: I hope most of those actions by default will be replaced with really useful stuff.

    @Jörg Rüppel: That exact concept has already been implemented by Andreas Pakulat for KDevelop4

    Comment by zwabel — June 22, 2009 @ 9:53 am

  13. That is awesome news!

    Comment by Jörg Rüppel — June 22, 2009 @ 11:08 am

  14. > void myMethod(const int& value) but I’d like to be able to have it this way: “…const int &value…”

    I’d agree on putting the ‘&’ or ‘*’ sign on the right side, because the C++ compiler treats the ‘&’ and ‘*’ symbols in the a different way.

    int* x, y; // looks like X and Y are int*
    int *x, y; // more obvious that x is only a pointer really.

    Comment by Diederik van der Boor — June 22, 2009 @ 11:25 am

  15. That’s a style question.

    Personally, I don’t like the second variant. Yes, if there is multiple variable-declarations in one line, then it makes sense. But else, putting the ‘*’ to the left side is imo nicer, because it is a nice “TYPE name” splitup, not “TYPE TYPEname”.

    Comment by zwabel — June 22, 2009 @ 11:33 am

  16. Very nice, but we need Python support.

    Comment by kusu — June 22, 2009 @ 2:11 pm

  17. Looks great!
    If KDevelop keeps evolving at this rate I’ll probably even switch from Eclipse do KDevelop for my C++ programming and only use Eclipse for Java.

    Comment by P. Müller — June 22, 2009 @ 5:09 pm

  18. this area concept is great ! I hope it can be extended to some other KDE applications like Koffice or Digikam :)

    Comment by DanaKil — June 22, 2009 @ 6:33 pm

  19. What it is is arguable, i think. We can also say TYPE OPERATORname :)

    It would also be nice if we could configure the order of declaration specifiers. For example, i like the following style

    int const *name

    Some people like const before int more. Anyway, great work there :)

    Comment by litb — June 22, 2009 @ 9:58 pm

  20. What happens when you shrink the window, or have more than a couple of working sets? Where do the icons go? There’s only just enough room for them in your mockups/screenshots.

    Comment by randomguy3 — June 22, 2009 @ 10:28 pm

  21. I’ve found myself wanting features like this in kate. Its starting to be a little too simple to work cleanly with some of my projects. I might have to give KDevelop another try!

    Comment by Thomas Fjellstrom — June 22, 2009 @ 10:42 pm

  22. Still looking great – how’s visual debugging support coming along? I seem to recall that was one of the key outstanding items a couple of months ago.

    Comment by Tom Lynch — June 23, 2009 @ 12:53 am

  23. @randomguy3: Then menu-items are hidden in a submenu, and/or the area-switcher becomes scrollable

    @tom Lynch: There is a lot of work being done on the debugger these days (Mainly by Niko Sam), it seems to be coming along nicely.

    Comment by zwabel — June 23, 2009 @ 4:11 pm

  24. Hi, just wanna say thanks for your work. I am beginning to pick up c++ on kdevelop 4 but find it difficult to start to code a simple “hello world”. I just want to type sample code from my c++ book, but some how the simple (console) project templates are missing. Us “novice” programmers want to learn the language first, and then worry about cmake, qmake or autotools… Any easy way to do this in kdevelop 4?

    Comment by Kombat — June 26, 2009 @ 7:19 pm

  25. Very nice. Are the Working Sets fixed categories? I tend to edit in sets more like lib, cli, gui for some of my applications, and yet other categories for other applications. It’s not clear if I can define my own sets with this new interface. Heck, I’d toss in a scratch documentation and website set as well so as I’m working I can note certain changes.

    Well done, either way!

    Comment by Evan 'JabberWokky' Edwards — June 28, 2009 @ 7:46 pm

  26. @Kombat: Either find some tutorial how to create a hello-word Makefile or cmake project. cmake is not complicated, a hello-world project would just look something like “TARGET(helloworld, main.cpp)” and not much more. Actually KDevelop has a “No GUI (Cmake)” template, that probably is exactly what you want, a hello-world command line application.

    @JabberWokky: The working sets are automatically defined by the files you have open. Every set of open files automatically is a working set.

    Comment by zwabel — June 28, 2009 @ 9:06 pm

  27. Great !!!

    I hope it will integrated in the major distribution including KDE4.3, it seems to become really amesome !

    Comment by manudwarf — June 29, 2009 @ 9:03 am

  28. KDevelop4 is such a step up from KDevelop3, it’s amazing to see all the new features. I just hope the project management bits gets worked out soon, so I can start using it for real.

    I really like the working set idea. I have a little problem with the tooltip dialog though.

    I think that the “hover to get a dialog” mechanism breaks the GUI consistency with the rest of KDE. Hovering over a component usually only gives a small informative text, which goes away when the mouse leaves the GUI component. Redefining how tooltips works is a bad idea, consistency-wise. The relatively complex code view tooltips when hovering over the syntax elements are a stretch, but I think they are ok given that they are _mostly_ informative.

    I’m not sure you actually need to ‘manage’ the working sets very much. When a file is opened its view is automatically added to the current working set. When the view is closed it is removed from the current ws. All you really need are buttons to add and remove working sets.

    The working set icon besides the document tab bar could be a drop-down button instead, similar to the forward and back buttons in konqueror, i.e. when you hold it down for a second a small menu appears that allows you to create a new working set or delete the current. There is no need to show what files are part of the working set, you see that in the document tab bar anyway. I don’t think the “Add all” and “Subtract all” are needed either, just open or close the files you want in a ws.

    Comment by Staffan Palmroos — June 30, 2009 @ 9:25 pm

  29. Could you please describe what exactly these Areas do? Especially maybe post a screenshot of a Debug area?

    Because if they are even remotely associated with Eclipse Perspectives, I smell disaster. Eclipse Perspectives completely change your working area, and are the worst thing anyone could do in an IDE. Give me a good code view area with an ability to debug on the spot – I’ll take it over Perspectives any time.
    Actually, Perspectives are one of the reasons I hate Eclipse (the others are it being sloooow and having a worst possible UI on the planet. For example, the right-click menu is 700 pixels high and contains ~40 entries, half of them submenus, copy/paste being somewhere in the middle, with even “Preferences” being there, wth?).

    P.S. It seems I’m not the only one who thinks like this. Here’s a (slightly ranting) writeup from a long-time programmer: http://www.informit.com/blogs/blog.aspx?uk=Thinking-About-Upgreading-to-Firefox-30-Think-Again

    Comment by Alex — July 2, 2009 @ 12:33 pm

  30. same problem as the other guy wanting to start learning on kdevelop and c++. I have spent 2 days trying figure out how compile and run hello world. other ide’s are intuitive and straight forward. I can find no where or way to write even my most simple source files to begin using kdevelop to build upon as a new programmer. using codeblocks now.. but I rather be using kdevelop.

    Comment by lost — August 9, 2009 @ 2:24 am

  31. Hi,

    I have just a simple question: has this new feature been incorporated to KDevelop? I looks really nice, but I haven’t been able to find it anywhere…

    Best regards!

    Comment by Musikolo — December 6, 2010 @ 12:23 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: