Qt Creator, KDevelop

I decided to give both Qt Creator, the new IDE from Qt Software, and KDevelop from today's svn trunk/ a whirl. Now, I'm not an IDE kind of guy. It's no secret that I'm an old fart who uses vim and lots of konsole tabs to do his development. The only GUIs I use in development are tools to visualize the output of valgrind runs, a web browser for patch review and defect reports and applications to communicate with my teammates (konversation, kontact and skype). No IDE is in that mix and I like it that way.

Well, almost. I do admit that there is a lot of stuff I do manually that a proper GUI could alleviate me of. Switching between headers and implementations, for instance. Every IDE I try, though, adds more inconvenience than convenience to my life. Maybe I'm just not giving them a fair shake .. and so every so often I try them again.

With Qt Creator having been recently announced, I decided to give it a whirl. In turn, that caused me to svn up and build KDevelop, too. Here are my thoughts and findings.

First, The Elephant In The Room

Before I get on to the interesting bits about the actual IDEs themselves, however, I'd like to address the proverbial elephant in the room: why the hell is Qt Software releasing an IDE? My perspective on that, which follows, is as a spectator to it all. I've known for a couple years that this was happening, respected the privacy of those involved but wasn't actually involved in any way with any of it. Honestly, I gave it a slim chance of ever seeing the light of day at all. ;)

Well, it was started back when the future of KDevelop was, shall we say, in a dubious state. That's an important bit of context to understand. Second, it was started as a bit of a skunkworks project, a "let's see what could be possible" thing. There really was a lot less intent at the start than one might expect. ;)

Today things are a bit different: KDevelop has momentum again. It seems to be a much more open project now, as well. It still has a lot of work needed to be done.

In the end, one can't always get 100% efficiency and there will be times people work on their own thing for less than purely logical reasons. We aren't vulcans, we are humans after all. There are some significant differences between Qt Creator and KDevelop, but really .. they are duplications in my opinion. That's unfortunate, but perhaps it's as close as we'll get to efficient. I hope that the two groups will find ways to share code and what not.

What really didn't help was how it was announced. The guys working on Qt Creator are not diplomats, they are engineers. (I stole that one, verbatim, from Mattias Ettrich himself, actually.) I tried to warn them that they needed to be really, really, really clear about licensing (something they have since corrected, so kudos for that) and the relationship to KDevelop.

I was very concerned it could cause unnecessary bickering and create schisms that are unnecessary. I hope that both the KDevelop hackers and the Qt Creator hackers can get along well (so far it seems so) and that the rest of us will let them live in peace in the meantime so they can all sort out whatever needs sorting out without pressure or incitement.

Ok, the elephant is now fully worked over, let's move to useful things!

Qt Creator: What I Loved

There are many things about Qt Creator that I struck me right off the bat in a positive way. I loved:

• how when you collapse a bit of code, it has a little "collapsed" marker that you can hover over to see the code that is collapsed in an overlay. Hover interfaces rock for those kinds of use cases.



• how the first thing you see when you start it up is "Get Started" if it's your first time running it or a project listing and session restore options if you've already used it for work. It's a great compromise between the insane menagerie that is the NetBeans opening page and the blank spaces of other IDEs that force you to instantly hit the menu system. Having the obvious start points front and center just waiting for you to click is perfect.



• how when a file was open, it listed all the methods in the file in the "smart bar" at the top. I don't really know what that thing at the top is called, but I'm going to call it the smart bar. It looks smart, and it works smart. .. ergo it's a smart bar. =P That same bar also shows open files in a drop down which I find much more sensible than tabs.



• the smart bar at the bottom of the window with it's quick open (typing "| Animator" to get the Plasma::Animator class is neat) and it's quick access buttons for things like open tasks.



• the side bar which gave me access to all the things I need: editing, debugging, building, help ... I never hit the menu bar except to see what was actually in there after actually using it for a while yesterday.



• the speed was impressive: things opened quickly, syntax highlighting was fast, fast, fast.

