[Note: this is a copy of a message I posted at Forum Nokia, about compatibility between the Maemo6 UI and the and Symbian ^4 UI, this being my main concern. But because Maemo 6 is also breaking source compatibility with Qt in general, I am posting here as well, as Qt's single source/multiple deployoment is being used to attract developers to Maemo too]

I would like to know Nokia's official position on source code compatibility between Maemo 6/Qt and Symbian^4/Qt.

As far as I know, Qt enables single source/multi-platform programming, and that ability was the main reason Nokia has bought Trolltech. I have seen live demo's of a single source Qt app compiling to both Windows XP and S60 5th ed.

Also, Qt is currently being advertised by Nokia in both the Symbian Developer community and to other (mobile) developers as enabling them to a single source app and deploy it on multiple platforms, including some mobile ones (not the one we need, but anyway).

If one looks at such a source I see some kind of archetypical app looking like (from the Qt 4.6.0 beta release)

#include <QApplication>
#include "mainwindow.h"

int main(int argc, char *argv[])
{
QApplication app(argc, argv);
MainWindow window;
window.showMaximized();
return app.exec();
}

So, I would expect code for Maemo 6/Qt to look exactly like this.

However, on this site [http://zchydem.enume.net/?p=128], which is linked to from maemo.org, and also in the Harmattan source repository (http://qt.gitorious.org/maemo-6-ui-f...hnical-preview), the example code looks like this

#include <DuiApplication>
#include <DuiApplicationWindow>
#include <DuiApplicationPage>
#include <DuiButton>

int main(int argc, char *argv[]){
DuiApplication application(argc, argv);
DuiApplicationWindow window;
window.show();
DuiApplicationPage page;
new DuiButton("Hello", page.centralWidget());
page.appear();
return a.exec();
}

Apart from a certain API similarity I would not say this is Qt code. And even if it is Qt code, with DuiApplication being a subclass of QtApplication, it is immediately clear that there is no source compatibility here.

On developer.symbian.org there is talk (http://developer.symbian.org/wiki/in...Prop/Direct_UI) about a Qt based Direct UI, which abbreviated looks just like Dui. But in the paperwork I've seen there are no API's by name, so it is not possible for me to verify whether Dui on maemo 6 and Direct UI on Symbian^4 are the same.

So, some questions

1) Are Maemo 6 and Symbian^4 both going to use this Dui/Direct UI library? If not, why not?

2) Why is Nokia departing from Qt single source/multiple deployment promise for this particular case. I can imagine one might need new widgets for new controls, but I fail to see the technical reason to create a new application class.

Just googleing Qt Direct UI turned up a ton of stuff about this. Direct UI is nokias "finger friendly" UI add on to Qt which will be used on both Maemo and Symbian (and maybe not just Maemo 6 and Symbian^4, it may well be on 5 and ^3 too).

One article here http://mobileduo.blogspot.com/2009/0...-orbit-qt.html

heres some info about symbian^4 from symbian foundation blog

Symbian^4

Planning for Symbian^4 is at an earlier stage. It follows Symbian^3 by around six months.

The following technology contributions are expected to be fully integrated for Symbian^4:

* Qt optimised for the Symbian platform – Qt is a well-liked application and UI framework;
* A new “Orbit” extension library for Qt, which contains more than 50 widgets tailored for mobile user experience, and which will provide a replacement for the existing “Avkon” widget set;
* A new “Direct UI” interaction and navigation logic, combined with finger-optimised layouts offering excellent touch and hybrid-device user experience;
* The application suite re-factored and re-written to take advantage of Qt APIs, Orbit widgets, and Direct UI.

Elements of this combined offering will of course be available for experimentation ahead of their full integration in Symbian^4.

http://blog.symbian.org/2009/04/30/r...-release-plan/

@svdval: As I understand it, it's not *instead* but *on top* of Qt 4.6 (i.e. Qt4.6 != Maemo 6 UI framework). So your original example would still work, but probably with some visual/input limitations (a bit like GTK and Hildon, but the Dui stuff is much broader). People more into Dui stuff, feel free to correct me

Plain Qt 4.6 applications will run in Maemo 6.

The Maemo 6 UI Framework will offer additional / optimized features for projects interested in Maemo specific integration. Such optimizations are being proposed to the Qt team to be integrated in future Qt releases, either in the "generic" Qt or the Qt Mobility libraries.

The Maemo team (or the Symbian team) can have the "luxury" of productizing such additions / optimizations faster since the Qt team is developing a common toolkit for several platforms, and this requires a lot of extra work on development (sometimes rewritting entirely a library) and testing.

There will be enough time of Harmattan pre-releases for developers to figure out how well their plain Qt projects run and feel in Maemo 6, how interesting are the Maemo optimizations offered, how much extra effort is needed and if it's worth... And also plenty of time for providing feeedback to the Maemo and Qt teams, file bugs, etc.

I think it's this conversation behind the link that makes svdwal anxious about the compatibility between Maemo6 and Symbian^4. From what I gather, there is no official stance from Nokia on this.

http://developer.symbian.org/forum/s...ead.php?t=3363

There is a lot of stuff, but none of it on an official Nokia website, such as Forum Nokia. Blogs have their advantages, but them clearly being an official company policy repository isn't one of them.

Any reason for two different UIs on Maemo and Symbian, both sitting on top of Qt? I could understand that there is no specific layer on top of Qt for, say, Linux or Windows, but since both Maemo and Symbian will be ran on touch based devices, I don't see the point of two different UIs.

I don't believe it is a good idea to push Direct UI all the way to the application level. The whole point of Qt is it being a library that hides as much as possible of the host platform. So if you introduce a DuiApplication class and assorted other Dui classes will result in 2 things

1) porting existing Qt apps will become harder and more expensive.

