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

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 17:56 UTC (Tue) by erwbgy (subscriber, #4104) [Link]

GNOME uses GTK as its toolkit, which is LGPL. KDE uses Qt as its toolkit, which is GPL. This means that corporate developers can write proprietary applications using GTK, while they would need to pay Trolltech for a license to write a similar proprietary application using QT. Hence the popularity of GNOME with "corporate types".

I don't like GNOME much myself, but I know a few non-idiots who do. Choice is good as long as they interoperate, which is getting better all the time.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 18:25 UTC (Tue) by cventers (subscriber, #31465) [Link]

You're right about the library licensing issue, and this caused me to
almost choose GNOME a little ways back (yes, even after Qt went GPL).

Today, though, I've spent over a year using KDE full time at home and
work, and I've watched the rapid progress this desktop has been making
with keen eyes.

And now, I think that KDE using Qt (even given the Trolltech
dual-license) is *brilliant*. Qt is simply best-in-class in terms of a
cross-platform networked desktop toolkit. It's quite fast (and getting
better), very flexible, very easy to use, well documented, well supported
and well maintained. KDE can leverage on this massively successful
toolkit to deliver a massively successful desktop.

Every dollar Trolltech spends on engineering benefits KDE as much as it
does Trolltech, and hence Trolltech's commercial success will benefit
KDE. KDE's commercial success will in turn benefit Trolltech, and indeed,
Trolltech has started hiring KDE developers to work full time on KDE.

As for the licensing issue being the basis of GNOME's popularity with
"corporate types", I think this is pure speculation, and quite possibly
wrong. Trolltech doesn't charge royalties on their licensing - they
charge per-developer, at a low enough rate to be rather insignificant to
any company that employs full-time developers. (Think about it - a
developer costs between 50 and 100+ thousand a year, plus money spent on
benefits / support services / etc, and you're adding, what do they charge
- $1500 a year?). I have some of my own speculation about why the
"corporate types" choose GNOME over KDE, but this is neither the time nor
the place, I think.

From my programmer's perspective: I've used both Qt and GTK, and while I
think the unstable C++ ABI is a nightmare kind of problem to deal with,
I'd still pick Qt any day of the week because it's far more mature,
capable and easy to use. The collective GNOME APIs are, well, muddy. Very
muddy.

And you're right about choice. We share that sentiment.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 18:49 UTC (Tue) by Lockjaw (subscriber, #4611) [Link]

When working at a small company I chose GTK (not GNOME) over Qt in part because of the licensing issues (the other parts being C++ and Glade). At a large company, I could see that $1500/year isn't so much, except then you have to ask permission to get the $1500, go through purchasing, etc. I wouldn't underestimate the advantage of not having to ask permission.

