Perhaps because not everyone is doing development on KDE?

The Ninja-IDE supports linux, windows, and osx so it has broader appeal.

That's a good point, although I feel that "development on KDE" needs a response: KDevelop isn't limited to making KDE applications, and KDE applications like KDevelop aren't limited to running inside the KDE shell - the major Linux desktops are quite interoperable today as far as running applications goes. Furthermore, generally speaking KDE apps are also available for Windows (via the KDE Windows installer) and OS X (via distibutions like Fink), although both platforms are considered experimental deployment targets for KDevelop.

I personally don't feel like downloading all the hundreds of megabytes of KDE runtimes just to fire up an IDE for a test run (this is on Xubuntu).

"hundreds of megabytes of KDE runtimes" is absolute FUD. libkde4core is 2.5MB on my system here. Even all the KDE libraries that you would need are only going to be in the 10s of MB. Did you actually do a test to see how much you would need?

Yes I did. On my 32-bit Xubuntu machine, I called `sudo apt-get install kdevelop`, and it has informed me that I require 99.0 MB worth of archives, and that it will take up ~330 MB of disk space after everything is installed. For some reason, I recall `apt` telling me I had to download over 100 MB on my 64-bit machine...

Admittedly, a lot of the download size comes from additional dependencies, but still - I don't want to have to install all that when I use an entirely different WM, and there are alternative WM-independent solutions to begin with.

KDevelop is WM-independent -- its dependencies don't include the window manager or shell. This silo thinking has to stop. Basically all the library stacks on Linux have a shell project prominently associated with them (Qt/kdelibs: Plasma, GTK+: Gnome Shell, EFL: Enlightenment, Motif: CDE), so you run out of "WM-independent" apps pretty fast if you make that mistake. And considering Qt even calls into the GTK+ theming system if run in Gnome it strives to be interoperable more than most.

As for alternatives, I'm not aware of a Python IDE with comparable abilities for Linux (Wing probably comes closest, but is proprietary).

What has the potential for greater impact on your productivity - 320 MB of used disk space or a useful IDE?

Maybe the package (Kdevelop or something above it in the dependancy tree) maintainers screwed up. Unfortunately it's not very uncommon to see complete gnome-* download (I have KDE) for a simple application that only requires one library.

Which packages will also increase your update times ... This goes double when using something that doesn't ship binaries like Macports.

I'd guess it's due to KDE's general lack of popularity. Typically, nothing done under the KDE umbrella gets noticed.

I'm going to guess you're based in the US, because the two big Linux desktop camps are indeed somewhat split along the continents as far as mindshare goes. Makes me wonder about the exact breakdown by geographical area of the HN readership :).

Don't forget to throw Mac and Windows into the mix. You're forgetting two much, much larger user bases.

I'm not based in the US and I rarely see people use KDE compared to other Linux DEs

Against your anecdotal evidence I'll present a somewhat less anecdotal evidence in the fact that KDE was voted best desktop environment in the last annual LinuxQuestions members choice awards. Clearly people voting for it are the ones using it, don't you think?

If anything was "clear" from a non-randomly sampled poll, we wouldn't need randomly sampled polls.

I haven't noticed that either, if only due to the fact that GNOME desktop (for some value of GNOME) always came by default with Ubuntu. (Yes, I'm aware of Kubuntu.)

Well, it has historic reasons - KDE was founded in Germany and many of the initial wave of developers were based there, and it's the same for Gnome and the US. Both were certainly international from the start and the bias on the developer side largely no longer persists (also due to the huge presence of South America and India in FOSS now), but for the first half-decade you were simply far more likely to run into KDE people at a European event and into Gnome people at a US-based event, and thus make connections and become involved. This then extended to things like the prominent distributions (SuSE and Mandrake: KDE-centric and from Germany and France; Red Hat: Gnome-based and from the US) and print mag coverage, when that still mattered. And of course Trolltech was a Norwegian company later bought by a certain Finnish phone maker.

And to become more markedly opinionated for a moment, it's also most likely why Gnome managed to catch on and get to a place where it could make some meaningful contributions to the space, despite always having run on arguably inferior technology: The US FOSS scene had a little bit more of an entrepreneurial spirit going (also due to the early decision for LGPL licensing - well, kdelibs was always LGPL as well, but Qt only went LGPL a few years ago, while GTK+ always was) and the US IT market is simply somewhat bigger as well. If KDE had put some more effort into growing US mindshare early on (like it has tried to in recent years by launching a second annual conference just for the US, Camp KDE) things might have gone differently.

Thank you a lot for this! This is really impressive.

A shame that it probably will be a bit tricky to get this running on OSX...

Maybe a good starting point is here: https://github.com/mxcl/homebrew/pull/8511

I had no luck with Python under KDevelop (tried it something over a year ago). It worked, but not really as an IDE. I liked it for C though, maybe it would be worth trying it again.

And it might be silly but I really loved the KDE's variable coloring. Example for those who don't know: http://www.kdevelop.org/sites/kdevelop.org/files/photos/Kdev... Basically every variable name is hashed and colored differently. Upside is that different variables have different colors in the code and the orientation was much easier/quicker. Downside is that you sometimes catch yourself renaming variable just to have a different color.

Indeed. I tried out Ninja about 6 months ago. While it was very nice I found it just didn't compare to KDevelop in terms of features and ease of use (admittedly I am also using to KDevelop for C++ work).