For every KDevelop release, announcements are made by various people on various news sites, and there’s plenty of comments. Depending on the news site, those comments are more or less accurate, but generally, comments on KDE applications outside of the “KDE world” (planet, developer blogs, …) are often alarmingly mis-informed and are spreading a lot of FUD. I’m sure most projects have similar issues, but I feel it’s especially bad for KDE, and for KDevelop in particular. I have no idea why, but I’d like to collect and clarify a few common misunderstandings and wrong things said about KDevelop.
First of all: KDevelop 3
KDevelop 3 is not KDevelop 4. Please, if you have used KDevelop 3 and you think that makes you know anything about KDevelop 4: forget it. The two applications have nothing to do with each other. And by nothing, I mean nothing. They have a totally different philosophy and a totally different code base, and they mostly have been developed by different people.
About KDevelop’s philosophy
The way KDevelop 4 works differs from the way many other IDEs work, which means some people are sometimes confused about how it works and why. But, if we wanted it to work like something that alreay exists, there would be little point in creating it. So, here’s some bullet points of things people often seem to get misunderstand:
- KDevelop 4 is not a programming tutorial
- KDevelop 4 is designed for people who know how to program, and who know how to use their tools. For example, KDevelop 4 supports building projects with CMake — which does not mean it will magically create or maintain CMakeLists.txt files for you. It means we have tools to help you do it, such as CMake code completion and assistants to add new files. Of course, you can use KDevelop as a beginner — I personally think it’s an excellent choice — but it’s not an IDE that will save you from understanding how building an application works. Which we think is a good thing. In KDevelop, for all UI elements that have to do with things like building and debugging, or VCS support, it’s very easy to tell how you’d do the same thing in the shell. It’s just more convenient to have a button or a keyboard shortcut to do it.
- KDevelop’s aim is not to create an application which makes it as easy as possible to compile “Hello World” programs (although it happens to be pretty easy with the application templates).
- KDevelop 4 does not aim to be a collection of wrappers around as many tools as possible.
We try to integrate existing tools instead of wrapping around them, and we try to keep everything fully transparent to the user by design. For example, although we have git support, we expect people using it to know how git works. - We try to be as non-invasive and transparent as possible. Especially, we have no project files (well, we have, but it
only contains your project name and a few similar settings — it’s not
something you want to have in your project repository, it’s more like a personal
settings file). We have no workbench, i.e. importing a project into
kdevelop is as easy as “open this directory in KDevelop” and clicking
“yes use git support”. You’re not really “importing a project”, you’re
just opening a directory. The only thing which brands this
directory as being a KDevelop project is the project.kdev4 file, which, as said
above, is just some convenient meta-data. - The main focus of KDevelop 4 is language support. The main focus of the IDE is things like code completion, syntax highlighting, marking syntactic and semantic errors, finding information about objects in the code (type of variables, …) and quickly navigating in your code. This is what most time is spent on in development, and what — in my personal opinion — makes KDevelop really more useful than a text editor plus a few GUI tools for debugging and stuff. Yes, we have things like unit test integration, debugger support, tools to edit your build configuration cache etc, but the heart piece of the IDE is the language support part. I think the eclipse people would tell you something different about their IDE.
- KDevelop is not a compiler and not a build system, nor does it contain either.
Comments frequently encountered and why they’re pointless
“kdevelop 3 was good, but kdevelop 4 has none of the features”
- KDevelop 3 did lots of stuff, but it did little things really well. While KDevelop 3 supported almost every language and build system, for many of them it is questionable what benefits it provided over just using, say, kate. In KDevelop 4, this is different; we just do a few things, but we try to do them really well. If what you need is not among the things we do, then that is unfortunate, but I’m sure it’s better to provide a really good tool to a few users than a mediocre tool which everyone could use, but nobody actually does use because there is better, more specialized alternatives.
- KDevelop 3 focused on being a wrapper around dozens of development tools, quite the opposite of what KDevelop 4 does. If you’re looking for wrappers around tools which are difficult to use by themselves, maybe you should instead look for better tools (such as CMake over automake).
- If you’re looking for complete GUI wrappers (as opposed to helpers) around tools which already have a nice interface, KDevelop 4 probably is not for you (e.g. CMake). As said above, we expect users to understand the tools we support.
“kdevelop is slow”
It’s not. Seriously, it’s not. I’m not going to do an excessive benchmark now, because “slow” is so ill-defined, but KDevelop 4 is by far the most responsive and slim IDE I know.
A little less subjectively, here’s some numbers I took on my Arch Linux x64 (04/2013), SATA2 SSD, Intel Core i5 540M 2.4GHz CPU, 4GB RAM system (all numbers are after the respective appliction has been started before, because I’m too lazy to reboot twenty times):
RAM usage (RES):
All applications with the KDevelop repository loaded as a project, after a fresh startup.
KDevelop: around 250 MB
Eclipse: around 400MB (Eclipse does not appear to hold a parsed representation of the project’s source code, at least I’ve never seen it parse it?! I don’t know…)
Netbeans: about 600-700MB
Storage space:
Without all dependencies, from pacman’s “installed size”.
Eclipse CDT: 320MB
Netbeans: 540MB
KDevelop + kdevplatform: 50MB
Of course, this will change if you don’t have the dependencies; KDevelop depends on kdelibs (around 50MB, but depends on some more things itself) and friends, and Eclipse and Netbeans depend on the java stuff, so subjectively on an empty system (just plain X11 installed) I’d say it doesn’t make much of a difference. Real numbers on what those IDEs plus all dependencies need storage-space-wise would be welcome of course. I would be very much surprised though if KDevelop (with all dependencies) would end up using significantly more storage space than Eclipse CDT (with all dependencies).
That being said, it’s a stupid point anyways, because who cares about whether it needs 100 MB or 500 MB on your hard disk nowadays (I don’t). If it required several gigabytes (like mathematica or so), I might complain, but in the few-hundred-megabyte-range, everything is all right for an application I use every day.
Startup time:
(until main window + all widgets shows up; “warm” start!)
KDevelop: around 3 seconds
Eclipse CDT: around 11 seconds
Netbeans: around 18 seconds (plus an extra at least 5 until a file shows up in the editor)
I’m perfectly aware that this is not a benchmark of any kind, or even a serious comparision. But maybe I just need to post some numbers in order to make people try for themselves if stuff is slow or not instead of just making random uninformed claims.
“$language is not supported”
Supported languages are: C++, CMake, PHP, Python, Ruby (not yet released but good), JavaScript/QML (not yet released and quite basic).
Everything else is indeed not supported, and if you need an IDE which supports that language, you’ll have to implement it yourself in KDevelop, or use a different IDE.
But, be aware that “not supported” only means “no extra-fancy features”. We do have syntax highlighting and such basic stuff for everything, from Action Script to Yacc, so you can edit files from other languages just fine.
“there is no GUI designer”
No, there is not. You can just use QtDesigner alongside KDevelop. How do you want QtDesigner integrated in KDevelop, do you want the designer window inside KDevelop? Or a “new UI file” button? What’s the point?
I claim that if you understand how KDevelop is meant to be used, you will have to agree that there is little point in QtDesigner integration beyond having a template for “UI file with C++ class” (which we have), because all you could do is pinning the designer window into a KDevelop tab, which I don’t see a point in.
“it’s KDE so it’s slow / bloaty / cannot be used under FOOBARDE /…”
“it’s KDE” just means that it uses the KDE libraries which means it’ll depend on some packages. Other IDEs have dependencies as well, they use a different set of libraries (when I installed eclipse for the test above, I didn’t have java installed for example). I don’t see a qualitative difference between depending on Java and depending on kdelibs.
It also doesn’t mean you can’t use it in other environments than KDE’s plasma, that’s a myth which just keeps popping up for whatever reason. It’s about as pointless as claiming that you can’t run vim on X11 because X11 is GUI and vim is terminal. Or so.
It also doesn’t mean it’ll be any slower in non-KDE environments. Of course, if you use a lot of KDE applications, they will, combined, use less memory and start up faster because of shared libraries, but that’s an extra benefit you don’t get for other applications anyways.
“the syntax coloring makes my eyes bleed”
First, you can turn it off if you don’t like it. Second, try using it for a week — I have yet to meet someone who turned it off after having used it for a while.
Here’s an extensive explanation about how syntax coloring works.
“it’s unstable and crashy”
It’s not. There was problems with stability in the 4.1 era (wich was years ago), and there’s a bug in some Qt versions before 4.8.3 which made it crash too, but the current version is perfectly stable.
That’s about all. I hope that with this post I have covered most things that usually come up, so I can just link to this page when it happens again 😉
Categories: Everything
The main reason I switched from KDevelop 3 to Eclipse/CDT was lack of autotools support in KDevelop 4. But there's also a more fundamental issue of CADT development model.
In your post, you write: "There was problems with stability in the 4.1 era (wich was years ago), and there's a bug in some Qt versions before 4.8.3 which made it crash too, but the current version is perfectly stable." Well, the problem is that KDevelop 3 stopped being improved long before KDevelop 4.0 got released and even then you admit it took mode time before KDevelop 4 was "usable". What it means for a user is that you go through these steps:
1) Having an IDE you like
2) Having an IDE you still like, but that's effectively unmaintained
3) Being forced (by your distro unless you want to deal with a lot of pain) to use an IDE that's not ready (KDevelop 4.0)
4) Adapt to a new IDE which is eventually usable, but no longer supports what you were using before.
So even if KDevelop 4.5 ended doing everything I wanted, I likely wouldn't switch back because I'd know (or at least expect) I'd have to go through the painful steps above again for KDevelop 5. Personally, I think developers should have simply renamed the project to avoid confusing people (and especially distros) into thinking that KDevelop 4 was in any way related to KDevelop 3.
You have some fair points, and I'm not going to argue about them since I understand why you bring them up. Let me just make some remarks:
> The main reason I switched from KDevelop 3 to Eclipse/CDT
> was lack of autotools support in KDevelop 4.
The reason KDevelop 4 didn't support autotools was that everyone around KDE effectively stopped using it since at least 2008. So there was little interest in having it supported, and being a quite low-manpower-project, KDevelop had to focus on a few things it wanted to do. Autotools support wasn't very high on the list.
> So even if KDevelop 4.5 ended doing everything I wanted,
> I likely wouldn't switch back because I'd know (or at least
> expect) I'd have to go through the painful steps above again for
> KDevelop 5.
The 3 -> 4 step was very painful, and nothing similar is going to happen again anytime soon. Everyone knows it was a difficult transition for both users and developers, and everyone wants to avoid doing it again. For version 5 of the KDE frameworks for example, there is of course some restructuring, but source compatibility will be mostly maintained (except some few select things), so it's very unlikely there will be any major application rewrites.
Part of the 3 -> 4 problem was that people expected 4.0 to be usable as a desktop environment, which it was not. It was meant as a "we freeze our API now" release.
> Personally, I think developers should have simply renamed
> the project to avoid confusing people (and especially distros)
> into thinking that KDevelop 4 was in any way related to KDevelop > 3.
Yes, I think that would have saved us from a lot of confused and annoyed users. Instead we would of course have "how could you discontinue this awesome project" people, but those wouldn't be associated with KDevelop 4 at least.
Cheers
> The reason KDevelop 4 didn't support autotools was that everyone
> around KDE effectively stopped using it since at least 2008.
Well, that point is definitely valid for a KDE developers environment. However, maybe the website should be clearer about KDevelop being targeted mainly at KDE development rather than a general-purpose IDE (autotools is still more popular overall).
> The 3 -> 4 step was very painful, and nothing similar is
> going to happen again anytime soon. Everyone knows it was
> a difficult transition for both users and developers, and
> everyone wants to avoid doing it again.
If that is indeed the case, it would be a nice change from the KDE and Gnome tradition of throwing everything away on every major release.
> Part of the 3 -> 4 problem was that people expected 4.0
> to be usable as a desktop environment, which it was not.
> It was meant as a "we freeze our API now" release.
Unfortunately, I think history has shown that no matter what you say about your project, distros *will* ship a new .0 release when it comes out. Of course, the fact that version 3 had been mostly unmaintained for a while probably didn't help. Personally, I prefer calling the API-freeze version a beta or RC.
> Yes, I think that would have saved us from a lot of
> confused and annoyed users. Instead we would of course
> have "how could you discontinue this awesome project"
> people, but those wouldn't be associated with KDevelop 4
> at least.
Well, at least it would have increased the likelihood of distros actually shipping both KDevelop and KNewIDE for a while rather than have KDevelop3 suddenly being replaced by something that's not ready. Still not ideal, but at least a smoother transition.
Cheers
> Well, that point is definitely valid for a KDE developers
> environment. However, maybe the website should be clearer
> about KDevelop being targeted mainly at KDE development
> rather than a general-purpose IDE
But it is not. We just happen to support the tools commonly used for KDE development best. None of the things we do is specifically optimized towards KDE — just the choice of tools we support is. Granted, we have a few select features (signal/slot code completion for example) which are specific to Qt; there's nothing for KDE though.
Yes, CMake is used for building KDE. But it's not like it was KDE's very own build tool or anything, tons of other projects use it (for example blender, compiz, boost, inkscape, MySQL, just to name a few). The same goes for all the other things we support, although most are probably so standard that nobody will complain anyways (C++, gdb, make, git).
> (autotools is still more popular overall).
Popularity is a difficult thing to measure, and in my world autotools is not a very popular build system nowadays. Most projects I follow have switched to something different by now, and I know very few new projects which decide to use autotools. I'd say it's pretty much dying, and I'd also say this was just as predictable back in 2008.
> If that is indeed the case, it would be a nice
> change from the KDE and Gnome tradition of throwing
> everything away on every major release.
I can definitely say that nothing of relevance gets thrown away for KDE 5. 🙂
> Unfortunately, I think history has shown that no matter
> what you say about your project, distros *will* ship a
> new .0 release when it comes out.
Yes. I think KDE 4.0 was the best example in history which has shown this. 😀
I guess if the same people would be doing it again, they'd probably do it differently. But it has happened, and we have survived it. 🙂
> Well, at least it would have increased the likelihood
> of distros actually shipping both KDevelop and KNewIDE
> for a while rather than have KDevelop3 suddenly being
> replaced by something that's not ready. Still not ideal,
> but at least a smoother transition.
Yes. But, one of the things I wanted to emphasize in my post is that this was a relevant thing to talk about five years ago. People bringing this topic up at each KDevelop release started annoying me, because it just doesn't matter if there was a smooth transition between KDev 3 and KDev 4 any more. It has happened, everyone has learned from it, and now everything is working nicely again. So I'd prefer if people would stop complaining about it. 😉
Cheers,
Sven
> Yes. I think KDE 4.0 was the best example in history which
> has shown this. 😀
> I guess if the same people would be doing it again, they'd
> probably do it differently. But it has happened, and we
> have survived it. 🙂
Actually, the issue predates KDE 4.0. Gnome 2.0 was a similar mess (which got me to switch to KDE 3 for some time), and later we got an even worse mess with gnome 3.0 (I'm now on XFCE). At this point, I'm starting to doubt that developers really learn from past mistakes. Or maybe they just get replaced by new developers who weren't there for the previous mess. So I'm fully expecting the same to happen for KDE 5.0 and Gnome 4.0.
> It has happened, everyone has learned from it, and now
> everything is working nicely again.
I probably won't switch back to it, but if indeed KDev 5 shows that developers learned from past mistakes, then that'll be a pleasant surprise (and a model for the gnome folks).
Well, it's not like "hm, we have run out of minor version numbers, let's rewrite everything so we can increase the major one", it's more like "hm, our framework sucks, let's make it better" … "ok, everything has changed, time for a major version number increase".
So I think there's two factors in not breaking everything: The first one is, don't do it, i.e. if you change something, do it gently, and only release it when it's done. Of course, if that is possible, it's great, but unfortunately it isn't always possible (well, waiting for it to be ready always is, but you can't always prevent a full rewrite). The second one is, your framework needs to be in an acceptable state. If you have a horrible API and nobody wants to work with it any more, then at some time it will be less work to rewrite stuff than to keep the old API, or gradually improve it. If your API is somewhat okay, then you can probably prevent full rewrites for a pretty long time by doing continous improvement, like KDE 5 (KF5) does. By the way, half of KF5 is already done and the other half is planned pretty exactly, and it's not going to break anything significant (see http://community.kde.org/Frameworks/Epics).
Cheers
It's a quick way to get some new users to your system "that has *nothing* to do with the old, I guess? It's not a good longer-term strategy.
"the new system" is more than five years old. And still people keep referring to the old one.