GNU site? Aren't we talking about Qt? http://www.trolltech.com/developer/faqs/free.htm l Refer to 'Can I make software with the Qt Free Edition and release it under the GPL, BSD, or Artistic license?'
KDE would be so much more fun without all those clueless people spreading nonsense.
But the thing that made the different most probably wasn't KDE recompile, but instead some of the other stuff I listed ( O(1) scheduler, prelink, whatever). Or maybe it was so much faster just because you believed it must be so much faster after you recompiled it.
The claim about distributions not optimizing for newer CPUs is not true. They usually use something like -march=i486 -mcpu=i686, which means it uses instructions that at least i486 knows, and optimizes them for i686 CPUs. I personally doubt recompiling KDE with better compile flags that those in distro shipped packages makes noticeable difference. Things like prelink, O(1) scheduler, better mapping of binaries into memory, or code optimizations of KDE are things that may make difference.
Re:But what I am rellay looking forward to...
on
KDE 3.1 Released
·
· Score: 1
> > (The 'save this process' trick is a way to have a set number of Konqueror processes stay alive after you quit the last Konqueror window. This way, the next time you click on the Konqueror icon, it re-uses the last process that was open, which is a nice little hack that makes Konq appear to launch faster when it's not actually launching at all.)
> So.. just like Internet Explorer then?:) [duck] > Well, it seems like a good idea, but why not just shove it into kdeinit and be done with it?
Because it's actually not like Internet Explorer (even though being called 'preloading', it's rather 'reusing' - but reusing is already something else, and I couldn't come up with a better name;) ).
Glueing it in kdeinit would make Konqueror load during KDE startup, making it (=KDE startup) slower. The way it's done now first Konqueror startup takes longer, because it's not loaded yet, but after quiting, it's kept for reusing later. Or, simply said, it's not part of kdeinit because that would be a horrible hack, the current implementation, despite having a good amount of voodo magic in it, can be considered a quite clean solution.
As to having it in 3.1, it's not in 3.1.0, but it's possible it will be backported to some later 3.1.x version.
Re:A little more information
on
Adopt a KDE Geek
·
· Score: 2, Informative
Hmm, ok, more precisely said, the linking itself is slow. No wonder, ld has to load the huge.o files created by gcc (huge because of all the debug info and things duplicated in every.o). For example all.o files here for libkdeui.so are together 45MiB (101 files), forming 21MiB large libkdeui.so. Creating the library needs almost 30s here (1Ghz Athlon, hdparm shows disk can do 40MiB/s). I don't know how about you, but I call that slow, regardless of what exactly is causing this.
Re:Ok, I have a solution for them.
on
Adopt a KDE Geek
·
· Score: 1
> Get together with the Gnome geeks, combine the two and spend 1 year making it smaller and faster.
ONE year? Oh come on, you have absolutely no idea what you're talking about.
> and to hell with chasing the unuseable do everything file manager... rip the damned html and other readers fro mthe file managers... Cripes you guys, Nautilus and Kfm both suck horribly now... and it's dragging the wm down with it.
And here you don't know what you're talking about either. FIrst of all, KDE's filemanager is called Konqueror, since several years already. Second, the performance of a filemanager is hardly going to drag down the wm. And third, khtml and other readers are not integrated in Konqueror, so they can't be ripped off.
> what's next xmms is going to be increased in size by a factor of 10?
Why? You don't think it's already bloated enough for a thing that just plays music?
Re:A little more information
on
Adopt a KDE Geek
·
· Score: 2, Informative
2a: You apparently never tried to compile a larger C++ project. GCC needs considerably more time to compile C++ code than C. In general, the GNU toolchain has worse support for C++ as compared to C (yes, C++ is more complicated than C, but I don't think it's _that_ much). Precompiled headers will hopefully help here.
2b:No wonder remaking kernel after changing one module is so fast. Usually nothing except the module itself depends on it, so nothing else needs to be rebuilt. But if somebody commits a change to some of the kdelibs header files, many files have to be rebuilt.
1a: Most people probably don't want even to patch and compile even their GCC. It's just one more thing to take care of.
1b: Moreover, GCC is not the only bottleneck. The linker (not ld.so, but ld, the one creating binaries) is pretty slow as well. Or you could try debugging some KDE app (with debug info compiled in) in GDB - THAT will teach you what 'slow' really means (and maybe you'll even suddenly find KDE's performance quite acceptable).
> But far less than Konqueror is built into KDE.;) With Win, I can at least set the browser I want to use. I can't figure out how to make KDE apps use anything but Konq
Just go to file associations config dialog, and for text/html move Konqueror down or Mozilla up in the preference order. Now press Alt+F2 and type 'kde.org'. Happy now?:)
There aren't any really (well, at least not more than in other pieces of code). Let's for example have a look at the table comparing gtkmm and Qt linked from the article (this one http://www.murrayc.com/murray/talks/2002/GUADEC3/s lides/html/img6.htm). For a guy who's supposed to know C++ so well his arguments have rather weak base ground, so he's either not that good, or he's just badmouthing Qt without knowing the things.
Moc extends C++: Oh yeah, telling this to people believing moc is a preprocessor can be hard, but moc extends C++ about as much as Doxygen. Moc is a code _generator_ (or call it precompiler), it's not needed to preprocess the sources, programs written in Qt are valid C++, otherwise one wouldn't be able to compile it with so many C++ compilers. What moc does is it analyzes headers files with few tags added, and for reasons like making it easily readable those tags are created using few #define macros. If TT wanted, they could be written in comments, just like for Doxygen, and it would be perfectly perfectly pure C++, yet there wouldn't be any real difference. In fact, it would be possible to write Qt code even without moc, but one would have to hand-write all the generated code, and that would probably get some people in madhouse.
Containers: Qt has to run on a number of quite old and crappy platforms (unfortunately, I'd be happy if TT dropped the support for them too). That's the real world. It's easy to limit a brand new library (which gtkmm2 is) to using things like that, but there are still C++ compilers in use that can't handle things like that. Some key design decision for Qt were made many years ago, and some (paying) developers wouldn't be happy if Qt completely changed every year. Moreover, Qt3.x has support for STL (I don't know how good though, I don't use it), and maybe Qt4.x will have its own containers only for backwards compatibility, and will prefer STL.
Namespaces: Qt is in a sort of namespace, and it should be sort of namespace clean (everything starting with Q). Since for KDE4 it's planned to have it completely namespace clean, including plugins, etc., Qt4 will be maybe in its own namespace too. Not that putting it in a real C++ namespace will make that much difference.
Memory management: One can delete widgets in Qt, and they will be automatically removed from the parent, who's otherwise responsible for the deleting (and getting used to this simplifies things). It's also not true you can't create Qt classes on stack, I do that sometimes when it fits. The truth is that it doesn't fit most of the time.
GNOME classes: Let's skip this one.
Widget containers: I don't know enough about the way it's done in gtkmm, so let's skip this one too. It's doesn't matter much anyway, I don't have any problems with separate layouts in Qt (in fact it may be easier to code the layouts that way, but that's just a guess).
Typesafe signal handlers: Well libsig++ has its problems too, like possibly increased compile time with already slow enough g++, and the compilers need to be very good at handling templates, which g++ wasn't not that long time ago. http://doc.trolltech.com/3.0/templates.html might be a good read in case you wonder why Qt still uses moc and not libsig++.
License: The table misses QPL and commercial licenses for Qt. TT developers also have to eat, and people need to be payed in order to e.g. write as good documentation as Qt's is (just compare it to gtkmm's). If you can't handle the fact somebody tries to make money and yet is so Open Source friendly, just shut up, ok? I can undestand some people prefer Gtk+ just because of LGPL, but that's no reason for TT bashing.
Development: There are at least two places where Qt is discussed, for the first one see mailing lists section on TT www site, the other place is KDE lists. For a commercial company, their handling of bugreports and suggestions is quite good. (Not to mention that those FSF fanatics screaming about Qt not being Free(tm) should actually love it - it's GPL'd, not LGPL'd and that's the one true RMS way, isn't it?)
I'm not saying Qt is a perfect thing. Nothing is. There are certainly things that could be better, some of them are there because of the wide platform support, backwards compatibility, some of them are there for other reasons. But there's no valid reason to call Qt bizzare or insane. It's one of the best toolkits in the world, and I mean it.
Don't worry, GNOME has its army of trolls too. Last week in three discussion somebody said something like "it's easier to code for GNOME and it has much better technologies", yet after I asked "why and which ones", nobody answered anything specific (BTW, are you going to tell me?).
KDE has its share of trolls, GNOME has its share of trolls (including you and in the past even Miguel de Icaza himself), so what makes KDE worse?
Oh, and "integrated" of course means more than just using KParts... for example having one file open dialog, instead of having one official that sucks and a couple of others in some apps where they try to make one that doesn't suck.
> There were rumblings at one point, if I'm not mistaken, that OO.o may get ported to GTK2, which would be cool.
But there also were rumblings that porting OO to Gtk/Bonobo is just a good joke. Given the fact that OO is C++ and doesn't have anything in common with GNOME from the programmers point of view, by the time OO is ported to GTK/Bonobo, KOffice or GNOME Office will be most probably as good as OO.
> I'll agree that that stuff should not be on by default
It should be on by default, as the BFUs most needing this feature would have trouble finding out how to turn it on (if they knew there was something like that). More skilled people are expected to have no trouble finding out how to turn it off. Well, and then there are also idiots like this one...
> Yes, I do have specific complatins about the KDE UI and I have expressed them in various places, but they will never be addressed, because they apply to the general concept of KDE: Not making any decisions. Wether the menu bar is global or inside the application window should never be optional - this is a fundamental decision that should be made by the developers once for all. The same goes for button placements and the terminology used in programs.
I like the global menubar. It's faster than when the menubar is in the application window. However, there are many people who are used to the menubar in the application window. So what now, which one to drop? You won't get people to agree on this, not to mention that this specific feature is very cheap in resources. Different terminology is of course a problem, feel free to help fixing it. And I don't see any problem with button placement, what exactly is supposed to be wrong with it?
> If you write an application, you want to know what the user's system looks like. Does it use 3D or 2D icons? How does the system use bevels and mouseovers? Is there a per-window or a per-application menu?
Who gives a damn? It's not important for the application if the icons are 2D or 3D or where the menubar is.
> Where am I supposed to put OK and Cancel buttons in dialogs? What colors am I supposed to use for which meaning? Making all of this a user option makes it impossible for developers to write applications that fit into the user's system.
So if I take advantage of KDE libraries that take care of many such things, my application won't fit in the system? Interesting.
> For example: Neither KDevelop nor Opera are able to deal with a global menu bar. Opera retains a per-window menu bar and KDevelop places some dialogs behind the menu bar, making their title bars inaccessable. And if you want real fun, activate global menu bars and focus-follows-mouse in KDE.
I'd say KDevelop is simply broken in this respect (which can be fixed), and Opera doesn't support the global menubar because it's not a KDE application. And after trying focus-follows-mouse, I didn't have any fun, the only difference I noticed was a focus policy that I don't like.
> Now, if you really like KDE I suggest that somebody set up a web site, download all the KDE source and set some democratic voting system to decide what parts of KDE are junk.
Good luck. And don't be too disappointed to find out that the factors most reponsible for the memory usage are the size of the libraries and inefficient dynamic loader in glibc, for speed the flexibility, ease of development and consistency. So, what will be the part to remove first? There will be never again cool games fitting in 8KiB memory like Jet Pac 20 years ago, and comparing KDE with IceWM in certain aspects is comparing apples with oranges.
But otherwise, if somebody really wants to work on optimizing KDE, your patches are of course welcome.
Well, since I managed to write in KDE3 in languages like Czech (accented characters), Russian (cyrilics) and Hebrew (RTL), the problem with you being unable to write in Latvian is probably not a KDE problem. Do you have locale set properly? Do you have unicode fonts (like e.g. those ttf ones from MS)? Do you have the proper keyboard layout?
The only thing the article really says is that GNOME1 uses less memory than KDE3. Which is no wonder, KDE1 used less memory than KDE3 too. You should try GNOME2 - it's just as memory hungy as KDE3(both the environment itself and apps themselves - I bothered to check it, and yes, I tried to make the comparison fair).
In fact, unless GNOME2 will get some optimizations in this area, KDE3 will need less memory after prelink finally becomes available.
You, just like others, didn't get the (IMHO) ironic meaning of the post (reversing everything). At least guessing from the gtk file selector comment - I don't believe a sane person could like that poor excuse for a file selector.
KDE taking 95MiB? Either your build is pretty broken, or you're one of those many many people who think they know how to measure memory usage but don't (because probably nobody really does:-/ ).
Slashdot Mirror
GNU site? Aren't we talking about Qt?
m l
http://www.trolltech.com/developer/faqs/free.ht
Refer to 'Can I make software with the Qt Free Edition and release it under the GPL, BSD, or Artistic license?'
KDE would be so much more fun without all those clueless people spreading nonsense.
You should check your facts first. It's perfectly fine to develop e.g. BSD-lincensed code with Qt.
But the thing that made the different most probably wasn't KDE recompile, but instead some of the other stuff I listed ( O(1) scheduler, prelink, whatever). Or maybe it was so much faster just because you believed it must be so much faster after you recompiled it.
The claim about distributions not optimizing for newer CPUs is not true. They usually use something like -march=i486 -mcpu=i686, which means it uses instructions that at least i486 knows, and optimizes them for i686 CPUs. I personally doubt recompiling KDE with better compile flags that those in distro shipped packages makes noticeable difference. Things like prelink, O(1) scheduler, better mapping of binaries into memory, or code optimizations of KDE are things that may make difference.
BTW, even this may make for sure more difference that recompiling : http://dforce.sh.cvut.cz/~seli/download/tips.html
> > (The 'save this process' trick is a way to have a set number of Konqueror processes stay alive after you quit the last Konqueror window. This way, the next time you click on the Konqueror icon, it re-uses the last process that was open, which is a nice little hack that makes Konq appear to launch faster when it's not actually launching at all.)
:) [duck]
;) ).
> So.. just like Internet Explorer then?
> Well, it seems like a good idea, but why not just shove it into kdeinit and be done with it?
Because it's actually not like Internet Explorer (even though being called 'preloading', it's rather 'reusing' - but reusing is already something else, and I couldn't come up with a better name
Glueing it in kdeinit would make Konqueror load during KDE startup, making it (=KDE startup) slower. The way it's done now first Konqueror startup takes longer, because it's not loaded yet, but after quiting, it's kept for reusing later. Or, simply said, it's not part of kdeinit because that would be a horrible hack, the current implementation, despite having a good amount of voodo magic in it, can be considered a quite clean solution.
As to having it in 3.1, it's not in 3.1.0, but it's possible it will be backported to some later 3.1.x version.
Hmm, ok, more precisely said, the linking itself is slow. No wonder, ld has to load the huge .o files created by gcc (huge because of all the debug info and things duplicated in every .o). For example all .o files here for libkdeui.so are together 45MiB (101 files), forming 21MiB large libkdeui.so. Creating the library needs almost 30s here (1Ghz Athlon, hdparm shows disk can do 40MiB/s). I don't know how about you, but I call that slow, regardless of what exactly is causing this.
> Get together with the Gnome geeks, combine the two and spend 1 year making it smaller and faster.
ONE year? Oh come on, you have absolutely no idea what you're talking about.
> and to hell with chasing the unuseable do everything file manager... rip the damned html and other readers fro mthe file managers... Cripes you guys, Nautilus and Kfm both suck horribly now... and it's dragging the wm down with it.
And here you don't know what you're talking about either. FIrst of all, KDE's filemanager is called Konqueror, since several years already. Second, the performance of a filemanager is hardly going to drag down the wm. And third, khtml and other readers are not integrated in Konqueror, so they can't be ripped off.
> what's next xmms is going to be increased in size by a factor of 10?
Why? You don't think it's already bloated enough for a thing that just plays music?
2a: You apparently never tried to compile a larger C++ project. GCC needs considerably more time to compile C++ code than C. In general, the GNU toolchain has worse support for C++ as compared to C (yes, C++ is more complicated than C, but I don't think it's _that_ much). Precompiled headers will hopefully help here.
2b:No wonder remaking kernel after changing one module is so fast. Usually nothing except the module itself depends on it, so nothing else needs to be rebuilt. But if somebody commits a change to some of the kdelibs header files, many files have to be rebuilt.
1a: Most people probably don't want even to patch and compile even their GCC. It's just one more thing to take care of.
1b: Moreover, GCC is not the only bottleneck. The linker (not ld.so, but ld, the one creating binaries) is pretty slow as well. Or you could try debugging some KDE app (with debug info compiled in) in GDB - THAT will teach you what 'slow' really means (and maybe you'll even suddenly find KDE's performance quite acceptable).
Is it really that difficult to select a different widgets style if you don't one?
> How does one go about to build a Windows Manager from scratch? Do I need to know C, C++, or one of the other library frameworks?
You need to know more. Developing a window manager isn't exactly the same level like 'Hello world' apps.
> But far less than Konqueror is built into KDE. ;) With Win, I can at least set the browser I want to use. I can't figure out how to make KDE apps use anything but Konq
:)
Just go to file associations config dialog, and for text/html move Konqueror down or Mozilla up in the preference order. Now press Alt+F2 and type 'kde.org'. Happy now?
There aren't any really (well, at least not more than in other pieces of code). Let's for example have a look at the table comparing gtkmm and Qt linked from the article (this one http://www.murrayc.com/murray/talks/2002/GUADEC3/s lides/html/img6.htm). For a guy who's supposed to know C++ so well his arguments have rather weak base ground, so he's either not that good, or he's just badmouthing Qt without knowing the things.
Moc extends C++: Oh yeah, telling this to people believing moc is a preprocessor can be hard, but moc extends C++ about as much as Doxygen. Moc is a code _generator_ (or call it precompiler), it's not needed to preprocess the sources, programs written in Qt are valid C++, otherwise one wouldn't be able to compile it with so many C++ compilers. What moc does is it analyzes headers files with few tags added, and for reasons like making it easily readable those tags are created using few #define macros. If TT wanted, they could be written in comments, just like for Doxygen, and it would be perfectly perfectly pure C++, yet there wouldn't be any real difference. In fact, it would be possible to write Qt code even without moc, but one would have to hand-write all the generated code, and that would probably get some people in madhouse.
Containers: Qt has to run on a number of quite old and crappy platforms (unfortunately, I'd be happy if TT dropped the support for them too). That's the real world. It's easy to limit a brand new library (which gtkmm2 is) to using things like that, but there are still C++ compilers in use that can't handle things like that. Some key design decision for Qt were made many years ago, and some (paying) developers wouldn't be happy if Qt completely changed every year. Moreover, Qt3.x has support for STL (I don't know how good though, I don't use it), and maybe Qt4.x will have its own containers only for backwards compatibility, and will prefer STL.
Namespaces: Qt is in a sort of namespace, and it should be sort of namespace clean (everything starting with Q). Since for KDE4 it's planned to have it completely namespace clean, including plugins, etc., Qt4 will be maybe in its own namespace too. Not that putting it in a real C++ namespace will make that much difference.
Memory management: One can delete widgets in Qt, and they will be automatically removed from the parent, who's otherwise responsible for the deleting (and getting used to this simplifies things). It's also not true you can't create Qt classes on stack, I do that sometimes when it fits. The truth is that it doesn't fit most of the time.
GNOME classes: Let's skip this one.
Widget containers: I don't know enough about the way it's done in gtkmm, so let's skip this one too. It's doesn't matter much anyway, I don't have any problems with separate layouts in Qt (in fact it may be easier to code the layouts that way, but that's just a guess).
Typesafe signal handlers: Well libsig++ has its problems too, like possibly increased compile time with already slow enough g++, and the compilers need to be very good at handling templates, which g++ wasn't not that long time ago. http://doc.trolltech.com/3.0/templates.html might be a good read in case you wonder why Qt still uses moc and not libsig++.
License: The table misses QPL and commercial licenses for Qt. TT developers also have to eat, and people need to be payed in order to e.g. write as good documentation as Qt's is (just compare it to gtkmm's). If you can't handle the fact somebody tries to make money and yet is so Open Source friendly, just shut up, ok? I can undestand some people prefer Gtk+ just because of LGPL, but that's no reason for TT bashing.
Development: There are at least two places where Qt is discussed, for the first one see mailing lists section on TT www site, the other place is KDE lists. For a commercial company, their handling of bugreports and suggestions is quite good. (Not to mention that those FSF fanatics screaming about Qt not being Free(tm) should actually love it - it's GPL'd, not LGPL'd and that's the one true RMS way, isn't it?)
I'm not saying Qt is a perfect thing. Nothing is. There are certainly things that could be better, some of them are there because of the wide platform support, backwards compatibility, some of them are there for other reasons. But there's no valid reason to call Qt bizzare or insane. It's one of the best toolkits in the world, and I mean it.
Passing --enable-final to configure (and no -j) helps even more.
Good example of how much much faster GCC will be once it finally gets precompiled headers.
Don't worry, GNOME has its army of trolls too. Last week in three discussion somebody said something like "it's easier to code for GNOME and it has much better technologies", yet after I asked "why and which ones", nobody answered anything specific (BTW, are you going to tell me?).
... for example having one file open dialog, instead of having one official that sucks and a couple of others in some apps where they try to make one that doesn't suck.
KDE has its share of trolls, GNOME has its share of trolls (including you and in the past even Miguel de Icaza himself), so what makes KDE worse?
Oh, and "integrated" of course means more than just using KParts
Boy, I think you desperately need a girlfriend. How about going to find one instead of wasting your time on such paranoid things?
You can of course complain to whoever you paid to for getting KDE.
> There were rumblings at one point, if I'm not mistaken, that OO.o may get ported to GTK2, which would be cool.
But there also were rumblings that porting OO to Gtk/Bonobo is just a good joke. Given the fact that OO is C++ and doesn't have anything in common with GNOME from the programmers point of view, by the time OO is ported to GTK/Bonobo, KOffice or GNOME Office will be most probably as good as OO.
> I'll agree that that stuff should not be on by default
...
It should be on by default, as the BFUs most needing this feature would have trouble finding out how to turn it on (if they knew there was something like that). More skilled people are expected to have no trouble finding out how to turn it off. Well, and then there are also idiots like this one
> I believe the original author was not including dependencies. Without those, Galeon is the smallest.
No. Without dependencies, Konqueror is the smallest (which also shows that not including dependencies doesn't make much sense).
> Yes, I do have specific complatins about the KDE UI and I have expressed them in various places, but they will never be addressed, because they apply to the general concept of KDE: Not making any decisions. Wether the menu bar is global or inside the application window should never be optional - this is a fundamental decision that should be made by the developers once for all. The same goes for button placements and the terminology used in programs.
I like the global menubar. It's faster than when the menubar is in the application window. However, there are many people who are used to the menubar in the application window. So what now, which one to drop? You won't get people to agree on this, not to mention that this specific feature is very cheap in resources. Different terminology is of course a problem, feel free to help fixing it. And I don't see any problem with button placement, what exactly is supposed to be wrong with it?
> If you write an application, you want to know what the user's system looks like. Does it use 3D or 2D icons? How does the system use bevels and mouseovers? Is there a per-window or a per-application menu?
Who gives a damn? It's not important for the application if the icons are 2D or 3D or where the menubar is.
> Where am I supposed to put OK and Cancel buttons in dialogs? What colors am I supposed to use for which meaning? Making all of this a user option makes it impossible for developers to write applications that fit into the user's system.
So if I take advantage of KDE libraries that take care of many such things, my application won't fit in the system? Interesting.
> For example: Neither KDevelop nor Opera are able to deal with a global menu bar. Opera retains a per-window menu bar and KDevelop places some dialogs behind the menu bar, making their title bars inaccessable. And if you want real fun, activate global menu bars and focus-follows-mouse in KDE.
I'd say KDevelop is simply broken in this respect (which can be fixed), and Opera doesn't support the global menubar because it's not a KDE application. And after trying focus-follows-mouse, I didn't have any fun, the only difference I noticed was a focus policy that I don't like.
> Now, if you really like KDE I suggest that somebody set up a web site, download all the KDE source and set some democratic voting system to decide what parts of KDE are junk.
Good luck. And don't be too disappointed to find out that the factors most reponsible for the memory usage are the size of the libraries and inefficient dynamic loader in glibc, for speed the flexibility, ease of development and consistency. So, what will be the part to remove first? There will be never again cool games fitting in 8KiB memory like Jet Pac 20 years ago, and comparing KDE with IceWM in certain aspects is comparing apples with oranges.
But otherwise, if somebody really wants to work on optimizing KDE, your patches are of course welcome.
Well, since I managed to write in KDE3 in languages like Czech (accented characters), Russian (cyrilics) and Hebrew (RTL), the problem with you being unable to write in Latvian is probably not a KDE problem. Do you have locale set properly? Do you have unicode fonts (like e.g. those ttf ones from MS)? Do you have the proper keyboard layout?
The only thing the article really says is that GNOME1 uses less memory than KDE3. Which is no wonder, KDE1 used less memory than KDE3 too. You should try GNOME2 - it's just as memory hungy as KDE3(both the environment itself and apps themselves - I bothered to check it, and yes, I tried to make the comparison fair).
In fact, unless GNOME2 will get some optimizations in this area, KDE3 will need less memory after prelink finally becomes available.
You, just like others, didn't get the (IMHO) ironic meaning of the post (reversing everything). At least guessing from the gtk file selector comment - I don't believe a sane person could like that poor excuse for a file selector.
KDE taking 95MiB? Either your build is pretty broken, or you're one of those many many people who think they know how to measure memory usage but don't (because probably nobody really does :-/ ).