Why does KDE work so well? Benjamin Meyer thinks he knows why, and he explains his thoughts in this Tribute to KDE. Benjamin is the lead developer of Kaim (screenshots), and has been working hard at porting this application from being Qt-only to a fully-fledged KDE application. In doing so, he has come in contact with the KDE development community and processes. Benjamin's experiences have led him to conclude that KDE's CVS culture, release strategy, and focus on consistency lead to polished, mature applications.

There's a perpetual argument as to whether KDE should break up its large modules into smaller pieces. Both sides usually focus on convenience: a smaller number of modules makes downloading, compiling and installation much easier while finer-grained packaging would enable a user to grab the new konqueror or kmail without having to download twenty other apps he doesn't want. There's no right answer, it's a tradeoff.

This piece points up what I think is an underappreciated advantage of large modules. It creates a situation where every developer not only has a copy of the source for every core app, but also a feeling of responsibility for and involvement with the entire project. That's a large part of why KDE feels so integrated and consistent, instead of coming across as a package of otherwise unrelated applications using the same toolkit.

BTW, I agree that Benjamin needs to hit the Return key a bit more often... ;-)

some further toughts about the upper mentioned advantages and disadvantages of large modules.

kinstaller integrated with kconfigure and extended with some "red-carpet"-like apps.kde.com/ftp.suse.com/whatever.sourceforge.net features might allow to have smaller packages from the upper mentioned sources.

additional to this the large modules might stay the gooddy to motivate the k-developer to klean up the own project.

i don't want to step to the level of knowing the formats of make and configure files but still want to try out cutting edge (not yet packaged) alpha applications.

kconfigure helps the upper behaviour very much. kinstaller might help finally even cluelesser users. the kde-project might end up with a lot more bug reports (is that wanted anyway?)

Another reason that KDE works so well (and is stable) is that it (almost totally) uses C++ rather than C.

I've often thought that it's no coincidence that two projects which are having problems with stability (Mozilla and Gnome) are both C-based. Yes, its possible to create an unstable app in C++ as well as C , and there are examples of unstable C++ apps out there too. However, it's hard to go past the advantages of templates etc that C++ provides. Trying to imitate this behaviour in C is a bit like trying to bolt wings onto a car ..... :-)

Benjamin, all your peices seem to be very ojective and easy to read, interesting articles, thank you.

I'd also like to ask something else: you learnt C++, QT and now KDE programming, how? At one point in time you were just a windows user, what was your road map to get from that point to writting a sucessful KDE aps?

Yes, I am seriously looking in to coding under Linux in C++ but I need a few pointers, I have only coded some TCL in the past and have little experience although I like to think I'm fairly technically minded.

There must be simple stuff on the web like "hello world" aimed at developing under Linux with GCC. Would using an IDE like KDevelop be a good move or console apps first? Pointers, links to Linux geared tutorials anyone? Recommened books for total beginners?

I'm a relative C++ newbie and have found the book "C++ from the ground up" (by Herbert Schildt - ISBN 0-07-882405-2) to be very good. Gives a nice intro to the STL , too.
Also - "KDE 2.0 Development" (by David Sweet - ISBN 0-672-31891-1) is very good. I found this to be a great intro to both the Qt toolkit and KDE - understandable even to newbies like myself ...:-)

Now, on the constructive side, my advice is: stick with Addison-Wesley. C++ is a big, complex language, and few are really qualified to teach it. But it seems like the C++ "inner circle" all write for AW - Stroustrup, Lippmann, Koenig, Moo, Meyers. Personally, I read Stanley Lippmann's "C++ Primer" cover-to-cover and did all the exercises on SuSE Linux using gcc and XEmacs. Then I read Stroustrup, the Meyers books, and the C++ FAQs book (which really does add significant value compared to the online FAQ).

For what it's worth, I like Herbert Schildt. I remember studying Teach Yourself C along time ago, and it was (and is) a classic book.

Teach Yourself C++ was more challenging, but then, C++ is much more challenging, of course! And, now that I have gone through Teach Yourself C++ a couple of times, I see that it too is a true classic.