As far as GNOME goes - I stopped using it when metacity became the window manager and I saw all those "crack smoking" replies to requests for reasonable features. It sounds like not much has changed on that front.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 19:14 UTC (Tue) by cventers (subscriber, #31465) [Link]

Fair enough - GTK can be swallowed easily by an individual developer
without the authority of management. But for some project (or series of
projects) in, say, Linux desktop applications at even a tiny companty to
be at all successful, your revenue will probably have to exceed
$1500/year quite a bit. So what's $1500/a head/a year to you, especially
when it includes support? Not saying blow your money... not saying you
made the wrong decision. Just saying Qt isn't particularly expensive.

If you look at Trolltech's commercial customers, they include companies
like Adobe. I'm seriously hoping that their Qt license purchases go to
making portable Photoshop, etc. Because frankly, for large projects like
Photoshop, especially, Qt is more "commercial grade". And it's backed by
a company with money to lose in lawsuits, which companies like for
reasons of assurance. And they sell support. If Adobe were to port its
suite to Linux, it still wouldn't be open source, but it would be very
good news for the Linux desktop.

Forge ahead, Trolltech. Forge ahead full speed.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 23:15 UTC (Tue) by mepr (guest, #4819) [Link]

You have put your finger on maybe the most relevant reason why a corporate, closed project would choose gtk over qt, the issue of releasing software packages for public use. Using QT means every time the c++ libraries go through another abi incompatability, the packages relying on that abi have to be rebuilt and rereleased. So you have redhat, ubuntu, suse, debian as probably the 4 most popular linux desktop packages, and none of them guarantee abi compatibility amongst themselves at any time. I upgraded my ubuntu install to breezy, and now flash is half broke, where by half broke I mean any given flash app has a 50/50 chance of working. And macromedia is one of the more supportive companies, as far as client, desktop, consumer software.

Welcome to library dependency hell.

GNOME v. KDE, December 2005 edition

Posted Dec 16, 2005 1:10 UTC (Fri) by thedevil (guest, #32913) [Link]

cventers wrote:
If you look at Trolltech's commercial customers, they include companies
like Adobe.

Interestingly enough, though, Acrobat Reader 7.x is gtk. And in terms of
ui it seems to me better than any of the free PDF readers.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 21:26 UTC (Tue) by dhess (subscriber, #7827) [Link]

From my programmer's perspective: I've used both Qt and GTK, and while I think the unstable C++ ABI is a nightmare kind of problem to deal with, I'd still pick Qt any day of the week because it's far more mature, capable and easy to use. The collective GNOME APIs are, well, muddy. Very muddy.

One problem with Qt is that, instead of leveraging the C++ STL, it comes with its own STL-equivalent classes (QList, etc.). What a waste of effort! I could understand this choice 5 years ago when many popular C++ compilers still lacked ISO-compliant STL implementations, but now it's just a weight around the neck of Qt.

And don't even get me started on Qt's "moc" nonsense.

I agree with you that GTK+ has a bunch of terrible API, but that's what you get when you go too far with the "OO in C" model. How C programmers can tolerate functions with names like gtk_file_chooser_button_new_with_backend is beyond me.

On the other hand, gtkmm is a really nice C++ wrapper around the GTK+ APIs, and there's gnomemm for the GNOME side, too. Unlike Qt, they make extensive use of the STL, and they support the signal/slot model without the need for a pre-processing step ala moc.

GNOME v. KDE, December 2005 edition

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

Er... You know what? All that nonsense that you decry so forcibly was
started more than five years ago. Of course C++ standard string class
still isn't suitable for real-world use, and the moc is actually
incredibly handy. It's almost as if you wouldn't have to write your own
preprocessor to write the repetitive stuff for you.

GNOME v. KDE, December 2005 edition

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

Of course C++ standard string class still isn't suitable for real-world use

This turns out not to be the case.

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 9:28 UTC (Wed) by cloose (subscriber, #5066) [Link]

Oh, yeah. The Unicode support is so great in std::string, right??

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 20:19 UTC (Wed) by nix (subscriber, #2304) [Link]

std::string does not dictate representation. That's what traits classes are for. Traits classes for UTF-8, UCS-16, and so on would not be very difficult to write.

This has been true for longer than Qt has existed, I believe: certainly it was true for years before the standardization process was complete.

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 21:32 UTC (Wed) by cloose (subscriber, #5066) [Link]

std::string does not dictate representation. That's what traits classes are for. Traits classes for UTF-8, UCS-16, and so on would not be very difficult to write.

No, you also need codecvt<> facets to convert between different representations (UCS-4, UTF-8, etc). And that's were it gets ugly.

AFAIK even "the C++ standard loving" gtkmm created there own string class for UTF-8 (see Glib::ustring).

So I would say a) it's not as easy as you make sound and b) as a app developer i have better things to do and just use QString. ;)

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 10:04 UTC (Thu) by nix (subscriber, #2304) [Link]

<blockquote>
No, you also need codecvt<> facets to convert between different representations (UCS-4, UTF-8, etc). And that's were it gets ugly.
</blockquote>
Actually it's about ten lines of calling iconv. I've done it. It's not hard.

GNOME v. KDE, December 2005 edition

Posted Dec 22, 2005 8:20 UTC (Thu) by oever (guest, #987) [Link]

Actually it's about ten lines of calling iconv. I've done it. It's not hard.

That sounds interesting. I've been looking for a way to handle different encodings nicely with just the STL. Could you give me a pointer to an example?

GNOME v. KDE, December 2005 edition

Posted Dec 26, 2005 23:54 UTC (Mon) by Baylink (subscriber, #755) [Link]

Is that the same as "bullshit"?

:-)

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 23:39 UTC (Tue) by smitty_one_each (subscriber, #28989) [Link]

I think the best defense of Qt is that its roots predate the C++98 standard. Nevertheless, it's still non-standard, and loses appeal thereby.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 23:46 UTC (Tue) by dhess (subscriber, #7827) [Link]

I think the best defense of Qt is that its roots predate the C++98 standard. Nevertheless, it's still non-standard, and loses appeal thereby.

Right, like I said, it made sense before reasonable STL implementations were available, but now it's just a pain.

I was hoping that Qt 4 would deprecate some of the redundant classes, but that doesn't appear to be the case.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 23:43 UTC (Tue) by dhess (subscriber, #7827) [Link]

Of course C++ standard string class still isn't suitable for real-world use

Oh, come on, that's ridiculous.

and the moc is actually incredibly handy. It's almost as if you wouldn't have to write your own preprocessor to write the repetitive stuff for you.

A handy tool is great, except when I'm forced to use it. Then it's not so handy anymore; I'd call it a nuisance.

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 9:41 UTC (Wed) by cloose (subscriber, #5066) [Link]

Oh, come on, that's ridiculous.

Then please tell me where does std::string support Unicode? Where are the often needed features like toInt(), toFloat(), replace(), trimmed(), rightJustified(). Sure I can write all those functions myself, but I have better things to do.

A handy tool is great, except when I'm forced to use it. Then it's not so handy anymore; I'd call it a nuisance.

moc provides Qt Meta-Object System. This is much more than just signal/slots. It's also dynamic properties and introspection. Those things are very useful for scripting engines or GUI builders. Please see http://doc.trolltech.com/4.1/metaobjects.html.

Regarding STL:

There is nothing that prevents you from using STL instead of QTL in your Qt applications. Also you can even use the STL algorithm with the QTL containers.

But a few things make QTL containers easier to use. Please see http://doc.trolltech.com/4.1/containers.html for reference.

Bye, Christian

GNOME v. KDE, December 2005 edition

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

Then please tell me where does std::string support Unicode?

Believe it or not, there are many, many C++ apps which do not need to be internationalized. I work on a very large (10m+ lines of code) in-house C++ application for a medium-sized, privately-held U.S. corporation, and all that Unicode strings would do for our application is a) slow it down and b) increase its memory footprint.

Even for internationalized applications, std::string may be sufficient for storing, e.g., UTF-8 encodings, depending on what your application is doing with strings. nix alludes to this in his comment above. All you have to do is Google Groups for "unicode std::string", and you'll find several threads with postings from some very good C++ programmers debating the merits of using std::string for storing international strings. The consensus seems to be that as long as you're not trying to process the strings (e.g., find a substring), std::string may suffice. And depending on the implementation of your STL, std::wstring may be good enough for UCS-4 encodings with "real" string semantics.

By the way, in my original comment criticizing Qt's "QTL," I didn't mention QString as one of the offending classes. I think it's clear that for a toolkit like Qt or GTK+, you need a portable, convenient class for dealing with Unicode strings until the C++ ISO committee cleans up the internationalization mess. (Though I would prefer a strictly UTF-8 class, can't we all just switch to this particular encoding?) So I never actually complained about QString. I was objecting to boudewijn's comment that, "C++ standard string class still isn't suitable for real-world use," which is complete nonsense. Maybe it's unsuitable for a GUI toolkit -- *maybe*, I would still prefer a toolkit that's templated on string types so that I can choose the appropriate representation for my application, e.g., I don't need multi-byte strings and don't want to pay the cost of one -- but certainly not unsuitable across the board.

Where are the often needed features like toInt(), toFloat(), replace(), trimmed(), rightJustified()

For toInt and toFloat, please see boost::lexical_cast. Its approach is much better than adding methods to your string class, because a) it's extensible to any type I can dream of, not just the ones that the Qt designers felt were important and b) I can override the conversion if needed (e.g., say I want my toFloat() to accept "+inf", or maybe I want to throw when I encounter that). QString's to* methods are non-virtual, so I'm SOL if I don't like their implementation.

I don't know what the other methods do, Boost may have similar functionality, but in any case, lack of these methods hardly makes std::string unsuitable for "real-world use." Millions of real-world applications do just fine without them.

moc provides Qt Meta-Object System. This is much more than just signal/slots. It's also dynamic properties and introspection. Those things are very useful for scripting engines or GUI builders. Please see http://doc.trolltech.com/4.1/metaobjects.html.

You're not reading what I'm saying! I don't care if moc does my dishes and takes out the garbage. I object to the requirement that I use it for my Qt application, not its convenience! gtkmm requires no such thing and I can always use moc (or any other code generation system) with a gtkmm app for all the other "good things" it does, if I choose to do so. These things should be orthogonal, not intimately tied together as they are in Qt.

Regarding STL: There is nothing that prevents you from using STL instead of QTL in your Qt applications. Also you can even use the STL algorithm with the QTL containers. But a few things make QTL containers easier to use. Please see http://doc.trolltech.com/4.1/containers.html for reference.

As far as I can tell, what you say doesn't apply to the Qt widget classes, since they're not templated. For example, if I want a list of selected items in a QListWidget, I get back a QList of QListWidgetItem *. So I don't see how I can avoid using QTL in Qt. Please correct me if I'm wrong, I would love to hear about it because this is one of my main objections to using Qt.

p.s. ... which reminds me of one more thing I don't like about Qt. Passing around raw pointers is really inexcusable in modern C++ design. Passing around containers of raw pointers (ala QListWidget::selectedItems()) is even worse! Please give me reference-counted pointers, preferably boost::shared_ptr, though templating on pointer type is even better. gtkmm is slightly better than Qt in this regard, but still inconsistent (some methods return raw pointers and others do not, though maybe there's a rhyme to their reason).

GNOME v. KDE, December 2005 edition

Posted Dec 16, 2005 1:20 UTC (Fri) by thedevil (guest, #32913) [Link]

dhess wrote:
On the other hand, gtkmm is a really nice C++ wrapper around the GTK+ APIs, and there's gnomemm for the GNOME side, too. Unlike Qt, they make extensive use of the STL, and they support the signal/slot model without the need for a pre-processing step ala moc.

If you keep the runtime typing inherent in the signal/slot mechanism,
I don't see what the advantage of C++ is. If you read any of Stroustrup's
books you know that the whole point was to marry OO and static typing.

And signals/slots aren't even the worst instance of this in Gtk; that
distinction belongs to the horrible string-named properties. That's
back to Smalltalk, folks. When shall we ever learn?

There's a reason why pretty much any Gtk app, if run manually from
an xterm, will spew an ungodly amount of warnings.

GNOME v. KDE, December 2005 edition

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

I'm sorry, I'm having trouble understanding your comment. Are you talking about gtkmm, or GTK+? I was talking about gtkmm. It sounds like you're complaining about GTK+, which, as I said in my original comment, I don't like, either, so I think we see eye-to-eye on that one, at least.

GNOME v. KDE, December 2005 edition

Posted Dec 17, 2005 4:05 UTC (Sat) by thedevil (guest, #32913) [Link]

Sorry, I forgot that in a flamewar one's supposed to pick a side :-)

If I should summarize the sentiment behind my post (and that's the
important part, right?) it's approximately this: Gtk design is so wrong
that not even a C++ wrapper can save it.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 18:57 UTC (Tue) by hazelsct (subscriber, #3659) [Link]

Bzzzt! Wrong answer. Qt license costs are trivial compared to developer time, except perhaps in India or China.

The real issue is the annual -- and always "final" -- change of the C++ ABI which breaks every binary app linked to C++ libs. In contrast, one can write against the GNOME 2.0 ABI and be guaranteed nearly five years of stability. As long as this keeps up, corporate developers will continue to stay away from KDE, Qt, and all other projects whose infrastructure libs are written in C++.

Linux, the GNU toolchain, X, GTK, GNOME, all one big happy C family!

GNOME v. KDE, December 2005 edition

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

Parts of X, specifically Mesa, are written in C++.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 23:38 UTC (Tue) by airlied (subscriber, #9104) [Link]

libGLU is the only major C++ component in Mesa and it provides only a C ABI... so doesn't have any of these issues...

I think some shader code recently added might be in C++ but again no ABI...

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 7:23 UTC (Wed) by nix (subscriber, #2304) [Link]

Hm, true. I hadn't noticed that none of the C++ness gets exported. The ABI problems will still be present with respect to libstdc++ itself, unless libGLU is linked with -Bgroup, which is a) unsupported and b) doesn't seem to be the case. (A good thing too: linking libstdc++ to *anything* with -Bgroup gives me the willies.)

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 22:18 UTC (Tue) by jmorris42 (subscriber, #2203) [Link]

> 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.

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.

GNOME v. KDE, December 2005 edition

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

It seems unusual for Linus to get involved in a debate like this

Oh, no: he's mildly famous for popping up on mailing lists and emitting well-reasoned posts baked in high-temperature flame. He was doing it before the Linux kernel even existed.

His posts to the GCC list over the years have been memorable for a high heat to light ratio...

I entirely agree with your characterizations of KDE and GNOME; I avoided moving from GNOME 1 for as long as possible, then finally when it was too rotted to use I ate my dislike for moc and jumped to KDE, entirely because the permanently-active parts of GNOME 2, like the panel, couldn't come close to acting as I wished, or as they had acted in GNOME 1. I've never looked back.

GNOME v. KDE, December 2005 edition

Posted Dec 26, 2005 22:20 UTC (Mon) by Arker (guest, #14205) [Link]

'The classic KDE criticism' so far as I know is licensing. That issue was solved long ago. Currently the licensing for KDE is more free than for GNOME, in fact.

Gnome doesn't just leave me unmoved - it moved me all right. It moved me to the point I will never again use GTK for anything that I can possibly accomplish without it. I was, by the way, a very early Gnome adopter, until they decided they didn't want users like me anymore and started throwing every insult and injury they could come up with my way.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 18:27 UTC (Tue) by jdub (subscriber, #27) [Link]

A few things to note from the thread that answer some of the things you've raised in your post:

Functionality and options are different things.
All of the issues raised were explained, and the whole "confusing users" rationale debunked every time. That's not how we make design decisions at all.
Accessibility is one of GNOME's strengths, and we include screen reader, magnifier and sticky keys functionality in the GNOME Desktop release suite. Remember, we want to make GNOME "Just Work" for users with motor, visual and other disabilities too!
We tend not to talk about "majority" user segments, except when we speak of the "vocal minority" we work within and receive most of our feedback from: users who are highly technically proficient and care deeply about their computing experience. That's a very different class of user to, say, my doctor. He's a smart guy, but totally doesn't give a shit about computers. I want to make Free Software that works for him.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 18:57 UTC (Tue) by hmh (subscriber, #3838) [Link]

You said:

All of the issues raised were explained, and the whole "confusing users" rationale debunked every time. That's not how we make design decisions at all.

Why don't you place the so-called advanced functionality behind an Advanced button or in another dialog tab, then?

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 19:05 UTC (Tue) by jdub (subscriber, #27) [Link]

There are plenty of places in GNOME where options exist on separate tabs, dialogues and behind disclosure triangles. It is not as if GNOME has no preferences or options whatsoever.

(Functionality and options are different things, and "functionality" generally doesn't hide in the same kind of places options do...)

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 19:33 UTC (Tue) by cventers (subscriber, #31465) [Link]

You're right, but the critical swinging point here is the concept of
'plenty'. You see, you can make lots and lots of users happy (the 5-nines
you refer to elsewhere) by having an advanced desktop that has a
well-designed layering exposing more advanced functionality to more
advanced users as they drill down. The cost is that you will occasionally
get the layering wrong and make small minds be overwhelemed. Here we have
KDE.

The other option is to use the idea that you're designing for the
majority as a reason to not implement features or configurables at all.
You'll *please* a small number of users this way because you're going to
be lucky and get a good handful of them that find not a thing more than
they need. But these people would have been *happy* if you had more, as
long as you managed it wisely. Here we have GNOME.

And I know you've stated that you don't design for the "majority", but as
far as I can tell you're just saying that:

>> That's a very different class of user to, say, my doctor. He's a smart
>> guy, but totally doesn't give a shit about computers. I want to make
>> Free Software that works for him.

Is the "totally doesn't give a shit about computers" not the majority
crowd? What exactly do you call it if the word "majority" is banished?

WYSIAYG

Posted Dec 27, 2005 0:03 UTC (Tue) by Baylink (subscriber, #755) [Link]

The problem on point is referred to as What You See Is *All* You Get, and it's the traditional argument made against GUI's by command-line partisans, as well.

It *is* a problem, though, and the *real* problem that it is, is this:

Non-power-users *don't stay that way*.

People learn. And regardless whether your interface failed to scare them away when they were newbies, if they *can't get their work done* now that they're *not*, they're leaving, anyway.

So the "progressive complexity" partisans are the ones closest to right.

The as-yet unsolved problem is one corollary to "*why* is that menu item greyed out when I want to use it?" -- *how* do you let the user know that there are more powerful commands hidden from them that are pertinent to what they're doing?

Once someone comes up with a good, portable, intuitive solution to that which app writers can deploy without great pain, we'll really be going somewhere.

You heard it here first. ;-)

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 20:58 UTC (Tue) by mightyduck (subscriber, #23760) [Link]

But even for an experienced user it's sometimes nearly impossible to find
out how to change some very trivial things. For instance, the only
GNOME-like application I use at times is Firefox (I know it's GTK and not
GNOME but that all comes from the same stable to me). What drives me nuts
in Firefox are the freakin' wrong button order and the key bindings in
the location bar (every time I press CNTRL-U it wants to show me the
HTML-source). Now, after googling for quite some time I found that I have
to put the following stuff into my .gtkrc-2.0 file:

gtk-key-theme-name = "Emacs"
gtk-alternative-button-order = 1

I did that and you know what, it STILL doesn't work! I tried all kinds of
things with gconf-editor and whatnot in order to fix that broken stuff
but until now I couldn't figure out how to change it! The result is, I
stay away more and more from GTK- and GNOME-apps because it drives me
nuts. Now you can call me an oldtime UNIX user (the ones you apparently
don't care about and try to piss off as much as possible) but I still
have some influence and I really can't recommend something (even to your
doctor) which I'm not able to use myself.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 21:13 UTC (Tue) by cventers (subscriber, #31465) [Link]

While we're griping about GTK, can someone please tell me why every time
I hit + in GAIM or another GTK app, it renders as a tiny superscript plus
sign? Why do I always get these weird "binary character" graphics in the
course of normal IM conversations with a small amount of copy/paste? Why
does copying text out of a syntax-highlighting editor result in broken,
non-newline-terminated colourized text showing up in the GTK edit box I'm
pasting into?

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 0:51 UTC (Wed) by diakka (guest, #10310) [Link]

use gconf-editor and set /desktop/gnome/interface/gtk_key_theme to "Emacs".

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 17:35 UTC (Wed) by tjw.org (subscriber, #20716) [Link]

use gconf-editor and set /desktop/gnome/interface/gtk_key_theme to "Emacs".

Settings you make with gconf-editor will only be used if gnome-settings-daemon is running when you start firefox. If you don't use gnome-settings-daemon, you are correct in editing your ~/.gtkrc-2.0 file.

Note that ~/.gtkrc-2.0 is just silently ignored if gnome-settings-daemon is running.

There's also the possibility that you don't have the Emacs theme in /usr/share/themes/.

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 14:24 UTC (Thu) by mightyduck (subscriber, #23760) [Link]

I made the change with gconf-editor but it still didn't work at first.
Now I switched to KDE 3.5 and the gtk-key-theme suddenly works! I have no
idea why it decided to respect my settings now. The only thing which
started up together with firefox is gconfd-2. Maybe that's the
gnome-settings-daemon which makes it work? I don't know.

Anyway, thanks for all the hints, but my point is that it's extremely
complicated even for experienced users to change such simple things.
Maybe GNOME should provide an "idiot" and a "poweruser" mode if they
don't want to confuse their doctors. Then at least the ones who want to
tweak obscure settings and know what they're doing can switch to
"poweruser" and mess up their UI in whatever way THEY want. I still
believe the UI should adapt to the user and not the other way around.

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 14:25 UTC (Thu) by gallir (subscriber, #5735) [Link]

Oh my freaking God. Is that "usable", "simple", "it just works". I'm
still parsing what I should do to change key bindings in Firefox.

So, to be sure it reads my resource file I should first do some "ps -
kill -9" commands? No, I can't believe it.

BTW, I'm a vim user. What's the "emacs' style"? :-)

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 14:37 UTC (Thu) by mightyduck (subscriber, #23760) [Link]

BTW, I'm a vim user. What's the "emacs' style"? :-)

I'm a vi/vim user myself but I frequently use CNTRL-U in the shell in
order to clear the command line and I want to do the same in the firefox
location bar. But the default binding for CNTRL-U in firefox is "view the
HTML source" which drives me nuts if I hit it by accident. And, believe
me, I'm not the only one here, most of my coworkers complained about
that. Maybe it appeases the Windows crowd (which we don't have here
except for our secretaries and they're not used to keybindings at all,
they just point and click with the mouse) but it drives UNIX users
insane.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 21:43 UTC (Tue) by b7j0c (subscriber, #27559) [Link]

>> Why don't you place the so-called advanced functionality behind an Advanced button

yuck!

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 0:37 UTC (Thu) by dmarti (subscriber, #11625) [Link]

Please don't do "Advanced" tabs. If you're looking for a feature, you have to look twice, in the relevant tab and in "Advanced". It's like record stores that have a separate "Alternative" section. You have to look twice to see if they're out of something.

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 7:25 UTC (Thu) by AnswerGuy (subscriber, #1256) [Link]

Just have one option somewhere near the top that enables the "Advanced" (more options) throughout all configuration dialogs and widgets.

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 10:09 UTC (Thu) by nix (subscriber, #2304) [Link]

Apparently this `confuses the users', too. (Well, that's what I was told when they took it out of Nautilus, along with every feature of that program that I actually used it for.)

Perhaps the GNOME project should change the expansion of its acronym: with the near-demise of Bonobo the amount of `network object model' in there is minimal anyway. Given the GNOME attitude (`on crack' and dismissive contempt) to suggestions that perhaps not all features that the program's maintainer doesn't use are useless, I suggest the recursive acronym `GNOME Now for Obtuse Morons Exclusively'. It's not true, but at times it seems to be their goal :(

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 7:53 UTC (Thu) by komarek (subscriber, #7295) [Link]

And please, don't call it "Advanced". It's not advanced. Perhaps it is rarely used, or obscure. But emacs key bindings are not any more advanced then remapping ctrl-c (ascii ETX, which we all learned was used to abort a program) to "copy". The same thing goes for hundreds of other options that devs like Havoc Pennington don't like to expose.

-Paul Komarek

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 19:08 UTC (Tue) by cventers (subscriber, #31465) [Link]

Maybe you're right about some of these points having been addressed. If
it's not usability and not confusing users that you're after, than what
is it exactly?

One of the reasons KDE continues to be such a joy for me is because of
how many features are hiding right under the covers. I often discover
them by thinking at some random moment, "Wouldn't it be cool if I could
-- wow! They thought of that and implemented it! Way cool". In that
moment I've just discovered that I can detach tabs in Konqueror. Or get
Wiki feeds about my artists as I'm listening to music in amaroK. Or one
of hundreds of other things that makes my computing experience a joy and
doesn't get in my way.

Honestly - every time I use GNOME I just end up getting let down. I'll
admit that I put it on my teenage sister's laptop (she's not a computer
person)... but that was more because I had an old Ubuntu CD laying
around.

She loves Linux - likes it better than Windows (and has since expressed
interest in try KDE after seeing me use it). But little things just annoy
you. One in particular I remember - she nudged her Synaptics touchpad too
much and the GNOME top bar or whatever it's called ended up right-aligned
with HUGE quick-launch icons. I couldn't for the life of me figure out
anywhere on that panel to right-click in order to get to the screen I
needed to in order to get it re-aligned. In the end, I had to delete all
the quick-launch icons to make room to click through to the panel. This
exercise took me 10-15 minutes of frustration, and I'm a goddamned
programmer! All of my intuition about the ways to control the thing you
guys *might* have thought of were useless, whereas generally in KDE if I
have an intuition they might have implemented some random feature,
chances are I'm right and it's there, more powerful than I imagined.

I don't mean to just slam on GNOME, but once again, what's your goal? Why
is GNOME software often so much less desireable / powerful than KDE
counterparts? Why do my GNOME-using friends use Konqueror and K3B and
amaroK and Kaffeine, using GNOME for nothing more than the pretty window
decorations? I run one GTK app - GAIM. And occasionally when I go to send
someone a file, I get reminded of how much I hate some of your project's
decisions about the UI. The moment all the IM clients decide to support a
common encryption standard, GAIM will be leaving my desktop (unless GTK
apps magically start looking / working better by then).

Perhaps Linus (and myself) are totally wrong about GNOME devs being
motivated by "not confusing users". Why have you excluded all useful
functionality then?

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 19:17 UTC (Tue) by jdub (subscriber, #27) [Link]

What's our goal? To bring software freedom - and the deeper freedoms it defends - to the 99.999% of people around the world who don't care about computing technology quite as much as we do.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 19:23 UTC (Tue) by cventers (subscriber, #31465) [Link]

Mine too. Now in the process, can you guys make your GNOME desktop a
little more functional and powerful so that it doesn't feel like I'm
using an airport kiosk?

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 19:37 UTC (Tue) by jdub (subscriber, #27) [Link]

Perhaps some constructive feedback may actually get you where you want to go.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 20:05 UTC (Tue) by cventers (subscriber, #31465) [Link]

Well, my apologies for stepping over the line a bit with that last post.
The airport kiosk remark is just the best describing remark I've come up
with after tinkering with GNOME a few times in between spans on KDE over
the years. (IIRC, my earliest time spent running around on an actual
Linux *desktop* was Red Hat 5 or 6).

My biggest criticism (is this constructive?) of GNOME is that every app
and dialog feels like it was deliberately reduced from what it could have
been. In some cases, this is genius and the dialog is simple / elegant /
pretty. But way too often does it simply get in the way (Your file picker
is a *big* example - why won't it let me sort by file type and why isn't
it immediately evident that I can type a location?)

If GNOME stood alone on the desktop market, I think it would be a great
desktop. The fact is that it stands next to KDE, and even though I admire
your looks and in *some* places the simplicity, any time I spend any
length of time at all in GNOME I come away frustrated after X number of
important things appear to have been intentionally excluded. (X is
porportional to the amount of time I spend on GNOME)

GNOME v. KDE, December 2005 edition

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

I only learned about the `Ctrl-L to type' thing by following that mailing list thread. Affordances in GNOME are frequently absolutely *awful*, even in very widely-used common dialogs.

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 5:17 UTC (Wed) by zlynx (subscriber, #2285) [Link]

In my opinion, Gnome shouldn't even have a file picker. Saving a document should just ask for a name and drop it in a default location. After that you can put it somewhere different with Nautilus. Opening a document shouldn't even get a dialog: open it from Nautilus or drag and drop it.

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 11:45 UTC (Wed) by csamuel (subscriber, #2624) [Link]

Gah, do that and I'll give up helping the folks I know who use GNOME get
themselves out of trouble!

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 13:58 UTC (Wed) by mauvaisours (subscriber, #6130) [Link]

Have you learned about this useful little thing called "Folders" that helps you organize what you do ?

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 22:25 UTC (Thu) by emj (guest, #14307) [Link]

Well you are right in one sense, what should a user do in the root? You really should have everything in your home directory, perhaps in the "my Documents" folder. Or even better let people "tag" their files, and make it a database.

On bigger multiuser system it's even worse, have you ever tried to find the account of your friend John in the local /afs.. "Now was is /afs/fnord.se/homes/h/dk/sf/u2313n23? I can't really remmeber... "

GNOME v. KDE, December 2005 edition

Posted Dec 27, 2005 23:05 UTC (Tue) by quintesse (guest, #14569) [Link]

"why isn't it immediately evident that I can type a location?"

OMG!!! Do you know how many times I screamed at that stupid dialog because I thought I couldn't enter a location?

I positively hate hidden functionality and think all GUIs should be "discoverable" which means that you should be able to learn at least 99% of its functionality just by "looking around".

I find that most of the time for me Gnome either does not have the functionality I want or they have hidden it so well that even I as a very experienced user can't find it.

But it's not only Gnome, I love Firefox for example but I still miss some of the settings that you could find in the Mozilla preferences. I want a button "Trust me, I know what I'm doing" that show me all those option pages they removed! (And please, do NOT tell me about about:config!!)

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 23:16 UTC (Tue) by smoogen (subscriber, #97) [Link]

One of the big things I have to do for customers is to turn off the spatial perspective in nautilus. People hate having to close 15 windows as they went searching for something in their directory tree structure.. but every time I and others mention it.. its that we arent understanding what we should do.. Here is a sample of what multiple customers have complained about:

Well I am just wanting to open up a document that I filed away in the way that I wanted, but I when I have finished opening up
Desktop
Work Documents
Project XYZ
2005
Work Orders

I now have 4 windows I dont want to stay open and 2 that I do.. so I end up spending a lot of time closing stuff.

[And switching to 'classic' mode makes everything look like it is GNOME-0.8 and not as featured as the KDE desktop.]

I currently use GNOME, but I am coming this close to switching over to KDE even if it means being a third class citizen on Fedora.

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 6:55 UTC (Wed) by Mithrandir (subscriber, #3031) [Link]

Agreed. At least my default desktop distro (Ubuntu) has made that change for me. :)

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 8:25 UTC (Wed) by heini (subscriber, #33614) [Link]

One simple thing: You mentioned this doctor w/o computer knowledge.
Imagine it was a german doctor, who simply would like to see his desktop
in german language. I am a KDE user and when I start KDE the first time, a
configuration wizard pops up where the very first thing I can choose is
the language.

Now on to Gnome (or XFCE). Whenever a new version is released, I try it
out. I am not asked to choose my language. I spend 15 to 30 minutes to
find out how to change it to german (other than setting some ENV vars, I
know how to do that). I finally give up and stay with KDE, and so will the
german doctor, he doesn't know how to set ENV vars.

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 20:12 UTC (Wed) by Los__D (subscriber, #15263) [Link]

GDM, choose the language before you log in... Now that was hard, huh?

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 7:15 UTC (Thu) by heini (subscriber, #33614) [Link]

You really think this is a good idea, don't you?

No other display manager out there let's you choose the language,
because it's simply stupid to put it there.

1) This locks Gnome users to using GDM, but what if they have no
control over what display manager is used (because it's not their
machine)?
2) You have to re-login to change the language.
3) What if you don't use any display manager at all?

So this makes the situation even more worse, sorry.

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 9:48 UTC (Thu) by Los__D (subscriber, #15263) [Link]

1) I expected you wanted the whole package.
2) New user = new login... Or are we schizo here?
3) If you don't use a display manager, you'd mostly be a shell user (Or one of those strange people who login with the text console and do a startx as the only command there), and used to LC_LANG if you want another language.

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 10:33 UTC (Thu) by dvdeug (subscriber, #10998) [Link]

Changing the display manager is simply not possible for anyone using a multiuser system where the admin doesn't use Gnome. And it gets real tiring when every program expects that you're running the whole system; is it that unreasonable to try and choose the better program instead of the one from GNOME?

GNOME v. KDE, December 2005 edition

Posted Dec 16, 2005 17:47 UTC (Fri) by cortana (subscriber, #24596) [Link]

Surely you always have to re-login to change the language: a process may only alter its own environment, and anyway translated strings are usually loaded by an application at startup, and never altered.

I do agree that there should be some kind of regional settings option in the preferences menu that would allow one to change the value of LANG. LANGUAGE and the various LC_* variables that will be used the next time one logs in.

GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 20:26 UTC (Wed) by aigarius (subscriber, #7329) [Link]

I am a programmer, but I still want my desktop to "just work". I do not want to configure things - I have work to do. Maybe sometimes there is an option missing, but the time I spend configuring my desktop is tiny compared to time I spend working. If there are more options - I will spend more time on useless configuration just because I *have to* look through all the options.
I am all on Gnome about this one - if you want to work, just work and forget about configuring.

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 7:41 UTC (Thu) by pascal.martin (subscriber, #2995) [Link]

I am in a similar situation, except for a few things:
- Gnome removed some of the options I did setup. I felt cheated.
- Despite its "keep it simple" mantra, Gnome has become really heavy.
- Gnome has had a tendency to forget my config on upgrade (debian specific?)

As logon time kept increasing, the frustration of not being able to restore my config convinced me to switch to Xfce:
- Xfce is simple and has not much more options than Gnome,
- but it starts much faster and takes up less memory.
- It tends to loose the user's config less often (your mileage may vary).
- It still use GTK (I don't like C++, the language made complicated so to maximize memory leaks :-)

GNOME v. KDE, December 2005 edition

Posted Dec 15, 2005 15:23 UTC (Thu) by mightyduck (subscriber, #23760) [Link]

Oh, come on, this is just BS. Nobody forces you to look through all
available config options, you don't *have to*. I use KDE and I never scan
the whole control center and go through all the options. I have maybe a
handful of things I change on a new system (like "focus follows mouse"
for instance) and then I'm able to work. But if for some reason I decide
to tweak some option because my habit changed or I discovered a more
practical way of doing things I know the option is there and I can easily
find and change it.

GNOME v. KDE, December 2005 edition

Posted Dec 23, 2005 4:54 UTC (Fri) by obi (guest, #5784) [Link]

Maybe it's BS for you, but you seem to think that everyone thinks like you. I agree with the parent - seeing boatloads of options just irk me. And this visual annoyance happens every time I have to search for an option. And I always feel something is set up "wrong", but I don't know what (maybe I'm paranoid).

I'm a programmer too, and I do appreciate Gnome's "not-in-your-face"-ness. Yes, there is some functionality missing, but I'm willing to bet it's not by design, but simply because they didn't get round to it yet, or in the worst case that it's not really a high priority.

Every time I try KDE, I appreciate the polish and some great technology, but I just can't cope with the UI feel for a very long time. Considering how many pro-KDE comments there were, I can see not everyone feels the same way as me. It just goes to show that it's good there are choices, and I'd encourage all the desktop projects out there to continue finding their unique identity.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 20:43 UTC (Tue) by proski (subscriber, #104) [Link]

Where did you get that 99.999% number? Many people care about computing technology, they just care about different aspects of it. I think that the 99.999% myth is used as an excuse for lazy programming. You may be surprised how much a designer cares about color quality of the monitor or how much a helicopter pilot cares about real time properties of the flight control software.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 22:28 UTC (Tue) by elanthis (subscriber, #6227) [Link]

Those users don't care about either of those things.

They just care that the computer does what they need. The details of how it does it is irrelevant to them. They especially do not want to have to learn how to edit rc files or memorize patterns of double-click icon -> right-click interface -> select Options -> select Advanced tab -> click Computer button -> check checkbox -> click OK or so on.

The designer wants an efficient application for doing their work, and they want to be able to ensure colors are correct, preferably by using a likewise efficient and simple tool. They do not want to need 12 steps to do it, either.

The pilot likewise couldn't give a crap about how the software works. He just wants to know that it works. Whether it's well-written real-time software or a staving kid in a box with a chalkboard and an abacus is entirely unimportant, so long as the helicopter stays up in the air and goes where the pilot wants it to.

KDE = Joy

Posted Dec 13, 2005 20:18 UTC (Tue) by mgb (subscriber, #3226) [Link]

>One of the reasons KDE continues to be such a joy for me is because of
>how many features are hiding right under the covers.

Yesterday I had a problem with an application window that had content off the right side and resizing disabled. It took ten seconds of clicking to discover some KDE controls which allowed me to temporarily override the window size. Right click title bar - Advanced - Special Window Settings - Geometry. Exactly where any logical person would look for them.

And the Qt libraries are just as logical. GUI programming is easy and fun with Qt. GTK may be easier than Xlibs, but its nowhere near as productive as Qt.

We've started with the default Gnome in several distros but always become frustrated and switched to KDE. Now we always install Kubuntu - on our own systems and for our clients.

And yet: Long live Gnome! Competition helps both.

--Mike Bird

KDE = Joy

Posted Dec 13, 2005 22:06 UTC (Tue) by job (subscriber, #670) [Link]

For comparison, where does other window managers put that control? How would you go about doing the same thing in Gnome?

KDE = Joy

Posted Dec 14, 2005 6:00 UTC (Wed) by zblaxell (subscriber, #26385) [Link]

Historically I've reconfigured all the window managers I've used for more than a few hours such that they don't understand the "disallow resize" window hint to begin with. Sometimes the "reconfiguration" is done by editing the config files...you know the ones...every window manager has them...they typically come in a big tarball, and you edit the ones ending in ".c", then type "make" or something similar to update the WM config. ;_)

Hints that disable window controls seem kind of silly to me. Putting on my naive-user hat for a moment, I expect that if you can resize one window, you can resize any and all windows. Actually, before I actually used a Macintosh for the first time many years ago, I had read about user interfaces and I assumed that you'd be able to pretty much move, edit, and resize anything you like in any application while it was running. Needless to say, I've been disappointed with everything that has come since.

IMHO, applications that can't cope with window resize at all (e.g. those that behave in some anti-social or useless way when the WM blithely ignores the application and reconfigures its window anyway) should have some kind of default panning or scaling behavior imposed on them, preferably transparently so that the clueless application has no idea this is happening. The only reasonable excuse for disabling WM controls would be in an airport-kiosk type of situation--in which case it would make more sense to disable the controls globally in the window manager, so having the application WM hints makes no sense in that situation either.

KDE = Joy

Posted Dec 14, 2005 7:27 UTC (Wed) by nix (subscriber, #2304) [Link]

Every WM respects at least one hint to disable controls: the transience property. As long as you have to support that, why not make the control more configurable?

Hints

Posted Dec 14, 2005 14:19 UTC (Wed) by Ross (subscriber, #4065) [Link]

That hint doesn't really mean to do that, it just means the window is associated with another application window and that it is likely to be short-lived. In fact, some window managers don't disable controls on transients. Many do, but there is no requirement that they work that way.

Hints

Posted Dec 14, 2005 20:16 UTC (Wed) by nix (subscriber, #2304) [Link]

The vast majority that provide any decorations at all disable them on transients: in fact, given the common use of transients for things like pop-up help bubbles, any wm that didn't disable decorations on them would be unbearable to use.

Hints

Posted Dec 14, 2005 23:45 UTC (Wed) by zblaxell (subscriber, #26385) [Link]

Pop-up help bubbles (and menus and drag+drop handles and other weird window cases) usually use override_redirect, not wm_transient.

I don't see a reason why transients (even real transients like dialog boxes) should not be organized or decorated differently--in fact, I think that's usually a good idea. The thing I insist on is that I retain the ability to arbitrarily move, size, raise and lower them (including the often-denied privilege of restacking a dialog window behind its parent, and independently minimizing parents and transients), regardless of decoration or initial position.

I do see many cases where the transient windows *themselves* are often a bad idea, but that's application misdesign that a window manager can't fix.

I've used truly hintless window managers (ones that don't move the keyboard focus from parent to transient and place the transient randomly, so I have to aim at the appropriate window with the mouse cursor for every single transient) and hintful window managers (ones that respect all of the hints to the letter and even impose restrictions of their own). If these were the only choices (thankfully they're not) then I'd pick the hintless WM, because it's at least possible to sensibly arrange windows with the hintless WM, even if I have to do a lot of extra work manually.

KDE = Joy

Posted Dec 14, 2005 3:55 UTC (Wed) by njhurst (guest, #6022) [Link]

People often comment that QT is more productive than Gtk, yet the only big QT apps I use are scribus and qcad (and both rarely). On the other hand, we have the gimp, inkscape, abiword, gnumeric and gnucash; none of which have comparable QT versions. Maybe it is just the company I keep, but most of the top notch programmers I know prefer Gtk. Why is that do you think?

KDE = Joy

Posted Dec 14, 2005 15:05 UTC (Wed) by cloose (subscriber, #5066) [Link]

On the other hand, we have the gimp, inkscape, abiword, gnumeric and gnucash; none of which have comparable QT versions.

IMHO it the success of the corresponding KDE apps (krita, kword, kspread, kmymoney) that lowers the interest in writing Qt equivalents for those apps.

Maybe it is just the company I keep, but most of the top notch programmers I know prefer Gtk. Why is that do you think?

Maybe you're only looking for/attracting C programmers? I'm a C++/Java/Delphi programmer and I would never ever use a OO in C API.

KDE = Joy

Posted Dec 15, 2005 7:11 UTC (Thu) by njhurst (guest, #6022) [Link]

I had a look at koffice recently and though I was impressed by the progress, none of them are close to their gtk equivalents. kspread, for example, couldn't open a few computational excel spreadsheets I've collected over the years, yet gnumeric had no trouble. Karbon's renderer seems to generate wrong results regularly and couldn't open even some simple svg diagrams. The connector routing in kivio is crap compared to that of inkscape. Krita feels like gimp 1.4, though my wife prefers the oil paint effect in krita :)

Actually, it may be unfair, but the feeling I get from the koffice suite is that they are mainly playing catch up to their gtk counterparts and have just lifted chunks of code wholus-bolus (nothing wrong with this, but it makes me wonder what their aim is).

If you are a C++ programmer you should take a look at gtkmm. It is a lot more C++ than QT. Murray Cumming has done a much better job of understanding the C++ paradigm (ouch, did I just use that word..) than the Troll developers. And the people I'm talking about tend to program in more esoteric languages (they would say 'real languages') such as Haskell, ocaml and Mercury.

KDE = Joy

Posted Dec 15, 2005 8:25 UTC (Thu) by cloose (subscriber, #5066) [Link]

After looking at the following you will sure understand that I have a different opinion about gtkmm <-> Qt and KOffice. :)

http://cia.navi.cx/stats/author/cloose

KDE = Joy

Posted Dec 15, 2005 8:41 UTC (Thu) by njhurst (guest, #6022) [Link]

Sorry, I don't understand that comment - could you expand a little bit? As far as I can see you've just shown me a CVS log for some project I've never heard of...

KDE = Joy

Posted Dec 15, 2005 10:14 UTC (Thu) by nix (subscriber, #2304) [Link]

It's the (extremely nifty) KDE CVS interface program, with changes to kdebase scattered throughout as well.

So yes, I'd say it's not surprising he likes Qt and friends. :)

KDE = Joy

Posted Dec 15, 2005 11:07 UTC (Thu) by njhurst (guest, #6022) [Link]

Ah, so he's heavily biased, and I should discount his opinion... ;) Full disclosure: I work on inkscape, a gtkmm app :)

KDE = Joy

Posted Dec 16, 2005 3:27 UTC (Fri) by thedevil (guest, #32913) [Link]

njhurst wrote:
If you are a C++ programmer you should take a look at gtkmm. It is a lot more C++ than QT. Murray Cumming has done a much better job of understanding the C++ paradigm (ouch, did I just use that word..) than the Troll developers. And the people I'm talking about tend to program in more esoteric languages (they would say 'real languages') such as Haskell, ocaml and Mercury.

Your sense is not clear here. (Who are the "people I'm talking about", Qt people or Gtk?) Can you please explain?

From my post way above you'll see that I quite disagree with you, but
until you clarify I won't repeat that again :-)

KDE = Joy

Posted Dec 16, 2005 4:36 UTC (Fri) by njhurst (guest, #6022) [Link]

I said 'good programmer', cloose seemed to think I meant C++ instead of C or something, I said Haskell etc.

KDE = Joy

Posted Dec 17, 2005 4:18 UTC (Sat) by thedevil (guest, #32913) [Link]

Ok, now I see, you referred to a post up the thread. Here's where the
disadvantage of a web forum over a newsgroup or mailing list shows ...

I think the preference of Real Language people for gtk is very simple -
there are, by historical accident (or is there another tangible reason?)
bindings for Gtk in those languages, while there aren't any for Qt.

One aspect of Qt is annoying - its dependence on database libraries.
I don't know if that played any role in making Gtk bindings preferred.

KDE = Joy

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

There are indeed a lot of good GTK apps.

But please let me know when GnuCash has finally left the stone age of GTK
1.4, then I might be able to stomach using it. ;)

Regards,
- Michael Pyne

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 22:04 UTC (Tue) by job (subscriber, #670) [Link]

On the subject of Gaim, have you tried Kopete from KDE 3.5 yet? It has all sorts of nifty features such as webcam support, and the integration with kaddressbook was what finally made me switch.

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 18:35 UTC (Tue) by GreyWizard (subscriber, #1026) [Link]

99% of the current Linux desktop market probably doesn't have damn bit of need for a screen reader / magnifier / sticky keys.

This argument is weak. There is a difference between features a minority of users desire, which the things Gnome doesn't do might be, and essential features which a minority of users simply can't do without. You can use a co