Not really, as these also depend on a large bunch of KDE libs which (even if someone ported them) might not fit on the root filesystem.

IMO the guarantee is that they paid far more money just to get Qt than they ever did spend on GTK coders and development. By owning ex-Trolltech, now they have a far more vested interest of keeping it (and applications based on it) alive and kicking. Also, do not underestimate what owning actual upstream (!) means. In fact, I'd bet serious money that even considering the demise of Qtopia/Qt Embedded, the next Qt versions will somehow find new love for mobile devices

Hmm, if they can port KDE Plasma on S60 device it shouldn't be so hard to do it for Maemo?

http://www.youtube.com/watch?v=9ni_6qTwj-Y

That's just a "widget" (in the web run-time sense) engine, not a KDE application. It probably has minimal (if any) KDE-specific dependencies.

Fremantle will have a WRT too I think.

And if you absolutely must have KDE apps, there's always the chroot way ;-)

Well done effects can provide you with important information and UI clues more effectively than simple static UIs ever can.

As with anything, tools are nothing more than that, some people use them well and some people don't, and, unfortunately, doing this well is a skill many companies seem to lack, but from the Fremantle screencasts I've seen so far it looks pretty promising (Modest just looks slick).

That might be true if Nokia had targeted Fremantle (Maemo 5) at the current Maemo 4-sporting devices (N8x0-series).

As an existing Nokia/Maemo customer I really don't see much "transitionality" in this move, especially when it means that even the developers of existing (GTK+) apps will be encouraged to leave the current (hardware & software) platform as soon as possible.

Are they still selling those N810s...?

This is only Nokia problem, they simply don't care.

They simply say all the existing applications of Maemo 3, 4 and 5 made with Hildonized Gtk+ will stop working in Maemo 6.

This is simply un-excusable as a rationale direction and approach. Looks like dictatorship to me. "we don't care about your old software".
Why is so hard to keep both Qt and Gtk+? Stuborness? I know there is or can be created a small reason for everything, but if you want to say "the end user is our boss" then you have to make it easy for him, not very hard. The same for programmers, they will leave the platform if the direction changes that much dramatic.

Nokia missed a lesson.

I don't know if American culture where you can return what you bought to the store even after 6 months (like Costco) - so the culture that say "we really want to satisfy the customer like the customer is our boss" - compared to European culture - makes the diffrence, but:

1) unless Nokia will not make OS upgrade that is compatible

2) unless Nokia will not renounce on the practice of "secret" device API instead of public APIs and plug and play

3) unless Nokia will not go in zig-zag directions with the OS supported (the s80 and s90, superior to s60 were abandoned, s60 is kind of crappy for upgrade - installed applications will be lost, Maemo was kind of abandoned for about 2 years because no new device was released with it, and now they slowly restart working on a device for it)

4) unless Nokia will not keep the old GTK+ API in the system along with Qt, to let the users be able to use old Maemo 3, 4 or 5 applications

this sounds to me a wrong strategy, and there are many programmers, power-users and analysts out there saying Nokia is doomed in the smartphone market, facts and figures show anyways Nokia lost almost half of the market share they had (they had 49% in 2006 and at the end of 2008 they had only 31%).

I seriously doubt points like that make any difference at all in market quota.

All that's needed is marketing, marketing, and more marketing, and promoting "whatever the trendy reviewers think is the-nice-feature-I-couldn't-live-without-today-even-though-I've-been-living-without-it-for-years" (which these days seem to be:

• a IBM Model M quality keyboard on the phone,
• a low quality capacitive touch screen instead of a high quality resistive one which also works with greasy fingers,
• removing ALL of what is left from good old tested for years user interfaces and replacing them with 2 or 3 Homer Simpson-sized buttons,
• and, of course, a webpage-totally-filled-with-useless-but-expensive-applications a.k.a. "quantity > quality app store"

).

Also, plainly discarding all of its current Maemo user base and developer base will not damage Nokia at this point, so that's why I believe they made a good company decision by switching to Qt.
Of course, as both user and developer, it bothers me. But hey, I was just reading page 2 of the Gtk+ manual. There's still time to download Qt's manual instead.

As a KDE developer: That's incorrect. While the Plasma desktop shell does support widgets "in the web run-time sense" (it has support for Apple Dashboard widgets, which are written in HTML/CSS and JavaScript), the video in question shows native Plasma widgets, which are not web documents (i.e. UI elements, layout management, etc., are not done by a web content engine, but with Qt technology). They're written in C++, JavaScript, Python or other languages bindings exist for. Of course, being Qt, it's trivial to throw a WebKit element into a Plasma widget and show some web content in it, however.

Plasma requires KDE's libraries to run in addition to Qt, and various things shown in the video make use of technology found in those libraries - the freedesktop.org icon naming spec-compliant icon loading and the implementation of the calendar system, for example. In fact, Plasma's own library (which is also used by applications other than Plasma, for example the popular music player/manager Amarok) is part of kdelibs as well.

If you take a look at the info box for the video on YouTube, you will find a link to the sources in KDE's SVN repository there, including the S60 port of kdelibs. It's not a complete kdelibs, but I wouldn't really characterize it - or Plasma's dependencies on kdelibs - as minimal.