Now I'm going to get the Windows 2000 from the Ground Up by Schildt, and it looks really great. Addison-Wesley is a very good publishing house too; but, comparing author to publishers is like comparing apples and oranges!

Yes, the easiest is to install KDevelop and start right off with creating a *Mini-KDE* app described in the tutorial manual included to work yourself through the 14 tutorial steps of the Qt docs. Show up on irc.kde.org on #kde if you?re running into problems :) That?s also the place where you can get some ideas to fix simple things on KDE by which you can learn C++ along doing it, it?s really easy once it gets ya.

Guys, thank you for the pointers. While running for a train today, instead of buying a magazine I bought my first c++ book, teach yourself C++ in 21 days. OK, I know, I always avoid books with titles like that also but it was the only thing they had. It starts with the real basics and I'm more than a little surprised to see how much overlap there is with other lanugages, the syntax is different etc but it's not a million miles away from perl or TCL, the design aspects, general strucutres seem to have far more in common that I would have thought. C++ is compiled of course and I'm used to runtime stuff but I had a real feeling that C++ was a million miles away, some kind of god like language that was far beyond my skills, that feeling has gone (however I'm on only day 4 of the book). I doubt I'll ever do coding for a living or be the next Mr. Faure / Mr. Bastian but given a bit of time there could be a few bug fixes here and there.

One question though, is Kdevelop + QT examples / tutorials a good place for a beginner to C++, would it not be better to learn the console side first before diving in to KDE and QT? So for the ignorant question I ask because it made more sense to learn TCL and then add TK knowledge afterwards.

The best way to learn C++ (or any language for that matter) is to write a real application. Somehow, writing those "toy" programs doesn't help. With a real application you have real motivation. You ask yourself real questions and face real problems. You *know* where and when to use polymorphism (as an example) because you've seen where it works and doesn't work. You learn to use asserts and check for proper values, even though no example program in any how-to book does so. Etc.

I would recommend learning the basics with a console application. Then progress on to straight Qt programming. And after you know what's going on, then move to KDE programming.

And don't stop learning! No one C++ book will teach you everything you need to know. Get Meyers "Effective C++". Don't be content with the Qt collection classes, and learn the STL. Learn the common Design Patterns.

I might be arguing against the crowd here, but I also suggest ignoring the example KDevelop and Qt programs at the *start*. The Qt samples are meant to illustrate one particular feature, but are not always good examples of program design. And the problem of the KDevelop templates is that you never learn how to start your own program from scratch.

That's rediculous. The language does not affect the stability.
I've been using GNOME for a long time now, and it's absolutely stable.

I've been doing GTK+/GNOME programming for a year.
I also have experience on "build-in-OOP" languages such as Delphi.
GTK+ is written in C, but it is OOP.
Many C++ people consider that as a hack, but I don't.
Why would it be a hack? It works on all platforms, and it's stable.
Other than the amount of code you have to write, doing C++ OOP is not any more efficient than GTK+ OOP.
GTK+ OOP supports RTTI too. And soon it will also support Java-like interfaces.

Besides, Mozilla is C++, not C.
It only uses GDK as an Xlib wrapper, that's all.

You do know that people write programs slightly more complex than "Hello World", right ?

> It is less efficient when coding.

Which is in itself a huge problem.

> But the final result will be just as efficient as any code "real" OOP languages produce.

False. An OO language can better represent concepts it knows about. Even more with C++ which has a very efficient OO model.

> I don't mind writing a little more code.

Yes you do, just like everybody. You just don't realize it.

> In fact: writing small programs in GTK+ needs less code than QT.

As I said, people write programs more complex than "Hello World".

> Doing "normal" things doesn't take much time.
> Creating GTK+ objects takes more time, but Gob can make it as simple as C++.

Again, you hit the nail right on : creating a class in C++ *is* a normal thing, and it is simple. With GTK+, it's a hard thing to do, so much than people felt the need for a preprocessor to help doing it. And though it does help, it's still far from being as simple as in any OO langage.

> > GTK+ OO framework also has a much larger overhead than C++.