As you can see, it's all about the interface. The text editor itself was good though not mind blowing. The use of subtle animations in places was good and the subtle use of colour is something that katepart could learn from I think. I didn't like that I had to press a key combo for autocompletion; I like that to be automatic but I couldn't find a configuration option for that.

Sounds like I'm starting to complain a bit, which means I must be ready for the next bit:

Qt Creator: What I Hated

It wasn't all one big rose garden, however. It's not a complete product, so there are going to be rough edges. Here are the things that cut me and left me to bleed in this pre-release:

There is only support for Perforce. No subversion, no git, no cvs ... Huh-what? Ok, historically Qt Software uses Perforce internally, but there's been a big movement towards git as well. Qt Creator doesn't even support git though, and that's a big WTF.

There is only support for qmake. I don't use qmake and have only a handful of projects on disk that use it. CMake is a bare minimum here.

There is only a plain text editor for the build files, which is crazy. I totally get the idea that it should be possible to edit the text directly and agree with the Qt Creator guys that simple GUI wizard things are not enough for real build systems. That doesn't mean that there shouldn't be some basic GUI there though that covers 90% of the use cases (allowing it to remain simple and focussed) with a "edit manually" fallback to cover the other 10% of use cases that 90% of projects will need 2% of the time. (I love faux-tistics!)

Qt Creator looks great, but it goes overboard in its aggressive "style everything!" approach. It should keep its hands off my push buttons, for instance. The buttons in Qt Creator look like ass compared to the nice Oxygen buttons, and don't even get me started on my guess as to why they themed the menu bar but not the menus themselves. It really takes the shine off an otherwise gorgeous visual approach. As important as knowing what to theme is knowing what not to.

It would also be awesome if the icons used followed the xdg spec for those so we could theme them up, but that's not a "hate" more of a "wistfulness".

Back to the hating, the keyboard controls are either completely non-obvious or just completely missing. If I have to take my hands off the keyboard or press more than 2 keys to get to things I need, the word of the day becomes "FAIL". "Ctrl+K, 'l', space, #, enter" is exactly two too many key strokes to go to a line in the document, something I do all the time. "Ctrl+G, #, enter" is so much more sensible, and it could still use the uber-slick quick open bar, with Ctrl+G automating the "Ctrl+K, 'l', space" bit.

One might think Qt Creator is a bit mouse centric, but its not. In fact, the keyboard controls are actually better than the mouse interaction as can be seen by clicking in the bookmarks and stop points bar in the text editor. Try it and you'll see what I mean. ;)

Crashes are to be expected with a product at this point, but it amazes me that there isn't any autosave-while-editing feature. That makes crashes not only frustrating but deadly: I can't afford to lose work.

The lack of creating projects based on existing sources was also frustrating. Missing things like a class browser is also a bit mystifying.

These are all "little" things compared to the work that's been done. It's nearly usable today, but not quite. If they can push hard on this project for another 6 months or so I think it could be stellar, as none of the above point to problems with the actual underlying design of things. It's just not a completed product and as such has a bunch of holes. Fair enough, I can wait.

I could also contribute, but of course the source is still locked away. I don't get that, to be honest, and will by final entry in the "hate" column. The whole "we'll show you a binary for a while first" culture is really broken. Nobody in Qt Software will be surprised to hear me say that, but I'm tired of saying it quietly internally while watching the parade continue in public.

KDevelop: What I Loved

I gave KDevelop a spin as well. What's interesting is that what I hated about Qt Creator was mostly addressed in KDevelop: it's keyboard friendly, it has autocomplete, it blends and integrates with my desktop better, it supports all the revision control systems and build frameworks I might want, it has integration with valgrind, it imports existing projects nicely. It also supports tons of languages and has all these other plugins, too!

What really shone for me, though, was the ability to click on a symbol and get a summary window that is very visually attractive but more importantly contains insanely useful information. Things like the documentation from the header file for that method, what file it is defined in, what file it is declared in and where it is used in the project! Really, really nice.

When I discovered the Outline function which does that for every method in the current file I was sold on the idea.

