GNOME v. KDE, December 2005 edition [LWN.net]

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 22:18 UTC (Tue) by jmorris42 (subscriber, #2203)
In reply to: GNOME v. KDE, December 2005 edition by erwbgy
Parent article: GNOME v. KDE, December 2005 edition

> GNOME uses GTK as its toolkit, which is LGPL. KDE uses Qt as its
> toolkit, which is GPL.

The license issue is important, but equally important is the language divide. GTK is C, Qt is C++. C can be wrapped in OO clothing well enough that it seems to be able to make everyone happy, language wise. Imagine a C++ horror like Qt running on a palmtop. Say the new Nokia gadget with only 64M of ram.

Note that GNOME seems to have found a way to negate this underlying advantage however.... needing 7.5M of resident set for a battery status applet is simply obscene.

Seriously, I'd like to see a KDE like desktop environment built on GTK2. The combination would be solid, scalable and free of license problems. Of course it would still be the wrong solution to my problem.

KDE is obsessed with recreating the popular but defective look and feel of Windows and gushing about Qt so much they were willing to ignore the fact it was proprietary software for most of KDE's life. GNOME appears obsessed with creating an environment as sterile and boring as a Mac while trying to import all of the defective plumbing found in Windows (binary registries, C#, .Net, etc.)

Both of which have a place in the evangelistic mission and all that, but what about once they get here? What are we offering? Have we lost our confidence in The Unix Way? Do we still believe we have a better philosophy of how things Should Be?

I want a graphical environment for UNIX that doesn't feels like it is a port. Something that is simple, elegant well designed and feels like it belongs in UNIX.

(Log in to post comments)

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 22:49 UTC (Tue) by boudewijn (subscriber, #14185) [Link]

That endless repetition of the old, hoary chestnut of "c is easy to wrap,
c++ is not" is so bloody annoying by now. It is NOT TRUE. AT ALL. Look at
the tremendous usability and functionality of PyQt. The Ruby bindings,
the Java bindings, the C# bindings, the C bindings, the Objective C
bindings, the Perl bindings, the Javascript bindings -- they have all
been usable and functional. PyQt, the Ruby, Java, C# and Javascript
bindings are alive and kicking. The ONLY reason the rest of them is no
longer maintained is that no-one wanted to use them. They were not
needed. C++ is, after all, and certainly in conjunction with Qt, a
satisfactory high-level programming language for people interested in
results, not in purity-posturing.

So, one more time: Qt bindings exist, are complete, are usable, are used
a lot.

(And as an aside, about palmtops and so on: ever heard of QTopia?)

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 23:31 UTC (Tue) by nix (subscriber, #2304) [Link]

It doesn't need to look like Windows either. Mine looks totally different thanks to the Dark Blue colour scheme and Keramik widget style. (I think the colour change does most to change the look of it.)

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 1:54 UTC (Wed) by daniel (subscriber, #3181) [Link]

Imagine a C++ horror like Qt running on a palmtop. Say the new Nokia gadget with only 64M of ram.

Perhaps you have not heard of qtopia.

KDE and GTK2 are the best

Posted Dec 14, 2005 6:14 UTC (Wed) by astrand (subscriber, #4908) [Link]

>Seriously, I'd like to see a KDE like desktop environment built on GTK2. The >combination would be solid, scalable and free of license problems.

Agree! GTK2 is the best toolkit[*], but KDE is the best desktop environment.

[*]: There are some really bad parts, like the file chooser, but that can easily be fixed.

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 23:29 UTC (Thu) by pynm0001 (subscriber, #18379) [Link]

> C can be wrapped in OO clothing well enough that it seems to be able to
> make everyone happy, language wise.

No it can't. :)

My first GUI programming experience was using the C-based Win32 API (no
MFC or anything, just the pure C calls).

When I transited to Linux, I wanted to be able to take that experience
over, so I started to learn GTK+. I simply couldn't grok it. The OO
layer they use there is wrapped behind lots of things the programmer has
to do, such as naming conventions, remembering to declare things in your
struct that counts as a subclass in the right order, and using (and
defining) macros EVERYWHERE in order to break C's typing system so that
you can simulate OO.

It sucked. So, I took the jump and started to learn Qt. I was vaguely
aware of C++ and how it worked from trying (and failing) to learn
Microsoft's MFC and Borland's Object Windows Library (OWL).

Luckily the Qt API and programmer documentation were simply excellent.
It was hard at first but once I got C++ down Qt itself was pretty easy.

Or to make a long story short, not everyone is content with the
monstrosity that is OO in C. ;)

> Imagine a C++ horror like Qt running on a palmtop.

Others have already mentioned Qtopia, but I wanted to point out why it is
that C++ software on portables can actually work. C++ isn't actually a
"bloated" language. Indeed, many of the frustrating things about it stem
from the requirements its designers impose on it that the code doesn't
pay for features it doesn't actually use.

In fact, well-designed C++ code can usually outperform equivalent C code
because the C++ language provides more information for the optimizer.
One program with C++ is the vast number of symbols generated, but most
are not actually required, and there is ongoing work in place to make
linking and loading C++ libraries suck less on Linux (Ever notice that it
doesn't suck on Windows? ;)

> KDE is obsessed with recreating the popular but defective look and feel
> of Windows

No we aren't. The default KDE combines elements from most major DEs.
I'll agree it looks most like Windows but there is nothing stopping you
from using e.g. Mac OS-style menus or the UNIX-traditional
focus-follows-mouse. You can even change the standard key bindings (and
KPersonalizer does this for you on the first startup).

I thing I want to know is why it is a crime if a GUI system allows their
user to emulate the feel of Windows... I know if I spent 10 years
learning keyboard shortcuts I wouldn't want to have to re-learn different
ones to switch.

> and gushing about Qt so much they were willing to ignore the fact it
> was proprietary software for most of KDE's life.

No it wasn't. KDE was started in 1996, making it almost 10 years old. Qt
has been Open Source since 1998, and was dual-licensed with GPL since
Sept. 2000. So it was only proprietary for 2 out of 9 years of KDE's
existence.

As far as The Unix Way, I feel that's what we're striving for with KDE.
Think of Konqueror as the shell and KParts as the I/O pipes. ;)

But let me tell you, this kind of stuff is hard. :(

Regards,
- Michael Pyne

GNOME v. KDE, December 2005 edition

Posted Dec 16, 2005 22:42 UTC (Fri) by dhess (subscriber, #7827) [Link]

One program with C++ is the vast number of symbols generated, but most are not actually required, and there is ongoing work in place to make linking and loading C++ libraries suck less on Linux

Are you talking about gcc 4.0's support for symbol exports? Or is there more to it? In the case of my employer's large C++ app, gcc 4.0's symbol exporting doesn't help us much because we throw exceptions, and as far as I can tell, that means we need to export any symbols across which exceptions can be thrown (which is practically... well, everything). So if there's some other efforts going on in this area that are unrelated to gcc, I'd love to hear about it.

(Ever notice that it doesn't suck on Windows? ;)

Are you talking about the fact that you don't have C++ DLL ABI issues on Windows? I thought that had more to do with the fact that every modern Windows app ships with all of the DLLs that it links against and effectively does the equivalent of GNU's LD_LIBRARY_PATH trick for each application, than any magic in Windows's runtime linker or MSVC++. In other words, Windows doesn't have any "system" C++ libraries, as far as I'm aware.

But maybe you're talking about something else.

GNOME v. KDE, December 2005 edition

Posted Dec 18, 2005 2:25 UTC (Sun) by pynm0001 (subscriber, #18379) [Link]

> Are you talking about gcc 4.0's support for symbol exports?

That's a part of it. The feature is called visibility. I regret to say
that it is still only 90% baked, as it's hard to use visibility correctly
in certain times when using C++ libraries that don't support it. For
example, using it with Qt 3 brings issues of its own for KDE 3.5. And
the STL implementation in gcc 4.0.x is buggy when using the pooled
allocator and visibility.

However, for the most part it is a great advancement, and when code is
updated to use it properly can substantially reduce the symbol count of a
C++ program or library, which greatly reduces linking time.

Another benefit of visibility is that it seems to make more optimizations
potentially possible. I forget the exact explanation though.

You can read about visibility here:
http://www.nedprod.com/programs/gccvisibility.html

> In the case of my employer's large C++ app, gcc 4.0's symbol exporting
> doesn't help us much because we throw exceptions, and as far as I can
> tell, that means we need to export any symbols across which exceptions
> can be thrown

AFAICT that isn't the case. You do need to export with default
visibility the definition of the class which you are throwing. I'd need
to ask around before saying that what you describe is definitely untrue
but I've never heard anything like that.

One other thing I want to describe is the prelink tool, which as it may
imply, will perform much of the work of the dynamic linker, and cache the
result, which will result in much less work loading the binary later.
It's useful all-around, but especially useful for C++ binaries.

This is what I was talking about with Windows, where for some reason
their C++ ABI seems to not suffer as much loading times as the ELF/Linux
ABI. But then again, I've heard of some useful C++ constructs which we
actually use in KDE that break with the Win32 mechanism.

Regards,
- Michael Pyne

GNOME v. KDE, December 2005 edition

Posted Dec 19, 2005 10:16 UTC (Mon) by dhess (subscriber, #7827) [Link]

AFAICT that isn't the case. You do need to export with default visibility the definition of the class which you are throwing. I'd need to ask around before saying that what you describe is definitely untrue but I've never heard anything like that.

Yes, you're right. I went back and re-read the wiki entry on visibility, and you only need to export the exception class. Thanks for clarifying.