KDE vs GNOME

[Remco]

The tradeoff being an extra compilation cycle that has no specification or measure of thorough testing and it only targets GObject. I guess that is pretty...erm, innovative.

Well, if it's not useful, it will not be used and die out. If it is useful, the language will mature. I'm betting on the latter. Vala only targets GObject. That's true. It also only targets developers. Very true. It does not target broccoli; that would be crazy. Who cares about these details? Vala's internal type management is specified and portable. That's a good thing.

As far as "it's not like its all that different from MOC" goes...it is, actually, for the same reasons I'm railing about Vala being dangerous. MOC's development was sponsored by a company that hired real engineers to work together in a team to design a sane way to use C++ with a real specification, and QA requirements. MOC still had and has bugs, but it has also far more than the word of a scant few people saying "this seems to work."

What is a "real engineer"?

Since MOC is a critical part of Qt, it better work correctly indeed. Vala is not critical. It is a young language that is tangential to any other project. As it matures and gains ground, it will receive more intricate project management. For now, don't use it in nuclear power plants please.

You say I lay words in your mouth with "Do you think any other programming language than C is wrong?", but later you say that bindings for 3 programming languages is too much. I miss the point, indeed. You seem to long for the waterfall development model.

[Wyatt]

Well, if it's not useful, it will not be used and die out. If it is useful, the language will mature. I'm betting on the latter. Vala only targets GObject. That's true. It also only targets developers. Very true. It does not target broccoli; that would be crazy. Who cares about these details? Vala's internal type management is specified and portable. That's a good thing.

People that aren't interested in basing initial design decisions on hear-say from fanatics of the latest fad language care, as it happens. I should like to see an actual specification for Vala; where is it and who maintains it? Is it clear and well written? Are there errata? How fast is it changing? What's their version migration strategy?

...you say that bindings for 3 programming languages is too much. I miss the point, indeed. You seem to long for the waterfall development model.

And there you go, again, focusing on a technicality so you can conveniently ignore my point. I admit the wording of that was a little dodgy, but I let it slide because I figured it was pretty obvious what was important to take away from it all. How directly do I have to state that consistency and sanity are the point before it's clear? Using the right tool for the job must balance with not having a tool exclusively for removing exactly six nose hairs from an upside-down eel on noon of Thursday. It must balance with not suddenly shifting convention simply because a randomly large group of people decided it seemed like a good idea. It must draw the line between, "Okay, we support C++ and Python, and as a special feature, you can write this subset of plugins in Javascript." and "You can write any app in any language and we'll support it all, even if it means we cram Java, Python, Lua, Mono, PHP, Befunge, LOLCODE, Intercal, and Ruby down their throats simultaneously just so they can run their desktop."

How is supporting seven languages in a single project sane? What does it gain? What advantages does it confer? And most importantly, do those advantages outweigh the disadvantages? Design sanity doesn't preclude multiple languages, but frankly, the amount of language creep going on lately is just ridiculous. If you've already established that you're using Python for scripting, why would you suddenly start saying, "Let's support Ruby and PHP, too!" To say nothing of trying to just support everything. Yes, I'm talking directly to KDE, here.

In fact, I'm not even targeting Gnome in particular here (though they seem to have thoughtlessly started this trend). Just because KDE has better UI design and application consistency doesn't mean I think they're doing everything right (though at least most of KDE actually is consistently C++ and PyQt).

This is why I see Vala as pointless and poisonous. It's a boutique language that no one will use because its role is already adequately filled by other languages. In the mean time it will draw away developer resources that Gnome itself so desperately needs.

Is that more clear?

[Remco]

People that aren't interested in basing initial design decisions on hear-say from fanatics of the latest fad language care, as it happens. I should like to see an actual specification for Vala; where is it and who maintains it? Is it clear and well written? Are there errata? How fast is it changing? What's their version migration strategy?

With this argument, any new language cannot be used at all. Of course you're not going to do big enterprise projects in Vala in these early stages of development. Let's step back to what I originally wrote: "Maybe not if Vala becomes popular in the Gnome crowd. I kind of like it, and it seems to be gaining ground."

That does not mean that Gnome will switch to use Vala for major parts of the DE. It just means that people see the merit of this language and that it will become popular in the future. You know, when it has matured.

[snip]
Is that more clear?

That's more clear. But I don't agree. It's probably a good idea to limit the language of framework libraries to one. It's good for compatibility and portability, and it eases refactoring. This already happens. The framework libraries of GNOME will always remain C + GObject (see how Vala will be of use here?), and those of KDE will always be C++ + Qt.

The applications will be written in just about any language imaginable. There is no point in making rules about which language to support and which to reject. Open source very much works like evolution. Either there are enough developers developing in a certain language to create and maintain an application, or there aren't. If there aren't, the application will die. If there are, the application will survive.

Of course, if you want to use apps that need Java, Mono, Python, Perl, Qt, Glib, Bash, you're going to have some overhead. If you care about that, don't use those apps. But nobody cares. Ubuntu already comes with all these environments, and it still fits on one cd.