I also liked the "Code / Debug" drop down in the toolbar that switches the tools between those two modes. Nice touch.

The fact that the text editor has tons of features and things like vi text mode is really cool as well.

KDevelop: What I Hated

There are a few areas that KDevelop really needs improvement from a simple user's perspective, and I'm sure neither of these things are news to the developers. Since I ragged on Qt Creator, though, it's only fair I do similarly with KDevelop. Apologies in advance.

There are a number of "not complete" features in KDevelop right now, such as the class browser which seems a bit random at times: why does it only show me the Plasma classes when it loads all of KDE base, though I selected only workspace/libs/plasma when importing the project? Like Qt Creator, KDevelop for KDE4 is not a completed product, however, so this is understandable.

The user interface, however, is in a general shambles. The menu system is something that I'm forced to interact with too often, and things are scattered everywhere it seems. Simply having useful shortcuts, such as a quick open bar as Qt Creator does would eliminate a lot of this pain.

There are moments of brilliance in the UI, like the code outliner and the class browser or how the UI never blocks even when it's churning through the code and parsing it out in the background.

Applying this elegance right across the UI would make KDevelop formidable. Instead I'm left wondering why every revision control system known to mankind is listed in the context menu when it's obvious that the project is using subversion, or where I should go to create a new class (I expected this in the class browser in the form of a "new" button or in the context menu even?).

As it stands, KDevelop has a great toolset and some really interesting features, but I can't bring myself to use it because of the UI. It's sort of the opposite situation compared to Qt Creator, isn't it? =)

The other thing that needs work in KDevelop right now is speed. Many things have gotten a lot faster in the last few months, and kudos on those accomplishments to the KDevelop team. However, when I opened libplasma as a project it imported all of kdebase. This not only took a rather long time (somewhat understandable as it's a good chunk of code), it didn't give me much visual feedback (again, the whole "UI elegance" thing) and then when it was finally up opening subdirectories in the Project explorer took 2-4 seconds. So there's room for improvement here in ways that will make the user experience nicer.

Oh, and the lack of autosave-as-you-edit in katepart is just as insane an omission as it is in Qt Creator.

Wrap Up

So what will I be using to code with this month? Vim and Konsole.

In six months it might be a different story. I might be using either Qt Creator or KDevelop; both have intense promise, and just need to show what they are capable with over the next year.

For the Qt Creator team I'd strongly suggest opening the code now rather than later and build a development community around it. The functionality holes in the app are huge and I don't think you'll be able to fill them all yourself. I know this isn't how other Qt Software tools get written, but maybe it's time for a shift there. Keep the focus on clarity and simplicity, but engage the audience to build bigger, better, faster and quicker.

For the KDevelop team, I'd strongly suggest casting an eye to the UI. It has plenty of features and seems to actually generally work. It's really time to think about how the user interacts with those things: make it dead easy to get to the most needed features, make it dead easy to navigate around the project and get rid of the UI cruft. It's a different kind of work compared to doing the crunchy yet great Declaration-Usage Chain stuff, but all your efforts put into DUChain may be for nothing if the UI doesn't speak to the user. It's a step up from where KDevelop3 was, but only a small step up so far. The outliner gives me hope, however, and it might be sensible to stop working on IDE features and force yourselves to shift to user interface.

I know that the above is not easy. If it was easy, it would already be done by this point. I know how hard it can be to expose your code and share with a global team (in the case of Qt Creator) or to step away from your main goal to focus on a temporary goal that will bring you users (in the case of KDevelop). I've faced both in the last year with Plasma (focusing on making a good traditional desktop experience causing a temporary sidelining of the 'revamp the user experience' during that cycle has been painful for me these last 5 months), and so you have my empathies.

You probably also have earned a "bitch at Plasma" card now. ;)

I am happy to see that we have so much movement on the devel tools side of things in the Qt/KDE world now though. It wasn't a happy place a couple years ago. In fact, it was a depressing grey place, but now the dawn is upon us. Let's see what full daylight looks like when Qt Creator and KDevelop make stable production releases.

Maybe I'll even say goodbye to vim at that point.