So what is the sodding argument to re-invent the wheel (*poorly*) again? They could have been finished by now, damnit, and the FOSS desktop would actually be innovative NOW and have a chance against the big boys. But no, they rather waste their time building upon a pile of dogshit.

You are missing one vital point of why Qt simply isn't an option for GNOME, and it probably never will be.

Qt != Gtk+.

As simple as that. GNOME is a Gtk+ environment, and it will most likely always be. Gtk+ probably leaves a lot to be desired from a development point of view, but that only means there's a lot to improve.

KDE and GNOME both have their weak points, and it's up to the competition between the two (and others, of course) to make sure they improve upon their weak points, benefiting the whole of the community. Let;s not forget that KDE 3.x was an extremely messy environment, ten billion million widgets all over the place. KDE 4 is trying hard to fix this - would this have happened in a similar way if GNOME had not been around?

Gtk+ will improve, thanks to the competition with Qt. Your post is just mindless fanboyism that does nobody any real good. If you really want to help the FOSS desktop, as you seem to imply you want, then write Gtk+ bug reports, write a long article detailing the flaws, so that the Gtk+ developers can actually improve their code.

But that's really not what you want, is it? You are just here to proclaim the superiority of Qt (which is most likely accurate), but you're not doing it for the greater good of the FOSS desktop - but only to take cheap shots at the competition.

What's also sad is that, when an article about GNOME appears, the KDE fanboys have to jump all out of the woodwork and proclaim how much better their favorite environment is. To the KDE zealots: you guys put Apple zealots to shame in your sheer fanaticism, you could really teach them a thing or two. Funny how I don't see a lot of GNOME fanatics jump on the KDE-flaming bandwagon unless provoked by one of you.
As for the changes, I'm not sure what to think. On one hand, I like a lot of GNOME's interface at the moment as it is, but on the other, some of these new ideas really are intriguing. I probably won't end up forming an opinion until I've played with it a bit, I like to have hands-on with a new UI or program before I judge it. I am happy at the removal of obsolete libraries, and hopefully they will also take this chance to really slim down the number of abstraction layers in GNOME itself. They've been moving towards that goal slowly, so I imagine we'll see a much slimmed down GNOME come version 3.0, which would be a very welcome change indeed.

You are missing one vital point of why Qt simply isn't an option for GNOME, and it probably never will be.

Qt != Gtk+.

As simple as that. GNOME is a Gtk+ environment, and it will most likely always be.

Whoa, go back to the last millenium. KDE vs. GNOME is no longer about Qt vs. GTK. The last toolkit barrier fell with Qt 4.5 (GTK style included by default and license change to LGPL).
These days it's mainly about the usability philosophy since GNOME 2.x.
No developer seriously says that GNOME should drop GTK alltogether. However it's absolute perfectly possible to create 100% GNOME HIG conforming applications with Qt. Qt itself is rather small (at least by today's standards). So there's probably no technical reason to not use Qt here and there in GNOME.

There are people who say that GNOME should adopt Plasma. This case it a bit more complicated. It really depends on how much KDE code is really required for Plasma. When many KDE libraries have to be loaded into memory then memory footprint is a technical reason not to use Plasma by default.
Luckily, on an individual level it doesn't matter, because it is possible to use Plasma under GNOME. Thanks to common back-end standards used by both projects, clicking on the Plasma Log-Out buttons brings up the GNOME Log-Out window.

Perhaps conforming to most of the HIG, however one philosophy of GNOME is in regards to accessibility, and assistive technologies. At the moment, QT is not an option for this reason if no other, due to the lack of integration with at-spi. This is eventually going to be fixed, with the at-spi-dbus project aiming for useability by the end of the year, but for now any QT application would not be considered a GNOME application on those grounds alone. It's not just about the HIG, it's about integration, and as long as QT doesn't integrate with all of GNOME's core technologies no QT application would ever be considered for GNOME. As at-spi and the relevant assistive software is considered a core GNOME technology, this effectively bars QT apps. NOt trying to put down QT, just laying out the facts.

Whoa, go back to the last millenium. KDE vs. GNOME is no longer about Qt vs. GTK. The last toolkit barrier fell with Qt 4.5 (GTK style included by default and license change to LGPL).
These days it's mainly about the usability philosophy since GNOME 2.x.
No developer seriously says that GNOME should drop GTK alltogether. However it's absolute perfectly possible to create 100% GNOME HIG conforming applications with Qt. Qt itself is rather small (at least by today's standards). So there's probably no technical reason to not use Qt here and there in GNOME.

You're glossing over a lot. It's not just about whether you can create HIG compliant applications with QT. QT does a hell of a lot more than GTK. GNOME relies on several external libraries that do essentially the same thing as parts of QT. Take Cairo for example. What do you do with an application that depends on Cairo? Do you eliminate the Cairo dependency and integrate it with QT or do you leave Cairo and end up with a lot of extra and uneeded libs that only complicate things when someone decides to make a new app that doesn't use Cairo but uses QT directly instead. If you ditch Cairo and other libs like it you end up rewriting GNOME from scratch. That doesn't seem very helpful either. Ditching GNOME's GObject system for a more C++ compatible object system would also probably be necessary and make the task even more arduous.

Gnome doesn't have to be GTK, and QT != KDE. There is no doubting that it would be a large effort to rewrite applications for a different framework, but there's not reason not to have a meaningful discussion about doing so.

I think a lot of people would appreciate standardising on one toolkit. For a start, it would give a cleaner environment, it would allow more code to be shared be shared between KDE and GNOME, and it would make lives easier for those who currently try to get their applications to work with both GTK and QT.

I'm not saying Gnome should stop working on what they have, I'm just saying they should be more pragmatic and choose the right tool for the right job. Sharing more low-level functionality between KDE and Gnome would result in more time for both developer teams to work on actual innovation instead of rewriting each others frameworks. If you call that mindless fanboyism - well, sounds a lot like 'blablabla I can't hear you blablabla' with your hands over your ears.