For some time already I wanted to join this discussion in a productive manner. But as this is quite a complex subject I was unsure where to start. So I start with a couple of observations and questions.

I don't have Qt experience yet, but I used Gtk+ and Hildon on Diablo and Fremantle a lot. I've also used Hildon a lot during the Beta phase of Fremantle (starting from the first version with UI support).

From what I learned with the Fremantle Beta SDK, I feel save to say, that once a SDK with UI support is released it's definitively too late to change anything substantial.
Unfortunately I'm quite sure it's already too late for Harmattan even without a SDK release.

So we will have Dui* widgets and we will have Q* widgets. That's not too bad yet. The question is, how deep/thick is this UI layer?

I mean we have to redesign the UIs anyways between different platforms. So to me the main question is: How much of the backend code needs to be changed? And if I'm talking about backend, I don't mean stuff like a database or a sort algorithm. I'm talking about the UI backend like callbacks/slots.

Is there some compatibility between Dui* and Q* widgets? For example, does QPushButton and DuiButton both implement a common Button interface?

I mean, I don't really care whether a Button is implemented using the QGraphicsView or not. To me it's still a button.
I can set a label, an image, etc. and whenever it's clicked it will send out a "clicked" signal.

If now the DuiButton and the QPushButton send the same "clicked" signal. My UI backend is happy because I don't have to change it.
But if the QPushButton sends a "qClicked" signal and the DuiButton sends a "DuiClicked" signal, then we have a problem because those "small UI" changes will ripple through our complete applications.

And of course it's not only signals, it's parameters send with the signals and methods called on the widgets.

Unfortunately I'm quite sure I already know the answer. The "pressed" signal which I find in duibutton.h has probably nothing to do with the "pressed" found in QAbstractButton. At least I cannot find any signs about that looking at the code.
And that is bad. Really.

Before I had a closer look at the code and this thread I was imagine it would work approximately like this:

As a developer I'm writing my code on one platform (e.g. Maemo). A very thin UI layer is separated into one file. Or one file per window. Those files are code or XML. Handwritten or created by a designer tool. But those files really only contain what the user is seeing. So only stuff that could be made by a graphical UI designer tool.

Then I implement the rest of the application. When I'm done. I fire up the Symbian UI editor and create a UI for Symbian. And that's basically it.

In the background there would be factories which create DuiWidgets or QWidgets but to me they just look like Widgets. Now if I need to invoke the Widget::setSuperTransparentAnimation() method which is only available in DuiWidgets. Then I would just cast my Widget to DuiWidget and invoke that method.

This way I could selectively use Maemo or Symbian specific code whenever I need it. And only when I need it.


I hope I was not too confusing I'm tired and if I talked BS, I'm sorry. Anyways, I think this is the single most important thread at the moment. And we should give the people on the devel-mailing list a hint that it exists.

Well, in the end it looks like Conboy will use Gtk/Hildon still a bit longer....