But this is not what's happening here as far as I can see. The "Qt" app does not extend the basic framework, the app uses the basic framework of the device.

There's a big difference!

dubik, you got me confused. You basically said that DUI and Orbit are both there to perform the same task (highly animated finger-friendly UIs). You also said that DUI will work on all platforms, be it desktop, Maemo or Symbian. If so, what's the point of Orbit? Do I even need to care about it? Or will I use DUI+Qt in the same way that I use plain Qt right now and get a first-class citizen on all platforms, (almost) without #ifdefs?

So you can take Dui to Symbian, compile it, and create nice looking applications? To port any Maemo app to Symbian, the easiest route would be to statically link against DUI library?

And same for the case of developing an app for Symbian, with an intention to release a Maemo version later, also prefer DUI?

Or prefer Orbit for both instead of DUI, assuming that Maemo devices have both more storage space for extra libraries, and better package management?

Anyway, if this works, then no problem, but somehow I have a feeling it's not this simple...?

Yes, it's that simple
Dunno about orbit, but there are no technical reasons why you can't ship DirectUI lib with your app.

It won't be that simple.

1) Look and feel. Dui apps will have a different look and feel from Symbian ^4 apps, at least, this is one of the arguments used against my proposal. However, App Stores have look and feel as one of their main requirements, so a Dui app will not be allowed on Symbian^4 App Stores, and a Symbian ^4 app will not be allowed on Maemo 6 App Stores. This fact alone will make this proposal unusable for commercial developers.

As my proposoal results in apps having the look and feel of the host platform, it is not an issue there.

2) These libraries will be huge, and statically linking will result in huge apps. Huge apps are very hard to download, and App Stores have limitations on size too. It also results in the apps taking up more space on a device, so you cannot sell as many apps to a single customer as you could when apps were smaller.

3) Why have two libraries doing the same thing instead of one? If Dui and Symbian^4 can be put on both device classes, there is no difference. So kill either Dui or Symbian^4. The argument here was again that Maemo6 and Symbian ^4 is for different device classes. For political reasons, with two competing parties developing competing UI frameworks, it will mean the death of one party.

The problem is that both parties think that commercial third-party developers are very much interested in device look and feel, as they are, being their companies representative.

People, let me tell you, once and for all, commercial third party developers don't care at all for look and feel. True, look and feel will help sell a device to a device manufacturers customer, and for a device manufacturers perspective look and feel is vitally important.

But commercial third party developers will go for the look and feel that attracts the most paying customers. We don't care what we think ourselves about a given look and feel, we only care about the ease of making money.

Having a different API for each existing look and feel is bad for us as it makes it harder to make money. What we therefore do is support only the best money making API&look and feel combi's in the market. Currently that is iPhone OS, Symbian OS, RIM,

Again, device manufactures care about looks and feel, and commercial third party developers care about API's. What is good for both then is a unified API supporting lots of looks and feels. As far as we are concerned, different parties inside a company can slug it out all they want. It's not my company after all, and if the competition is better for my business I will switch anyway.

As I'm sure most have already noticed from Planet Maemo, it seems like Orbit aka Uiemo will run on Maemo. At least one quite big obstacle down on the road to interoperability.

Of course, this is conjecture from an early demo, but see for yourself: http://zchydem.enume.net/?p=561

Moreover, it runs on N900 as well; no need to wait for Harmattan.

Now it gets even more interesting with Meego. The Meego architecture talks about "Handheld UI Framework" and "Netbook UI Framework". The former will probably be the Harmatan UI Framework, but what about the latter? Probably also based on QGraphicsView, but will they have more in common?

So, to return to this thread, I never did get the chance to compare those working frameworks and figure out how best to go cross-platform as they've been canned:
http://mobilephonedevelopment.com/archives/1138
With reference to a post by a Nokia employee:
http://www.gorkem-ercan.com/2010/10/...-ui-and-i.html

I don't want to say I told you so but if people had been listening to the external developers back in November/December last year a lot of wasted effort and possibly time-to-market could have been saved.

My question now is, if the MeeGo UI framework is not the thing to use what is - really just QML? Where's the standard chrome (battery and signal etc) going to come from? Are there some QML components for that on the way. What will define the standard platform look and feel?

Just curious...

Mark

MeeGo Touch as Not been canned