2) by the time all systems are multi touch, one would expect Dui to be changed back to Qt. So all apps will have to be ported again.

That's two times work for nothing, with no value being added.

Worse, you cannot advertise to developers that Maemo is a proper Qt platform. It would be if your existing Qt code would compile straight away, and that it would "magically" incorporate multitouch as far as that is possible without application adaption. The only thing I would expect to add code for is those bits of multi-touch that the system cannot abstract away from user code. But that is fine.

Let me give an example. On a multitouch system one can imagine setting a row of checkboxes (representing a set of booleans) by touching two buttons at the same time. All buttons in between will then be turned on. On a single touch system you have to touch them all yourself. At the API level I will see a bitset with some bits on and some bits of. I don't care whether they were set individually or all at the same time. Only if the widget notifies observers of state changes might there be some programming needed, for instance, if the code assumes only a single bit can be turned of or on, I would have to change that (in such a way that the code handles both single bit changes and multiple bit changes in a single state changed event).

AFAICS, existing widgets do not have to be renamed to get them multi-touch enabled. For instance, if I want the default widget that returns a boolean, I don't care if it looks like a slider that's to the left or right, a checkbox that's on or off or a choicelist that's yes or no (this is for those people who remember Series 80). I want the systems standard boolean widget. I don't want to worry at the API level what it looks like, that's the concern of the UI builder.

Only the widgets that make sense only in a multi-touch environment can have a different name, but even then, at some point in the near future multitouch is as common as single touch is today, so having them named differently will be thought of as a bad idea then, so it is a bad idea now.

Qt for Nokia is an asset as long as code written for Qt can be deployed on lots of platforms. That is after all why Nokia bought it in the first place. So, with Qt in place, Nokia has a very good value proposition to (commercial) developers, which is the size of the Qt user base. Qt is capable of hiding the differences between Symbian^4 and Maemo 6 for a lot of apps, and that means that Maemo 6 and Symbian ^4 devices can be counted together as a single platform.

But, as soon as there are differences between Maemo 6 and Symbian^4, there won't be a single platform anymore, and the value proposition Nokia is making to (commercial) developers drops hugely in value.

Nokia should know this because they had at some point three different UI's. S60, S80 and S90. And even though S90 and S80 were almost identical, the differences were big enough so that only the most trivial apps did not need porting. S60 and S80 were so different that all UI parts of apps had to be rewritten. A bit later, Nokia killed S80 with the excuse that two UI's were too expensive to maintain.

And here we are, 5 years down the road, and Nokia is making exactly the same mistake again. I believe that "flabbergasted" is a better description of my emotional state than 'anxious"