Rumors, Nokia hasn't announced anything.

Just a guess: people who used to work for Trolltech were called Trolls, so "post troll" is probably someone working for Qt Development Frameworks at Nokia (or whatever the official name for Trolltech is nowadays).

Likewise. I'll hope this DuiApplication stuff / source code incompatibility is some sort of mistake. I mean Qt is bringing declarative UI (btw. that's also "DUI") at some point (is it already in 4.6?). Wouldn't that help at least partially to fix this problem (presuming we really have a problem)?

The Qt 4.6 port for Maemo 5 is alpha-ish and the applications using it don't like like crap. Actually in most cases there is probably no way to distinguish them from a Hildon app. So the starting point is already better then the plain GTK+ situation.

Something that helps is that the Qt maintainers have Maemo well positioned in their priorities and they are delivering an official Maemo port. This was never the case of GTK+. Unfair and dubious comparison, I know, but let's not forget that it's the Qt team itself who is delivering this Maemo 5 official port.

They are the first ones not willing to see plain Qt apps looking crappy in any platform. And they have a long experience avoiding that.

I know that pure Qt applications are now looking good on Fremantle, but we´re talking about Harmattan here. Plain Gtk applications were looking ok-ish on Diablo but awful on Fremantle.

I´m just worried that history will repeat itself and we´ll end up in a situation like the current Hildon/Gtk situation. Once burnt twice shy - as they say... But yea, I´ll try to stop worrying and I´ll continue to learn about Qt. I´ll also watch this thread hoping that some Qt-Wizards shed some light on the issue.

Hi everyone, my name is Tomas Junnonen and I'm the guilty party who gave the introductory talk to the Maemo 6 UI Framework at the summit. Quim kindly pointed me to this thread so that I could address the concerns raised.

First of all, the headline is definitely not true

Qt remains a cross-platform toolkit and is definitely source compatible across the desktops as well as Maemo and Symbian. Qt-only applications in Maemo 6 are first-class citizens, we're putting a lot of effort into making sure they integrate well, look nice and that things like kinetic panning "just works" as one would expect simply by compiling for Maemo.

So what's with all the DuiApplication etc. stuff? This is something we're adding on top of Qt that we think will take the UI to the next level. Those of you who have been following the developer blogs of Qt will no doubt have seen a lot of exciting new features emerging just this year, such as the animation and state frameworks, multitouch, Qt/3D and of course everything related to GraphicsView. For those not familiar with the concept, the Qt Graphics View framework removes the limitations of traditional Qt or Gtk-like UIs (such as widgets being restricted to small rectangular areas, no real overlapping widgets etc.) and just gives you this great big canvas on which you can arbitrarily draw, animate, scale and rotate items to your hearts content.

So you've already got all these great new capabilities in (or soon to be in) Qt itself. But by themselves these are just the individual building blocks. When you instantiate a GraphicsView it literally looks like a piece of white paper. In order to take that and create a useful application out of it, it's going to take a lot of code. You're going to need widgets, layouts, transitions & animations, probably theming so things look consistent if you're ever going to have more than one application etc. That's what the Maemo 6 UI framework gives you. There's actually very little overlap or duplication with Qt itself (linear graphics-layout comes to mind, ours is implicitly animated), because while Qt for example defines what a widget on the graphics scene is, it doesn't come with any. In the upcoming Qt 4.6 you will see the first usable in-scene widget, QGraphicsWebView, which you will be able to drop into your Maemo 6 framework using application. One day Qt may grow to include everything, although that too would have its downsides, but we are not yet there today.

I hope this clarifies things a bit

I'll just take this opportunity to address some specific questions raised in the thread:

- DuiApplication vs QApplication. Like KDE and others, we do extend the base application class. Qt, being platform agnostic, cannot really do any initialization that being part of a specific platform typically entails. For example, it has no way of knowing where the translation catalogs for the application is located on the system. DuiApplication checks what is the active language (from the platform configuration system), loads the correct translation catalog, checks and initializes the active UI theme, connects the application to the system message bus and so on. It's tedious work, but someone has to do it

- Modifying Qt. Unlike Gtk+ which we patched quite heavily over time, except for some build configuration infrastructure we don't really add anything to our Qt packaging. If we (Maemo) need some change we will work with Qt together to upstream it, or better yet work together already during the initial feature development.

The Qt declarative UI, which like the Maemo 6 UI framework is built to work together with the Qt Graphics View framework, is a tool that can be used in many ways. Taken by itself every single application is still left to reinvent event the simplest of widgets again and again from the primitives. In order to achieve platform consistency, wouldn't it be nice if there was a library with common reusable components available? That could be used together with the declarative UI format?

We're digging the declarative UI in Maemo. In fact, we like it so much we think the visual QML designer that integrates into Qt Creator should be the way to rapidly create your Maemo application UI as well.

Thanks Thomas for replying here! I guess then I'll start using plain Qt 4.6 and later (if needed) add some Maemo 6 specific stuff once I've actually seen the benefits it brings.
It's good to know that you want to support normal Qt applications as first class citizens

Thanks a lot tomasj!

Let me add that Tomas has been in the Maemo team for a loooong tine and he (like others now driving the Maemo 6 UI framework) knows the patched GTK+ phase very well. I'd say they have even a personal interest in not going that way again, now with a Qt toolkit.

So if I understood correctly the above, in practice an application developer has two choices:

1) use the vanilla Qt. The apps will look just fine on Maemo 6, and should work ok on Maemo 5 too and other platforms. Good cross-platform experience.

2) If you want to make your app as shiny as the Maemo 6 default apps will be, then vanilla Qt is will not get you all the way as the Maemo 6 UI Framework is an extension (superset) of Qt. And by the way all those widgets, layouts, transitions & animations functions in this start with DUI, not Q.

So unless I'm totally misunderstanding something... If just crossplatform is not enough for you, but you want to take the best out of each platform, then you will have to code Maemo 6 specific UI for the Qt app. (and consequently separate UIs for the other platforms).

Thank you tomasj!

It would be nice to receive confirmation that the DUI APIs are designed to gracefully degrade on any platform that does not fully-support them. It's important to make cross-platform development as painless as possible, even if the final testing must be done on the fully-supported platform.

Regards,
Roger

I still have a misunderstanding. In the past QT was able to create a framework that worked and looked as it should on the host OS
Here we have three entities : QT, Symbian and Maemo, all three under the same umbrella. At this point Symbian and Maemo are developing two different frameworks both on top of QT, each meant to do almost the same thing.
Why doesn't this crystallize in a QT official extension supported on all systems QT compiles on? In this way we would know that using DUI we get the best look on both systems. I mean it should be easy giving in the end they are all under Nokia's umbrella.