Linked by Thom Holwerda on Mon 30th Mar 2009 18:43 UTC, submitted by elsewhere
Talk, Rumors, X Versus Y Any discussion about GNOME vs. KDE is sure to end in tears. It's basically impossible to discuss which of these two Free desktop environments is better than the other, mostly because they cater to different types of people, with different needs and expectatotions. As such, Bruce Byfield decided to look at the two platforms from a different perspective: if we consider their developmental processes, which of the two is most likely to be more successful in the coming years?
Thread beginning with comment 355924
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: kde vs gnome, qt vs gtk
by KAMiKAZOW on Tue 31st Mar 2009 01:22 UTC in reply to "kde vs gnome, qt vs gtk"
KAMiKAZOW
Member since:
2005-07-06

KDE applications seem to be designed to only be running on a KDE desktop. Starting any KDE application usually takes forever on my machine, because of all the KDE libs that are being loaded.

Well, that is done on purpose... not to annoy you, but the tight integration within the KDE eco system. KDE takes a bit longer to start than GNOME and according to an article that I've read a few weeks ago it also uses more RAM initially.
A result of that is that many KDE applications load quite fast -- much of the needed stuff is already in memory. There are a few exceptions (KOrganizer takes forever to load), but overall it's true.

Reply Parent Score: 2

RE[2]: kde vs gnome, qt vs gtk
by cycoj on Tue 31st Mar 2009 03:02 in reply to "RE: kde vs gnome, qt vs gtk"
cycoj Member since:
2007-11-04

"KDE applications seem to be designed to only be running on a KDE desktop. Starting any KDE application usually takes forever on my machine, because of all the KDE libs that are being loaded.

Well, that is done on purpose... not to annoy you, but the tight integration within the KDE eco system. KDE takes a bit longer to start than GNOME and according to an article that I've read a few weeks ago it also uses more RAM initially.
A result of that is that many KDE applications load quite fast -- much of the needed stuff is already in memory. There are a few exceptions (KOrganizer takes forever to load), but overall it's true.
"

Well that design decision tells me that my impression is right, KDE applications are made only for the KDE desktop. That makes the applications really unsuitable for any non-KDE environment. I don't want to 10s longer for digikam to start because it loads the KDE components just by Amorak, just because I might use it. I think it's a stupid design decision as well, it limits the scope of KDE apps, and the same job is better done by something like the preload daemon.

J

Reply Parent Score: 0

Dasher42 Member since:
2007-04-05

I actually agree with both of you but would say that the KDE approach is the right way. If you're going to load all the applications you need for your workflow, you're better off the more libraries they share. It also helps them be more consistent for UI and functionality.

This harks back to the silly obsession with boot times. Boot time is much more easily skipped by the user in favor of other activity; don't you want a more snappy environment and coherent design after it's loaded? It's like buying bulk when you know you're going to use all the goods. For my kind of desktop usage, that makes good sense.

Reply Parent Score: 3

KAMiKAZOW Member since:
2005-07-06

KDE applications are made only for the KDE desktop. That makes the applications really unsuitable for any non-KDE environment.

That's not true. Even when I use GNOME or anything else, I still use Kopete and Kontact and it works really well.

I don't want to 10s longer for digikam to start because it loads the KDE components just by Amorak, just because I might use it.

You make it sould like Amarok loads lots of exotic stuff not useful for anything else. Which KDE components used by Amarok are not used by digiKam? Both surely use the directory browser. Both have tool bars. Both have configurable keyboard shortcuts. Both support tagging of files. The list goes on.
That doesn't mean that digiKam loads everything used by Amarok or vice versa. Amarok doesn't load the KiPi plugins for lots of image formats and digiKam doesn't load Amarok's MySQL Emedded database.

I think it's a stupid design decision as well, it limits the scope of KDE apps

It's not stupid. This approach reduces the overall memory foot print.
BTW, real GNOME apps work more or less the same. For example I use GNOME's NetworkManager applet, because the KDE one was not mature when I set up my laptop and now all WLAN passwords are already saved in GNOME's Keyring and I'm too lazy to re-enter them in the now-mature KDE Network Management plasmoid.
nm-applet alone takes roughly 30-60 seconds to start (subjective, I didn't benchmark), because it's the first GNOME app I launch after log-in.

the same job is better done by something like the preload daemon.

Whaat? A stupid preload daemon is a better design decision?
If you want that make your own preload "daemon": Run any background KDE program in autostart.Yakuake (a terminal instpired by command consoles found in games like Quake), Kopete (IMO the best X11 instant messenger and the 2nd best IM overall after Adium for Mac), Amarok (music player), and KMail/Kontact (e-mail/PIM).

Reply Parent Score: 4

boudewijn Member since:
2006-03-05

You wrote "just by Amarok", but I think you meant to wrote "used by Amarok" -- otherwise your sentence doesn't make much sense, grammatically. And, of course, even with that emendation, it doesn't make much sense: Digikam loads only the kde components it needs, nothing else. If you start Amarok after Digikam, the extra components Amarok needs are loaded. KDE's libraries are pretty modular these days.

It's the same with any big application that doesn't try to reinvent everything itself, like Evolution, which used to have code to convert between rgb and hsv so it could draw shadows on buttons, or Mozilla, which had, last time I checked, its own math library implementation, or OpenOffice with its own component and widget framework. Though I don't think those apps are shining examples of starting in under 10 seconds...

Reply Parent Score: 6