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.
Dot Categories:
Comments
I think this text needs more than two paragraphs :)
Hehe see my previus two articals. Didn't think it would go on the dot...
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... ;-)
about the larger or smaller modules:
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?)
any comments?
i agree about the return key :-)
This is a very, very debatable point.
For instance, I recently did an update to KDE2, and now I've lost kmail. There's no way I can reinstall it or compile it myself. As such I have to use mozilla (s-l-o-w!) for mail.
It's too bad, because I really can't stand moz as it now stands. It makes OS X actually seem fast, which is why I'm using it at this point.
Kmail is in KDE2. Of course you can reinstall or compile it yourself.
>This is a very, very debatable point.
Well, yes. That's what I meant by "There's no right answer, it's a tradeoff."
>For instance, I recently did an update to KDE2, and now I've lost kmail.
>There's no way I can reinstall it or compile it myself.
Say what? It's gone now or just broken? Why is there no way to reinstall it or compile it?
Very cool article.
craig
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 ...:-)
First of all, be wary of books by Herb Schildt. I've heard only bad things about them. I haven't read them myself, but I haven't read a good review of a Schildt book yet. Here are some examples:
http://www.accu.org/cgi-bin/accu/rvout.cgi?from=0au_s&file=cp001508a
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).
Here's AW's new C++ series:
http://cseng.aw.com/catalog/series/0,3841,43,00.html
Here's a really good book to learn general Linux, including the programming environment:
http://www.sobell.com/LINUX/linux.html
Have fun with C++. Learning new languages should expand your mind, and learning C++ expanded mine like no other. Some of it may be hard, but stick with it; you'll be glad you did.
Funny. I invested so much in learning C++, and now I write Java for a living. But I'm learning Qt and KDE in my "spare" time and can't wait to start contibuting to KDE. See ya in the CVS logs!
Dein
Chris
I concur. Herb Schildt is notoriously bad, and Addison-Wesley series are a sure bet. Get Lippman's "C++ Primer", or, for a lighter start "Essential C++" :
http://cseng.aw.com/book/0,3828,0201485184,00.html
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!
Herb Schildt is reknown for writing very bad books filled with errors :
http://www.accu.org/bookreviews/public/reviews/0au/s.htm
And about what you call a "true classic" :
http://www.accu.org/cgi-bin/accu/rvout.cgi?from=0au_s&file=t001453a
Herb Schildt is reknown for writing very bad books filled with errors :
http://www.accu.org/bookreviews/public/reviews/0au/s.htm
And about what you call a "true classic" :
http://www.accu.org/cgi-bin/accu/rvout.cgi?from=0au_s&file=t001453a
Have a look at Thinking in C++ from Bruce Eckel
(ISBN 0-13-979809-9). It's downloadable from
http://www.bruceckel.com
The correct link is http://www.bruceeckel.com
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.
Cheers,
Ralf
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.
To learn C++, start with small console programs. If you want to write KDE or Qt programs, KDevelop or KDE Studio are definitely a good choice.
Have a look at STL, but don't become frustrated. It's all but intuitive. The more you will appreciate the nice Qt API ;-)
Mozilla is C++-based.
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.
> The language does not affect the stability.
What's the color of the sky on your planet ?
> Many C++ people consider that as a hack, but I don't.
And you're right. But it's still not as efficient as an OO language.
> Other than the amount of code you have to write, doing C++ OOP is not any more efficient than GTK+ OOP.
*Precisely*. The "amount of code" is the key here. It's more than just sheer number or lines, it's that you also have to get them right. Hint : programmers are human.
Actually, there's a bit more than that. GTK+ OO framework also has a much larger overhead than C++.
Read the quote from Stroustrup on
http://gtkmm.sourceforge.net/philosophy.html
I put it there myself back when I was still helping maintain Gtk--. It sums it up perfectly.
> What's the color of the sky on your planet ?
White.
Hello World in C:
#include
int main()
{
printf ("Hello World!\n");
return 0;
}
Hello World in C++:
#include
int main()
{
std::cout << "Hello World!\n";
return 0;
}
Do you see difference in stability? I don't.
> And you're right. But it's still not as efficient as an OO language.
It is less efficient when coding.
But the final result will be just as efficient as any code "real" OOP languages produce.
> Precisely*. The "amount of code" is the key here.
> It's more than just sheer number or lines, it's that
> you also have to get them right. Hint : programmers are human.
I don't mind writing a little more code.
In fact: writing small programs in GTK+ needs less code than QT.
Doing "normal" things doesn't take much time.
Creating GTK+ objects takes more time, but Gob can make it as simple as C++.
> GTK+ OO framework also has a much larger overhead than C++.
When you wrap things up in other languages, yes.
But who cares about those minor details?
If I write a program in GTK+ and Gtk-- I won't notice any different in speed on my old Pentium 166 MMX.
> Do you see difference in stability? I don't.
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" ?
seems like a matter of taste to me :)
No, a matter of skills.
If you can't code faster in C++ than in C, you're doing something wrong. If you can't code faster in Java than in C++, you're doing something wrong.
Some languages are simply better than others, because they're built upon the experience gained from previously existing ones. The "it's all a matter of taste, use what you like" mantra is bullshit.
Aha, and just because C++ has some advantages over C, then I must use C++ even though I don't want to?
Linux is written in C. Yet it is very stable.
> Aha, and just because C++ has some advantages over C, then I must use C++ even though I don't want to?
No. If you enjoy C, fine. It's just that someone working on the same task in C++ will probably go faster.
> Linux is written in C. Yet it is very stable.
You can make stable code in any language. It just takes more effort in some than in others.
well, then explain me why kde ain't written in java, if its a matter of skills.
maybe 'a matter of taste' is not totally correct either, but choosing the right language for the right thing to do is, whatever that language may be.
> 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.
You can pretty much say that g++ sucks (although it is good enough for most tasks).
It doesn't fully support the C++ standard.
> You can pretty much say that g++ sucks
In some regards it does, yes. :-) But it's improving, at that's the only free compiler we have.
>(although it is good enough for most tasks).
Yes.
> It doesn't fully support the C++ standard.
No compiler does, at this moment.
g++ is among the best in that regard, though.
KDE doesn't need to be written in Java to make it a killer Java development platform - it only needs a Java api. But KDE has a Java api in the kdebindings/qtjava and kdebindings/kdejava directories.
-- Richard
> Which is in itself a huge problem.
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?
> Does that make Delphi a huge problem?
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.
> Ever heard if interfaces? Delphi supports them.
Good for them.
> GTK+ 2.0 as well.
Not "as well" I'm afraid. It's again a set of syntactic conventions and not a real language feature.
> But multiple inheritance is considered by many people as a flaw.
So is every single C++ feature, except no two people can agree on which features are flaws and which aren't. :-)
> I never use that feature anyway.
How could you, unless you use an OO language supporting it ?
> I don't know whether it can be done in C, but if it can, and it can be wrapped up in a function
Do you have any experience in programming, even in C ? Or do you totally misunderstand what I mean ?
int i;
for(i = 0; i < 10; ++i) {
/* do something */
}
====>
int i = 0;
begin_loop:
if(i < 10) {
++i;
/* do something */
goto begin_loop;
}
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.
> How could you, unless you use an OO language supporting it ?
Why would I need multiple inheritence if I just want a subclass?
> 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.
I disagree. GTK+ code still looks far better than that loop emulation.
> Ever used the sizeof() operator ?
Yes, but it doesn't work correctly.
> way easier to use than Motif.
While Motif supporters/trolls always claims the opposite. ;-)
> Why would I need multiple inheritence if I just want a subclass?
Why would you want more than a subclass if you don't have multiple inheritance ? The availability of a tool has a lot of influence on whether you feel like using it or not :-).
> I disagree. GTK+ code still looks far better than that loop emulation.
To you may be. Ask a C++ or Java programmer :-).
> Yes, but it doesn't work correctly.
#include
int main()
{
printf("sizeof gtkobject : %d\nsizeof gtkobjectclass : %d\n",
sizeof(GtkObject), sizeof(GtkObjectClass));
return 0;
}
sizeof gtkobject : 16
sizeof gtkobjectclass : 40
> While Motif supporters/trolls always claims the opposite. ;-)
I've seen only one so far, Andy Fountain, the guy who wrote the Motif books for O'Reilly. His interview was recently republished on /. even though it already was a year ago.
sizeof gtkobject : 16
sizeof gtkobjectclass : 40
thats probably because of metadata overhead.
anyway, you don't have a point there i think (for the rest, the discussion is interesting)
#include
#include
void main() {
printf("%i\n",sizeof(QObject));
}
36
oops, ignore this one (again), i didnot understand what you were trying to say.
> 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 ?
> And OO in C doesn't look messy to you compared to Delphi ?
Not anymore. It looks readable and maintainable to me.
It took me about a few weeks to get used to it.
But that applies to Delphi OO and C++ OO too.
> But what's the point, when you have a simpler tool at hand ?
You're right, and that's why I use GOB for my GTK+ objects. :)
> Why use a less efficient and more complicated way of doing things ?
Because I like C and GTK+.
> It took me about a few weeks to get used to it.
Multiply that by the number of people involved in Gnome and you start to have an idea of why it's still catching up.
> You're right, and that's why I use GOB for my GTK+ objects. :)
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 ?
> Because I like C and GTK+.
No problem with that. The debated question is not what you like, but what is more efficient. You claim that OO in C is every bit as good as an OO language. You are wrong. That's all.
> 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.
> A lot of other developers have C experience and thus can learn much faster.
Still not as fast as Qt for a C++ programmer. And that's just a one-time handicap. The big difference comes in the long run, when actually using them.
> GOB is not difficult to learn. In fact, it took me less than half an hour.
After you had learn GTK+ itself, right ? Honestly, how many classes are defined in your current project ?
> No, I claimed that the final compiled code (the executeable) is just as efficient as a C++ one.
And you are still wrong, although that's less of an issue.