> When you wrap things up in other languages, yes.

No. The GTK+ OO framework has inherently a much larger overhead than C++.

> But who cares about those minor details?

Everybody does. What you call "minor details" are actually essential. That's the old "OO is syntactic sugar" cliché. Some people buy it because they see OO as an entirely different paradigm than good ol' procedural programming, while in fact it's an evolution of proc. programming. It's the next abstraction step. And just like procedural programming, it has to be implemented at the language level to be really useable.

You could program without for(), while() and functions, using just if() and goto. Would you do it ? Would you claim than doing it is "as efficient" ? Would you accept needing something like GOB to write a for() loop ? Wouldn't you "mind writing a little more code" ?

> well, then explain me why kde ain't written in java, if its a matter of skills.

Because even now Java isn't a viable solution on the desktop (in particular on Unix). There is of course more than just the language, but also what implementations of it are available on your platform. No matter how good the language is in theory, if the compiler sucks you won't get far.

Delphi doesn't support class operators and multiple inheritance and other things C++ does.
Does that make Delphi a huge problem?

> False. An OO language can better represent concepts
> it knows about. Even more with C++ which has a very
> efficient OO model.

An OO language provides abstraction for OO code.
But how's the final, lower-level result any better than OO in C?

Let's say you write a class in C++.
Then I disassemble that program and see what the asm instructions are.
Then I write those same instructions in asm.
And voila: the final result is the same without using an OO language.
(this is only an example; nobody would do such crazy thing anyway)

GTK+ OO is similar. It might look like a hack, but if you look at a lower level, it really isn't.

> Yes you do, just like everybody. You just don't realize it.

I said a *LITTLE* more code, not hundreds of lines.
If it was really that much then I wouldn't use GTK+.

> As I said, people write programs more complex than "Hello World".

And other people write programs less complex than Konqueror.

> No. The GTK+ OO framework has inherently a much larger overhead than C++.

Where's the proof?

> Everybody does. What you call "minor details" are
> actually essential. That's the old "OO is syntactic sugar" cliché

And why would they if the code is only 0.000000001 ms slower on a Pentium 166?

If you need to use multiple inheritance, then yes, it will become a problem. At least Delphi supports OO natively, not through syntactic conventions.

> But how's the final, lower-level result any better than OO in C?

Again : because an OO compiler knows more about what you're trying to do. Do you think that if you manually replace all your for() and while() by if() and goto, you're going to get the exact same lower-result ?

On one hand you have a compiler which understands what things like a class or a virtual function are and can represent those directly in assembly. On the other you have a compiler which only knows structs and plain functions.

> And voila: the final result is the same without using an OO language.
> (this is only an example; nobody would do such crazy thing anyway)

You really have a gift for saying yourself exactly what I mean, but without understanding it.

Yes, nobody would do such a crazy thing, because it's incredibly hard to code all these abstractions yourself. In C it's a little bit easier. In an OO language it's even easier. That's the whole point, and why C++ is more efficient than OO in C. It's just plain *easier*.

You seem to misunderstand what I mean by "more efficient" : I mean more efficient for the programmer. You write less code, make less mistakes, and the code is more readable.

It's also true that the resulting binary code will be more efficient, for the reasons I state above, but the key here is programmer's efficiency. That's why KDE, as a programming platform, is light years above Gnome, and why KDE development goes so fast.

> I said a *LITTLE* more code, not hundreds of lines.

It *is* hundreds of lines. When converting a GTK+ examples to Gtk--, on average we'd get between 2 to 3 times as less lines of code. That means a 1000 lines GTK+ program would shrink to 300-500 lines in Gtk--.

> And other people write programs less complex than Konqueror.

The typical desktop application isn't much simpler than konqueror.

> Where's the proof?

I leave it to you as an exercise to compare the sizes of GtkObject and GtkObjectClass to the size of an empty C++ class. :-)

> And why would they if the code is only 0.000000001 ms slower on a Pentium 166?

At this point I assume you've understood that I'm essentially talking about efficiency when writing code. Then again, with Gtk-- you'll also get several MB of mem overhead.