[RealNC]

Of course, if you want to use apps that need Java, Mono, Python, Perl, Qt, Glib, Bash, you're going to have some overhead.

Why didn't you put Gtk in the list?

[Remco]

I put Glib in the list, as that's more of an application framework than Gtk. Basically, GNOME's stuff is all split into small libraries.

[energyman]

and a lot of these libs duplicate functionality and code. Result: bloat. Mainanace problems.

[pingufunkybeat]

Unfortunately, this has turned into a flamefest already.

I use KDE, and I first started using it (KDE 1.1.2) on Redhat 5 in 1999.

What I've always liked about KDE is that they know exactly what they want to achieve. The results are not always perfect, but the goal has always been clear: Create a programming framework and a desktop environment based on this framework, which offers a consistent experience and the ability to accomplish everyday tasks.

With GNOME, I still don't know what their goal is after all the years. First, it was killing KDE, because Qt wasn't Free Software. Then Qt was re-licensed under the QPL which is a Free license, but not compatible with GPL, so KDE had to die. Then Qt was GPL'ed, but this was too free, so KDE had to die. Now that Qt is QPLed, GPLed AND LGPLed, there is no reason to kill it, so we have to look at the GNOME vision based on its own merit.

And I don't know what it is. I don't see many programs using the GNOME libraries. There is no component model to my knowledge (is Bonobo still alive? Has anybody ever used that for anything?), the new desktop-spanning inter-process communication is basically an update of KDE's dcop, there is the unclear relationship to Mono (a Microsoft standard), and a trail of failed startups (like Eazel) with lots of hype behind them and very little in terms of usable software (Nautilus took years to make usable). The standard GNOME experience today is a non-GNOME window manager, a GNOME panel, a GNOME mailer, a non-GNOME browser, a non-GNOME office suite, a non-GNOME music player, a non-GNOME burning program, a non-GNOME IM program, the non-GNOME image editor, the non-GNOME image viewer, etc. The only thing these programs have in common is that they aren't based on Qt or KDE, but most of them have nothing to do with GNOME, other than using GTK.

This is not bad per se - a minimal environment combining the best of independent tools specialising at different stuff, in the old UNIX tradition. The only problem is the XFCE does all that equally well, and is far more lightweight.

So I still don't understand the goal of GNOME. At one side, there is a complete desktop that has just been rewritten from scratch to make use of the latest technologies and GNOME will fall further and further behind if they don't undertake a similar rewrite, IMHO. On the other side, XFCE has caught up in functionality and caters well to the crowd who want a small GTK-based desktop for running 3rd party apps (like Firefox and OOo).

Overall I'm extremely happy with the KDE experience, especially since KDE 4.2. That's the first time where I've felt that a *nix desktop experience had surpassed the main commercial competitors not only in power, but also in polish. It is truly a 21st century desktop, and it's only the beginning, IMHO. It gives me the old KDE feeling of being in control, supports me with insanely cool stuff like ioslaves and web shortcuts, and at the same time it feels modern and polished.

I don't mean to bash the GNOME devs, as they have written some great software, and the competition with KDE has helped both desktops. The integration work between the two (like hal and dbus and compatible icon themes) have surely benefitted everyone. But I don't really see the decisive reason to use it now.

[Remco]

According to you, the goal of KDE is to create a development environment, and a desktop environment based on that, to accomplish everyday tasks. Does that not seem a little generic to you? This is what Windows does. This is what GNOME does. This is what OSX does. It's the definition of a desktop environment.

There are many many apps that work well with GNOME. They use GTK, they use Gstreamer, they use dbus, etc. So what if they aren't officially GNOME? They work well together. More importantly: they work well.

KDE apps don't work well anymore since the big 4.0. Everywhere you go, you see things that don't quite work yet. It will take a few years before that has stabilized. I don't know why such a clean break was necessary on the library level. For all the innovation that has been going on, KDE still works pretty much the same way. Had they just iteratively deprecated and improved parts, then the environment would incrementally get better.

This is what GNOME is doing now. GNOME 3.0 will not be very exciting/upsetting. It will feature an optional experimental new kind of desktop environment, and a lot of libraries will be deprecated in favor of the result of the major refactoring process going on right now. That's about it. Everything keeps working.

KDE and GNOME were already on the right track. They don't need a magical fix. You can build on existing mature software to make it better.

[energyman]

gnome stopped working with 2.0. And since then they did not improve.

KDE did a big cut with 4.0 and with 4.3 they are surpassing 3.5.
Not 'many years'. It is already done.

Compare that with gnome, which depends on evolution, a mailing app that crashes several times a day. Compare that with gnome that needs mono for a simple notes app. Something KDE can do as a plasmoid.

[RealNC]

KDE apps don't work well anymore since the big 4.0.

"KDE apps don't work well anymore".... How come they work just fine for everyone else?