Benjamin Meyer: A Tribute to KDE
Saturday, 2 June 2001 | Nstevens
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.
Comments:
Re: Benjamin Meyer: A Tribute to KDE - will - 2001-06-02
I think this text needs more than two paragraphs :)
Re: Benjamin Meyer: A Tribute to KDE - Benjamin C Meyer - 2001-06-02
Hehe see my previus two articals. Didn't think it would go on the dot...
The value of large modules - Otter - 2001-06-02
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... ;-)
Re: The value of large modules - maxwest - 2001-06-02
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 :-)
Re: The value of large modules - Tony A. Emond - 2001-06-03
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.
Re: The value of large modules - Erik - 2001-06-04
Kmail is in KDE2. Of course you can reinstall or compile it yourself.
Re: The value of large modules - Otter - 2001-06-04
>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?
Re: Benjamin Meyer: A Tribute to KDE - Craig - 2001-06-02
Very cool article. craig
Re: Benjamin Meyer: A Tribute to KDE - Fred123 - 2001-06-02
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 ..... :-)
Re: Benjamin Meyer: A Tribute to KDE - Brian - 2001-06-02
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?
Re: Benjamin Meyer: A Tribute to KDE - Sagittarius - 2001-06-02
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 ...:-)
Stick with Addison-Wesley - Chris - 2001-06-02
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: <a>http://www.accu.org/cgi-bin/accu/rvout.cgi?from=0au_s&file=cp001508a</a> 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: <a>http://cseng.aw.com/catalog/series/0,3841,43,00.html</a> Here's a really good book to learn general Linux, including the programming environment: <a>http://www.sobell.com/LINUX/linux.html</a> 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
Re: Stick with Addison-Wesley - Guillaume Laurent - 2001-06-02
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
Re: Stick with Addison-Wesley - Patrick Kennedy - 2001-08-20
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!
Re: Stick with Addison-Wesley - Guillaume Laurent - 2001-08-20
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
Re: Stick with Addison-Wesley - Guillaume Laurent - 2001-08-21
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
Re: Stick with Addison-Wesley - Richard Bos - 2001-06-02
Have a look at Thinking in C++ from Bruce Eckel (ISBN 0-13-979809-9). It's downloadable from http://www.bruceckel.com
Re: Stick with Addison-Wesley - Anonymous - 2001-06-03
The correct link is http://www.bruceeckel.com
Re: Benjamin Meyer: A Tribute to KDE - Ralf Nolden - 2001-06-02
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
Re: Benjamin Meyer: A Tribute to KDE - Brian - 2001-06-03
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.
Re: Benjamin Meyer: A Tribute to KDE - David Johnson - 2001-06-05
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.
Re: Benjamin Meyer: A Tribute to KDE - Alexander Kuit - 2001-06-06
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 ;-)
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-02
Mozilla is C++-based.
Re: Benjamin Meyer: A Tribute to KDE - ac - 2001-06-02
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.
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-02
> 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.
Re: Benjamin Meyer: A Tribute to KDE - ac - 2001-06-02
> What's the color of the sky on your planet ? White. Hello World in C: #include <stdio.h> int main() { printf ("Hello World!\n"); return 0; } Hello World in C++: #include <iostream.h> 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.
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-02
> 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" ?
Re: Benjamin Meyer: A Tribute to KDE - ik - 2001-06-02
seems like a matter of taste to me :)
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-03
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.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-03
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.
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-03
> 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.
Re: Benjamin Meyer: A Tribute to KDE - ik - 2001-06-03
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.
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-03
> 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.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-03
You can pretty much say that g++ sucks (although it is good enough for most tasks). It doesn't fully support the C++ standard.
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-03
> 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.
Re: Java isn't a viable solution on the desktop? - Richard Dale - 2001-06-03
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
Re: Benjamin Meyer: A Tribute to KDE - ac - 2001-06-03
> 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?
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-03
> 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.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-03
> 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.
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-03
> 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.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-03
> 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. ;-)
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-03
> 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 <gtk/gtkobject.h> 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.
Re: Benjamin Meyer: A Tribute to KDE - ik - 2001-06-03
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 <qt/qcombobox.h> #include <stdio.h> void main() { printf("%i\n",sizeof(QObject)); } 36
Re: Benjamin Meyer: A Tribute to KDE - ik - 2001-06-03
oops, ignore this one (again), i didnot understand what you were trying to say.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-03
> 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.
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-03
> ??????????????? 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 ?
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-04
> 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+.
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-04
> 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.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-06
> 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.
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-06
> 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.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-06
> 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. To be honest, it took me much longer to learn QT than GTK+ (and I'm still learning). And yes, I'm telling you the truth. > After you had learn GTK+ itself, right ? > Honestly, how many classes are defined in your > current project ? (???????????????????) And one has to learn C++ because he/she can use classes or QT. What's your point? > And you are still wrong, although that's less of an issue. What about Delphi classes then? A TComponent is large yet nobody complains about it and happily continues to do RAD.
Re: Benjamin Meyer: A Tribute to KDE - ik - 2001-06-03
you want multiple inheritance if you want a class to be a child of two parents. That situation happens a lot imagine you have an object you have to register in some list, and therefore it should inherit the foo class. but you also want it to have to be a bar (for similar or other reasons), so you also want to inherit from the bar class. . i am a beginning c++ programmer, just learned about mult. inh. (for dcop objects that also have to be widgets, otherwise you have to make two objects with almost the same interface.) , and i can say i encountered a lot of situations before where i could have used mult. inh. but i did not because i did not know it could be done in c++. maybe you can do similar things with interfaces ...
Re: Benjamin Meyer: A Tribute to KDE - Eric Nichlson - 2001-06-03
At 66 to 75 characters C wins, although if you leave out ".h" and "std::" C++ is only 68 (why does the word iostream have to be so dang long!?).
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-03
You can't leave out "std::" (well with g++ you currently can but that won't last), unless you add "using namespace std" before referring to cout :-).
Re: Benjamin Meyer: A Tribute to KDE - Ramiro Tasquer - 2001-06-03
Are you sure? Why don't you check this comparative? and you will know which one use more code.. Ramiro
Re: Benjamin Meyer: A Tribute to KDE - David Johnson - 2001-06-05
<em>It is less efficient when coding. But the final result will be just as efficient as any code "real" OOP languages produce.</em> <p>The ONLY efficiency in programming is the programmer's efficiency. And by "programmer" I mean all those people who write, modify, add to, and especially, maintain, the program. Who cares how many cycles a program shaves off of execution when few people can maintain it? <p>You know, it's possible to write object-oriented programs using assembler. So why isn't anyone doing it? Surely OOP in assembler must be extremely efficient...
Re: Benjamin Meyer: A Tribute to KDE - Philippe Fremy - 2001-06-05
inheriting from a gtk widget: #ifndef __GTK_DIAL_H__ #define __GTK_DIAL_H__ #include <gdk/gdk.h> #include <gtk/gtkadjustment.h> #include <gtk/gtkwidget.h> #ifdef __cplusplus extern "C" { #endif /* __cplusplus */ #define GTK_DIAL(obj) GTK_CHECK_CAST obj, gtk_dial_get_type (), GtkDial) #define GTK_DIAL_CLASS(klass) TK_CHECK_CLASS_CAST (klass, gtk_dial_get_type (), GtkDialClass) #define GTK_IS_DIAL(obj) GTK_CHECK_TYPE obj, gtk_dial_get_type ()) typedef struct _GtkDial GtkDial; typedef struct _GtkDialClass GtkDialClass; struct _GtkDial { GtkWidget widget; /* update policy (GTK_UPDATE_[CONTINUOUS/DELAYED/DISCONTINUOUS]) */ guint policy : 2; /* Button currently pressed or 0 if none */ guint8 button; /* Dimensions of dial components */ gint radius; gint pointer_width; /* ID of update timer, or 0 if none */ guint32 timer; /* Current angle */ gfloat angle; /* Old values from adjustment stored so we know when something changes */ gfloat old_value; gfloat old_lower; gfloat old_upper; /* The adjustment object that stores the data for this dial */ GtkAdjustment *adjustment; }; struct _GtkDialClass { GtkWidgetClass parent_class; }; GtkWidget* gtk_dial_new(GtkAdjustment *adjustment); guint gtk_dial_get_type(void); GtkAdjustment* gtk_dial_get_adjustment(GtkDial *dial); void gtk_dial_set_update_policy(GtkDial , dial,GtkUpdateType policy); void gtk_dial_set_adjustment (GtkDial dial, GtkAdjustment *adjustment); #ifdef __cplusplus } #endif /* __cplusplus */ #endif /* __GTK_DIAL_H__ */ #include <math.h> #include <stdio.h> #include <gtk/gtkmain.h> #include <gtk/gtksignal.h> #include "gtkdial.h" #define SCROLL_DELAY_LENGTH 300 #define DIAL_DEFAULT_SIZE 100 /* Local data */ static GtkWidgetClass *parent_class = NULL; guint gtk_dial_get_type () { static guint dial_type = 0; if (!dial_type) { GtkTypeInfo dial_info = { "GtkDial", sizeof (GtkDial), sizeof (GtkDialClass), (GtkClassInitFunc) gtk_dial_class_init, (GtkObjectInitFunc) gtk_dial_init, (GtkArgSetFunc) NULL, (GtkArgGetFunc) NULL, }; dial_type = gtk_type_unique (gtk_widget_get_type (), &dial_info); } return dial_type; } static void gtk_dial_class_init (GtkDialClass *class) { GtkObjectClass *object_class; GtkWidgetClass *widget_class; object_class = (GtkObjectClass*) class; widget_class = (GtkWidgetClass*) class; parent_class = gtk_type_class (gtk_widget_get_type ()); object_class->destroy = gtk_dial_destroy; widget_class->realize = gtk_dial_realize; widget_class->expose_event = gtk_dial_expose; widget_class->size_request = gtk_dial_size_request; widget_class->size_allocate = gtk_dial_size_allocate; widget_class->button_press_event = gtk_dial_button_press; widget_class->button_release_event = gtk_dial_button_release; widget_class->motion_notify_event = gtk_dial_motion_notify; } static void gtk_dial_init (GtkDial *dial) { ... -------------------------- Inheriting a widget with Qt: class QDial: QWidget { QDial(QWidget * parent): QWidget(parent) { ... ========================= I see a difference! I do not invent this, this is pasted from the tutorial of gtk: http://www.gtk.org/tutorial/sec-creatingawidgetfromscratch.html When you see this amount of code necessary in gtk to handle the OOP, you understand that: - a gtk programmer spends lot of time on doing unuseful things (inheritance in C instead of just C++) - a gtk programmer needs to get this complicated stuff right - the C compiler can't check the OO things, you rely on the programmer - a lot of things that should be automatic are left to the programmer > In fact: writing small programs in GTK+ needs less code than QT. this is not true. I am writing an article about this that should be ready in a few month to prove it. > Creating GTK+ objects takes more time, Yes, two hours to write the code where 5 lines of C++ will do it. Are you going to tell me that usually, you don't create objects ? > but Gob can make it as simple as C++. What is Gob ? A gtk object generator ? The only thing gtk is really good at is wrapping. Because it is C, it is easy to wrap a gtk and program with a _good_ language (good in the sense of suited to the task).
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-06
> Are you going to tell me that usually, you don't create objects ? I doubt he would, but yet that's most probably the case. A typical GTK+ program has only a handful of huge classes. A C++ program can exercise the OO paradigm much better. > What is Gob ? GTK+ Object Builder http://www.5z.com/jirka/gob.html > Because it is C, it is easy to wrap a gtk and program with a _good_ language Not even :-). OK, it's probably true with scripting languages like Python.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-06
I just copy and paste things from a template and rename some things...
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-06
> Yes, two hours to write the code where 5 lines of > C++ will do it. Are you going to tell me that usually, > you don't create objects ? I only create objects for large programs. But GTK+ doesn't require you to inherid things. Ever heard of copy and paste? Renaming things takes less than 3 minutes. In fact, all the objects I write never look as messy as that code above. They have newlines and identications. If you write C++ code without newlines and identications it will look messy and unmaintainable too.
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-06
> I only create objects for large programs. And in C++ you can create some whenever you want. You have no idea how far tiny helper classes can get you. > But GTK+ doesn't require you to inherid things. Yes it does, you have to inherit GtkObject. > Ever heard of copy and paste? > Renaming things takes less than 3 minutes. This is becoming hilarious. :-) > In fact, all the objects I write never look as messy as that code above. > They have newlines and identications. Riiight. When it comes to this point of denial I think we can end this thread.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-06
> Yes it does, you have to inherit GtkObject. No it doesn't. GtkWidget *win; win = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_window_show (win); And voila: a window without inheriting an object. > Riiight. > When it comes to this point of denial I think > we can end this thread. You don't agree? Remove the idents and newlines from your C++ code and see what it will look like!
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-06
> No it doesn't. Helloooo, we're talking about how to create a new class here. Not instantiate an object. > You don't agree? Remove the idents and newlines from your C++ code and see what it will look like! ROTFL. Yes, absolutely, you're right, anything it takes to end this thread. Yes, you're using a great tool. There.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-07
> Helloooo, we're talking about how to create a > new class here. Not instantiate an object. And I was talking about instantiate an object, noy about how to derive a class. :)
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-07
Now I *really* wish I could see the look on the face of someone who, having read the whole thread, stumbles on this final statement of yours.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-09
Something like this? o_0
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-06
BTW, a lot of the above code is not neccesary. #include <gdk/gdk.h> #include <gtk/gtkadjustment.h> #include <gtk/gtkwidget.h> Completely useless. Can be replaced with: #include <gtk/gtk.h> or #include <gnome.h> #ifdef __cplusplus extern "C" { #endif /* __cplusplus */ Only useful in C libraries. Useless in programs. guint policy : 2; /* Button currently pressed or 0 if none */ guint8 button; /* Dimensions of dial components */ gint radius; gint pointer_width; /* ID of update timer, or 0 if none */ guint32 timer; /* Current angle */ gfloat angle; /* Old values from adjustment stored so we know when something changes */ gfloat old_value; gfloat old_lower; gfloat old_upper; /* The adjustment object that stores the data for this dial */ GtkAdjustment *adjustment; You forgot to include these fields in your C++ class. These fields have nothing to do with inheritance, but the internals of the widget. GtkAdjustment* gtk_dial_get_adjustment(GtkDial *dial); void gtk_dial_set_update_policy(GtkDial , dial,GtkUpdateType policy); void gtk_dial_set_adjustment (GtkDial dial, GtkAdjustment *adjustment); Idem dito. #include <stdio.h> #include <gtk/gtkmain.h> #include <gtk/gtksignal.h> Useless. #include <gtk/gtk.h> does it all.
Re: Benjamin Meyer: A Tribute to KDE - Philippe Fremy - 2001-06-06
I do not pretend the above gtk code was optimised to be small, nor that the kde code is an exact equivalent. But it gives the general idea of what gtk vs kde programming is. There were some problem of copy/paste, this is why the code is not properly indented. The original looks better, as you can check with the url. About copy/pasting code, don't you know that it is dangerous ? Especially in gtk where the compiler can't check anything. If you get one struct wrong, I guess the whole code is fucked-up. True ? Also, you need to realise that what I have just copied in the previous message is _the official gtk tutorial_. This is what people are faced with when they want to learn gtk. If you think the above code is not good, then correct the tutorial. You tell me about gob, but there is no mention of gob in the tutorial. If I want to program in gtk, I will produce code like that because this is what this tutorial told me. Compare with Qt: the tutorial can be done in 2 days. A new C++ programmer should have no problem producing a qt application in one week. Qt has only one new concept, signal and slots, which is easy learned. The remaining of Qt is so clean that it could be the basis of an OO lesson. The same goes for the kde tutorial. The tutorial of gtk is very long, you need probably more than one week to finish it. No C beginner can do it. There are lot of concepts in here to understand. You need to understand the OO abstraction, there are references to XWindow, there are many macros you are afraid to understand how they work, you must supply by hand a lot of information and there are many things you just do but don't understand. I wonder why there are that many gtk application out there when I read this. An intersting shot would be to take the Qt tutorial and examples, and to rewrite them in gtk. Then compare the results in terms of ease of read, ease of programming, source size, ... I am doing exactly this right now with gtk and I am having a lot of fun. Notice also that except for the gimp and perhaps nautilus, there are very few ambitious project written from scratch in gtk. This is very different from kde where you have some very ambitious projects, most of them written from scratch, that can compete (and even sometimes beat) gnome projects. And they are done by very few developers (we didn't waste 13 million $ in a filemanager!). Ask yourself why!
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-06
> About copy/pasting code, don't you know that it > is dangerous ? Especially in gtk where the > compiler can't check anything. If you get one > struct wrong, I guess the whole code is fucked > up. True ? Yes, I realize that. But I know exactly what to rename. Even though the compiler doesn't check anything, Gtk+ will. It will give warnings like "WARNING: class FooBar is smaller than it's parent" and then you know you did something wrong. > Also, you need to realise that what I have just > copied in the previous message is _the official > gtk tutorial_. This is what people are faced > with when they want to learn gtk. I know that. And that's one of the reasons why idents and newlines are so important. > If you think the above code is not good, then > correct the tutorial. I never said that. I only said it looks messy because it lacks newlines and idents. > You tell me about gob, > but there is no mention of gob in the tutorial. Of course not. Gob is relatively new and the tutorial is outdated. And Gob is not part of GTK+. > Qt has only one new concept, signal and slots, > which is easy learned. The remaining of Qt is > so clean that it could be the basis of an OO > lesson. I learned GTK+' signal system quite easily you know. And I still don't see much difference between GTK+ signals, QT Signals and Delphi Events. > No C beginner can do it. I did. > I wonder why there are that many gtk > application out there when I read this. And I wonder why there are so many QT programs out there when I read the tutorial. It took me days to find out that I need moc to be able to create QT classes. And I still have to find out how signal slots work. > This is very different from kde where you have > some very ambitious projects, most of them > written from scratch, that can compete (and > even sometimes beat) gnome projects. The opposite is also true. Some Gnome projects can compete/beat KDE projects. And both can compete/beat Windows and MacOS software and FooBar 2.0 in l33t mode with the flying turtles. > And they > are done by very few developers (we didn't > waste 13 million $ in a filemanager!). Eazel spend 13 million $ for the sake of Nautilus and GNOME. That's a deed that shows their kindness and good faith. And now you're bitching about it? C'mon!
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-06
Just for the record : > Completely useless. Can be replaced with: > #include <gtk/gtk.h> > or > #include <gnome.h> and drive up your compile times through the roof. This is explicitly advised against (even in C++ :-).
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-06
We're waiting for gcc 3.0 with pre-compiled headers...
Re: Benjamin Meyer: A Tribute to KDE - Guillaume Laurent - 2001-06-06
AFAIK they are scheduled for 3.1 or later, not 3.0.
Re: Benjamin Meyer: A Tribute to KDE - dc - 2001-06-07
AAAAAARRRGHHHH!!!! (*falls down a big, black hole*)
Both C++ and C w/ OOP style are crappy and bloated - TrueOO ObjectiveC - 2001-06-04
... compared to ObjC. ObjectiveC = C with about 5 other things to learn it is a simple powerful language with way more flexible approach to OO than C++, no gigantic templates, and simple easy to maintain code. GNUStep is a framework built out of ObjC and it is very high quality. ObjC is why basically 4 people working part time have been able to create GNUStep with **NO** corporate backing (no Trolltech or Redhat or foundation to underwrite things). Before either KDE or GNOME people gloat too much they should go and READ some of the GNUStep code. Like the workspace manager - sure it's alpha and not that functional: **ONE** guy maintains it in his spare time. Please note how FEW lines of code are in it as well. Before you complain about lack of documentation READ the code. No C Java or C++ developper can honestly say that they can't understand ObjC after 5 minutes. Oh and whipdeedoo on the cross platform stuff, GNUStep has run on a half dozen Unix platforms, Windows, MacOSX, and OpenStep for years now. It's also got a bridge to Java, and Guile and there's and ObjC<->Python project too ... This is all with fewer developpers than there are female senior citizens on the KDE mailing list.
Re: Both C++ and C w/ OOP style are crappy and bloated - Erik - 2001-06-04
You say because GNUStep can create a DE with fewer developers ObjectiveC is better than C++. But you ignore that KDE is much more than just a bare DE. It has a browser, mail klient, media players, music creating applications, network transparent sound server, many games, ... (By the way, shouldn't KDE use K or K++ instead? :-)
Re: Both C++ and C w/ OOP style are crappy and bloated - Guillaume Laurent - 2001-06-04
Yes, ObjC is a very nice language. I played with it a few years ago. I even added regexp support to GnuStep string class. Unfortunately, ObjC is also completely dead, which is quite a shame. And speaking of overhead, it also has quite a lot. But you're right, there's no question it beats C++ hands down as far as ease of use is concerned. The OO model is also quite powerful.
KDE/GNUStep Foundation Kit/Objective-C integration - Richard Dale - 2001-06-06
I'm working on Objective-C bindings for Qt/KDE, and I'll try and get them done in time for KDE 2.2. I think KDE and the GNUStep Foundation Kit should make a good combination. Quite a lot of the really good stuff in GNUStep is in the Foundation kit, as opposed to the Appkit side. I don't think Objective-C is dead because it is now the native language of Mac OS X, and Apple have at least one full time maintainer, making sure it doesn't die on them :-). -- Richard
Re: Benjamin Meyer: A Tribute to KDE - Kevin Puetz - 2001-06-03
hmm... moz is C++. sorry, but bzzzt. So is M$ stuff, for that matter (with MFC though, which hardly counts) :-). and the linux kernel is C and rock-solid.
microsoft stuff is C++ - Will Stokes - 2001-06-07
actually, most things at microsoft are written in C. only more recent projects have been done with C++. Windows is C.
Want to write an OS instead? - Martin Nilsson - 2001-06-08
Do you want to write an OS instead in this well structured, coordinated, single-distributed form. Then you should run, not walk over to www.FreeBSD.org and start contributing.
Re: Want to write an OS instead? - ye wint soe htay - 2002-12-16
Yeah I agree with you but what's the starting point for newbies. There is a lot of OS design book but few of books how to implement that design.
Re: Want to write an OS instead? - V Fredrick - 2003-05-29
Really I agree with you, there are a lot of OS design books, which teach you lot about scheduling and interprocess communication and the like, but they never get down to explaining how to really code one. I am also deeply interested in making an OS. Will you and anybody reading this help me in any way you can. By the way, if you want to get a list of interrupts for the PC, I think one should visit http://www.pobox.com/~ralf
Re: Want to write an OS instead? - Richard Moore - 2003-05-29
I suggest you read Tannenbaum's book, which not only talks about the details of implementing an OS (Minix) but actually does it and includes the source code. You should also not that Ralf Brown's interupt list is mainly about software interupts (ie. DOS system calls) and almost totally useless to anyone trying to write an OS of their own. Rich.
Re: Want to write an OS instead? - yeswanth - 2005-07-26
send me sample code,books,tools,documets regading writing an OS