> If you need to use multiple inheritance, then yes,
> it will become a problem.

Ever heard if interfaces? Delphi supports them.
GTK+ 2.0 as well.

But multiple inheritance is considered by many people as a flaw.
I never use that feature anyway.

> Again : because an OO compiler knows more about what
> you're trying to do. Do you think that if you manually
> replace all your for() and while() by if() and goto,
> you're going to get the exact same lower-result ?

I don't know whether it can be done in C, but if it can, and it can be wrapped up in a function, then I believe it would be just as efficient as a "native" one.

> I leave it to you as an exercise to compare the sizes
> of GtkObject and GtkObjectClass to the size of an empty C++ class. :-)

How?

> Then again, with Gtk-- you'll also get several MB of mem overhead.

Which most of it is shared memory anyway.

True, GTK+ emulates OOP. And it requires more code.
But it is not so inefficient that it makes GTK+ unuseable.
Many things are wrapped up nicely in macros and functions.

Besides, the GTK+ developers aren't crazy.
If GTK+ OOP is really that bad, then the Gimp/GTK+ developers would have created a C++ toolkit instead of a C one.

If you think this looks ugly, error prone and unmaintainable, then you have an idea of how OO in C looks to any C++/Java/Python/... programmer.

> How?

Ever used the sizeof() operator ?

> Which most of it is shared memory anyway.

That's what we kept answering to our critics. Nevertheless, when the Eazel guys showed their very first prototype for Nautilus, using Gtk--, the beast was (according to Havoc) more than 30Mb large. That's one of the reasons why they were kindly invited to use C instead (although this was just before a vast improvement of mem usage in Gtk-- by Karl Nelson).

> But it is not so inefficient that it makes GTK+ unuseable.

Certainly not, nobody claims so. GTK+ is probably the best C toolkit around, way easier to use than Motif. But it is not and will never be as easy to use and powerful as Qt, and OO in C cannot be "just as good" as a real OO language.

> If GTK+ OOP is really that bad, then the Gimp/GTK+ developers would have created a C++ toolkit instead of a C one.

When the original developers of GTK+ started working on it, g++ was still at 2.7, e.g. a big pile of crap of a C++ compiler. And AFAIK none of them knew C++ anyway.

> Why would you want more than a subclass if you
> don't have multiple inheritance ?

???????????????

> To you may be. Ask a C++ or Java programmer :-).

Back in the days when I was still doing Winblow$ programming in Delphi, any C++ code looks far more messy and unmaintaiable to me.
It depends on one's experience.
Once you get used to GTK+, it won't look messy anymore.

> sizeof(GtkObject), sizeof(GtkObjectClass));

o_0
Never thought of that.

> I've seen only one so far, Andy Fountain, the guy
> who wrote the Motif books for O'Reilly.

Read all the comments at Slashdot and you'll find milions of trolls, as usual.

What I mean is that if a feature is unavailable or very hard to implement, chances are that you won't think about using it.

> Back in the days when I was still doing Winblow$ programming in Delphi, any C++ code looks far more messy and unmaintaiable to me.

And OO in C doesn't look messy to you compared to Delphi ?

> Once you get used to GTK+, it won't look messy anymore.

Of course you can get used to it. You probably can get used to OO in assembly as well. But what's the point, when you have a simpler tool at hand ? Why use a less efficient and more complicated way of doing things ?

> Multiply that by the number of people involved in
> Gnome and you start to have an idea of why it's still catching up

That's not a valid argument.
When I started doing C programming, I immediately started using GTK+.
So I had no C experience at all, yet it took me only a few weeks to learn it.
A lot of other developers have C experience and thus can learn much faster.

> So you had to learn yet another tool just to do something
> which is trivial in an OO language, and this is why
> an OO language is more efficient than OO in C.
> Haven't we been through this already ?

GOB is not difficult to learn. In fact, it took me less than half an hour.

> You claim that OO in C is every bit as good as
> an OO language. You are wrong. That's all.

No, I claimed that the final compiled code (the executeable) is just as efficient as a C++ one.