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

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 23:29 UTC (Thu) by pynm0001 (subscriber, #18379)
In reply to: GNOME v. KDE, December 2005 edition by jmorris42
Parent article: GNOME v. KDE, December 2005 edition

> C can be wrapped in OO clothing > 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 > 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 > 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 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

(Log in

GNOME v. KDE, December 2005 edition well enough that it seems to be able to

the popular but defective look and feel

were willing to ignore the fact it

KDE's

to post comments)

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.