So what's the purpose of Orbit and DUI then? Ie. what functionality they provide, that will not be available to cross-platform applications? Ie. why would a programmer want to use them in the first place? Ie. will cross-platform apps be seriously crippled in some ways?

Will it be possible to mix plain Qt and Orbit/DUI? What I mean, can Orbit/DUI widgets be insde Qt widgets, or vice versa?

What I'm after is this: Let's say there's some functionality where there exists both Orbit and DUI widget, but no plain Qt widget. So programmer would want to use plain QT for everything else, but us this functionality with something like #ifdef#else#endif around the device specific widget initialization. Is this easily possible, or will it require a lot of wrapper code, or will it be completely unsupported?

Orbit and Dui are UI Frameworks which provide ways to write finger oriented, highly animated applications. Basically something similar to what iphone, android or palm pre provides. QWidget is not designed for that. They also provide quite a few other things like virtual keyboard, localization, application lifecycle, service framework, notification framework and so on. Perhaps I phrased it wrong in my message. Dui apps are not maemo specific, they are Dui specific. You can take Dui library to your platform (where qt is supported) compile and create nice looking applications. Developers would want to use them because of current trend in application development. People don't buy crappy looking apps. They want eye candy. Eye candy is something which is not easy to achieve with QWidget. Looks like QML is coming to rescue but with QML DirectUI can and will work quite nicely, so they will be nice additions to each other and not really competing.
Btw, DUI is going to be heavily optimized for OpenGLES 2 devices. Not sure i can say the same about QWidget apps.

Dui/Orbit QGraphicsView based applications. You can mix QT into those framework if you can inject QWidget into QGraphicsView. Actually you can do that with proxy widget but it will be pretty slow. Check recent Gunnar's post on QT blogs.

Noone tried to include Orbit and DUI widgets in same app. I don't see reasons why they can't coexists. They both based on QGraphicsWidget. How much #ifdef will be required depends how you structure your app, so hard to say. Lets see what is Orbit in details, what layouts and widget it has, what api it uses and so on.

I think you are overlooking the Web Runtime here, which is just as first class citizen.

How many Javascript-friendly developers you find for each developer ready to go through Qt+DUI/Orbit? How many simple mobile apps you will find for every complex app requiring the native API? If the Symbian/Maemo cross-platform story is attractive then the Symbian/Maemo/iPhone/Android/Palm/Blackberry/Bada "fairly compatible" story is even more interesting.

Qt / QML / QGraphicsView might be more than enough for a segment of native developers. We can discuss this more in details when we see plain Qt running in a Harmattan SDK.

The loud voices in this thread are coming from you innovative developers, willing to squeeze the cutting edge. Are you representative for the majority of developers now and by the time Maemo 6 is released? Well, I doubt so.

I expect DUI to play an important role in Maemo 6, setting high standards for the UI Framework and providing the promised iconic user experience. Our native applications will sport it and we will invite the most demanding developers to use it. But the Web Runtime and Qt will be just as important.

Then time will tell, and more work will be done based on concrete interests and needs. How much and how fast will Qt integrate from DUI/Orbit in future releases? How much interest will DUI raise in platforms other than Maemo? What real stories will there be about cross-platform development?

We don't know the answers but we know that things move fast.

It's sad (at least, for me) to see the resistance* in this thread to really understand what is needed is definitely NOT case-specific not-much-flexible workarounds to save the day, BUT universal flexible** solutions to save the future. I hope to see a final product of a wide vision, instead of a narrow mind.

* I'm not pointing any fingers directly to anyone, I just speak generally.
** As far as possible, for sure. Please see my comprehension before replying.

So why Orbit and DUI and not only one widget set for symbian
and maemo? Whats their fundamental difference (did i miss something here :-))?
So in the future all widgets that Orbit and DUI have in common will be integrated into Qt?

Thanks and Cheers

Almost all of Qt apps in the world extend the basic framework to include their own widget sets and APIs. Even on desktop, some of the more serious commercial application use Qt as the core commonality but not to write a single app that magically works across platforms: they want the platform differences but also relatively cheap porting and a common set of tools.

This maybe is less than perfect, but I believe that that's reality and it's going to remain reality for a good reason.

When you try to limit mobile application developers to what a cross-platform framework can do without some platform-specific extensions, you end up with something more like J2ME or very basic HTML. Generalizing UI needs in a cross-platform way takes time, more time than Nokia and other companies have if they want to innovate in a way that reacts to market needs.

To be more precise, we COULD have a 100% common API that would allow for the awesome new touch UIs and would work great on Maemo and Symbian devices, but it would probably be ready a couple of years from now - when we already want the newer thing.

What is probably more practical is letting Maemo/Symbian innovate on their time frames, and later take the common parts into the core framework. Qt has done this with KDE for years.

Qt is an excellent cross platform TOOLKIT, and if seen as such, it makes perfect sense (at least to me). It's the core for building great DUI apps for Maemo, great Orbit apps for Symbian, and later QML apps (some of which will be fully portable, some will include DUI/Orbit specific components).

There's always a difference between what a purely cross-platform app can do (whether it's QWidget / QGraphicsView / QML / WRT) and what an app with a specific platform in mind can do. Show me a solution that solves that problem - Android tried but I don't think they've proven success (see posts about subtle fragmentation between Android phones - J2ME deja-vu).

With Qt you can port the pure cross-platform apps for free, and the platform-specific apps for cheap (as QGraphicsView is still the core for both Dui and Orbit). It is my belief that that's the role Qt should have!

I hate to interject with the voice of a noob, but...

As an old developer I understand some elements of this debate, mostly at a high level, but I am struggling with many details.

Has someone diagrammed this issue to make it clear to understand "at a glance"? If not, will someone? Before I get too deep into Qt?

@Texrat

There are few things I am pretty sure:
1) Vanilla Qt will work on all platforms.
2) There are people know the issues and already look into it.

The problem I have seen so far are the matters of UI, top level wrappers and service framework (Maemo 6 framework and Qt mobility project).

But come to think of it, it's similar to Qt on KDE. Where KDE has different set of APIs on top of Qt, but basically you could access most functionality via just writing Qt vanilla code itself.

One suggestion, if you want to write code on N900 and keep compatibility for future Maemo platform:

1) Write the core in plain Qt code
2) Decouple your UI from the core since it has to be re-written anyway for future more touch friendly experience.
3) Pack your functionality relies on devices specific hardware into components, such as bluetooth / camera, etc. In case anything change, you just need to re-write the underlying code without screw up your whole application.

Things will come more clear when close to Maemo 6 release. However, studying Qt itself is the right track since either Maemo 6 or Symbian^4 use Qt as foundation.

There is a big difference between having to create a couple of widgets and having to rename each and every Qt class in your app.

The Dui proposal requires you to change all the top-level UI code. Even though the change seems trivial (Q becomes Dui), it results in having to add complete UI components (an extra one for Dui and probably an extra one for Symbian ^4's UI as well), unless you take certain measures. The measure one takes is to add an extra layer of indirection called a Bridge, with a MyApplication calling either a MyDuiApplication (implemented by DuiApplication), a MySymbian^4Application (implemented by the Symbian ^4 variant of QApplication) or a MyPlainQtApplication (implemented by QApplication). Do this for each and every high-level Qt class that is or might be renamed now or in the future.

Considering that all Qt classes are already implemented as Bridge classes, the obvious thing to do is to implement Qt for Maemo 6 as an extra implementation for the main Qt classes, and to do the same for Symbian^4, and not require each and every developer that wants to target both Symbian^4 and Maemo 6, and possibly other Qt-supported platforms, to create their own set of Bridge classes. That is a complete waste of our time. The commercial realities of mobile development are such that commercial developers do not have the luxury of spending time to fix defects in vendor-provided frameworks. This is something that vendor employees should think very carefully about, because their actions will reflect on the vendors perceived willingness to support commercial third party developers.

Having dealt with the generics, its time for the specifics.

Having device specific classes is of course fine, as long as there are also plenty of generic classes. To make this more concrete, I don't care about the look and feel of the class that lets me set a boolean, as longs as its interface is the same, which means that there should be a generic Qt boolean widget. The reason is that almost all widget classes that I use in my apps will be generic widgets, maybe with a few device-specific ones at places where it matters. If I have to spend days on managing generic widgets (number and text input, radio buttons, sliders, checkboxes, labels), I don't have time for creating that single special widget that makes my app stand out from the competition.
So, create as many Dui-specific widgets as you want, but put the behind a unified Qt API that says, get me a boolean , or get me a number, or get me a bit of text.

The mayor factor on deciding what Qt-enabled platforms your app will have to run on is screen size. In that respect Maemo 6 and Symbian^4 are almost identical, compared to the desktop, notebook and netbook worlds. So changes are that I will need two sets of layout definitions, one for handheld devices and one for big-screened ones. But that is two layout definitions, not three slightly different sets of code.

I don't think it will take years. Implementing the look and feel of the widget might take a year, but defining it's interface will take days, and putting it in the Qt framework won't take that long either.

By that time the mobile OS war will be over. By having a unified Qt API it might take slightly longer for the platform to become available, but the upside is that the unified mobile Qt platform will be a lot bigger from the start, combining both Maemo 6 and Symbian^4. And as a bonus, you get the additional Qt platforms for little extra work, and not for much extra work.

Java had problems because vendors deliberately introduced their own extensions and incompatibilities. Further, for very small screens you do need exact pixel placements. That isn't a problem with mobile screens as big as they are now, for standard components.

Hiding Dui behind Qt is the way to make things cheap. Only for the Dui classes that do not have a generic Qt equivalent do you need it. DuiApplication, DuiWindow and such are not needed at the third party API level.

I don't have a technical argument - I completely agree that a better way to do things would be as a Qt backend and not a frontend on top of Qt. I also believe that the Maemo/Symbian people have done their best to use the Qt toolkit to create great device UIs in an acceptable timeframe, and sometimes in that process the API choices are optimized for short-term device UI work and not for portability - that's inevitable if Nokia ever wants to go to market. If I was in their place, I don't know if I could have done a better job on the same schedule and conditions without knowing what I know now, when it's already done (but maybe someone else would).