Absolutely, QML + JS and webkit are they key here. There should be a way to package such an app (with all the artwork and what not) and deploy the same way on Symbian, Maemo and all desktops Qt supports (I get that not all of them will have identical input methods but the code should run). The upside of running these on Nokia devices should be that it all comes heavily HW accelerated (and battery efficient) on the back end.

Hi,

I'll start by saying I work for the Symbian Foundation but these are my own opinions, not those of my employer. I'll also add that I'm a big Maemo fan too - I've had an N800 for ages, and my N900 is sat at the local DHL office ready to be delivered tomorrow. :-)

The criticism on this thread is spot on. Mameo DUI and Symbian DUI are not the same thing (as I understand it, the Symbian side of things accidentally stole the term from Maemo).

I've investigated this myself (and I used to be a software architect at Nokia, so you might consider I have some idea what I'm talking about) and I've also talked to people whose opinions I respect in the Qt, Symbian and Maemo organisations. We all agree - this Direct UI madness is a big mistake Nokia is making and it's going to come back to bite them.

To quote Tomas Junnonen from earlier in this thread:
This analysis is spot on. The UI paradigm is changing - people building UIs with standard QWidgets will find them looking "old" on these rebuilt Symbian^4 and Maemo 6 products. The new UI paradigm needs some new widgets built for the GraphicsView framework. However, the very LAST THING developers need is two completely separate implementations of essentially they same thing with different APIs - one for Symbian and one for Maemo. The idea that pure Qt apps will be OK on both is pretty pointless if you have to build your own set of widgets that's portable between the two.

The very concept that Maemo and Symbian (via Orbit - currently being renamed Symbian^4 UI framework) should build new UI frameworks on top of Qt, which is supposed to be a cross-platform application and UI framework should have set alarm bells off everywhere! When you consider that Qt is owned by Nokia, along with Maemo and almost all of the Symbian development teams - it seems almost inexcusable that there should be any framework built on top of Qt. However, given that there could be a desire to preseve the quality of Qt by not expanding the team working on it too fast or diluting the quality of the engineers, and at the same time a business need to build some products on top of the technology, you might be able to excuse a common set of widgets etc on top of Qt for mobile devices. Unfortunately two separate sets is just insane and WRONG, WRONG, WRONG!

Of course there and plenty of smart people in Nokia and this was not the original plan. The thing called Orbit was meant to be cross-platform. I heard from a fairly senior guy who sat on strategy meetings that the teams involved were basically looking for reasons to diverge and build separate frameworks from day 1 - as soon as the strategy was laid out.

Why? Well there were two teams building UI frameworks before Qt was acquired and a lot of people that would like to justify their jobs! Also, building a new UI framework on GraphicsView is interesting and challenging work which the engineers in both camps would love to do. Could they not have worked together on a single one? Apparently not.

Quim Gil, who I generally have a lot of respect for, seems to be in defensive mode here:
This is just wrong. It shows total priority on building products rather than building a platform for developers. As I've said, pure Qt is not enough any more, not when the platforms build their apps with different widget sets. This problem was solved by Qt for the various desktop platforms right down to phones and coffee machines - the same solution could work again. Different styles for different platforms and in some cases platform specific private implementations of classes.

There is absolutely no reason why you can't build completely different looking apps and platforms with the same application and UI framework.

I realise that Nokia employees can't agree with me publicly and criticise the actions of their colleagues and the company they're working for. However, people with the influence of Quim Gil need to recognise the mistake that is being made and work to fix it before it's too late, or at least minimize the damage if it is indeed past the point of no return.

I've done this, plain Qt apps can and do work across platforms. The future frameworks for Maemo and Symbian do offer something of interest to almost every developer - access to special platform input methods and the core widgets that the platform applications are built with. Don't you think 3rd party app developers will want the advantages of the GraphicsView framework for the same reasons the platform application developers do?

Waiting until these things have shipped will be too late. The Symbian one is not yet available for anyone outside Nokia to compare with what Maemo are building. By the time they do and all start ranting at once, it'll be too late for you to do anything about it and another own goal for Nokia.

Developers will want to build different UIs for different form factors in the future, and Qt's technologies, particularly QML should make that feasible in terms of time and effort. However, make the fragmentation optional or at least only reflecting real physical differences like screen size and input capabilities - don't create it artificially along political boundaries within Nokia's organisation.

Qt - cross-platform applicaitons for all Nokia devices.
QGraphicsView - excellent technology for creating next generation UIs.

Great strategy, botched implementation - PLEASE do everything you can to fix it.

Mark

Hi Mark, nice post with good technical insight.

Now, you know that software is developed by people with goals. In theory you can look at a toolkit and conclude that it will take this time for this amount of people to come up with a release. In practice this doesn't work like this.

Remember how was life around Qt only 2 years ago. Trolltech was a company in Norway. Symbian was a closed core OS developed by a company in the UK. There was S60 developed in a closed environment by several companies. Maemo was a GTK+ based platform pushed by a small team living basically out of the Nokia mainstream software strategy.

Now, at which point and at a which cost would you have been able to create the single team developing the toolkit to make everybody happy? Qt, Symbian and Maemo have different stakeholders with some overlaps. They have slightly different ways of working. The three organizations are going through huge transformations and in the meantime they have roadmaps, releases and products going out to the market. And yet they still have own goals, even if they complement each other and are sometimes common.

And yet they are converging their interests and releases around Qt, taking care of their own goals and stakeholder while adding on top instead of forking or reinventing. The three organizations are committed to open source development and early pre-releases, and this is why you have the elements to start this discussion in the first place. This public exposure and this long road to stable releases will fine tune a lot of what can be improved together.

I still believe this discussion will be more useful when we have concrete SDKs and platform releases to compare. The day someone comes pointing to duplicated, pointless or missing features then we will be able to have a proper technical discussion.

In the meantime we must play this game where you are the apocalyptics and we are the integrated, when actually the picture is more interesting than that.

Note that this multiparty exercise (that includes you) has a chance of big success precisely because the setting is more wide and diverse. This is one of the reasons why I think I'm working in the right platform and in the right direction, even if the story is not always as simple to explain as I'd wish.

The fear is that at the point we have SDKs and platform releases, the ship has already sailed, and IF there is an 'oops' we will be discussing damage control at best (case in point: the /opt story) and maybe suggesting things for Maemo 7/Qt 4.7+. From what I've seen so far about the Maemo 6 UI Framework, it's a bit scary, exactly because it's burning bridges to the rest of the Qt ecosystem. Once you're in Dui-land, there is no going back to 'plain' Qt, in effect, creating a sub-framework. I (think I ) understand the challenges of adapting a general application framework to a mobile use-case, but the prospect of having so many layers and layers of complexity makes it look a bit scary. In facti, it makes the original 'Code Less. Create More. Deploy Everywhere' motto sound like a slightly hollow promise or at least subject to more and more interpretation.

As someone else posted earlier in this thread: Isn't it too late then? Just look at libqt4-maemo5. A lot of things done there are Fremantle-only so Qt4.6-powered apps can be released for the N900 in a timely manner. Harmatten is supposed to be the release where stuff is done right. I as a developer have accepted the fact that Fremantle is this transition release, mostly based on GTK/Hildon and landscape view with portrait mode and first-class Qt support coming as additions later. Harmatten is the first real Qt-based release that better be enabling hassle-free cross-platform development (at least including Harmatten and S60).

So the API has to be gotten right for Harmatten. No developer wants a third, yet again incompatible API for Harmatten+1. If we wait for SDKs to come out, it will be to late to change such fundamental things (at least for Harmatten). History proves this: the Fremantle SDK still ships with an ancient Python and a broken (!) gdb. Even the Maemo5 Qt team inside Nokia can't get the SDK team to ship an updated gdb that will work with Qt apps.

The Symbian and Maemo teams have announced their plans for the future. If what Mark Wilcox writes is correct, we will have similar but incompatible APIs for Symbian and Harmatten. Now, why would I need a SDK to be able to talk about that? So I can check for myself that my Harmatten app just produces compile errors on S60? Obviously we need to talk about this right now and influence the proper people so that no SDK is ever released publicly with those incompatible APIs. In the alternative, a simple statement by a Nokia representative that of course API compatibility is a top priority and is being worked on as we speak will go a long way. Or am I missing something?

Hi,

Thanks for the lengthy response. I don't see this situation as apocalyptic and I'm really glad that both platforms are in open source so we can start doing something about this rather than Nokia dumping a couple of largely incompatible SDKs on us shortly before products ship.

Yes, I know very well how it works (or doesn't in some cases) having been involved with platforms for most of the major OEMs at some point.

Yes, I know this history very well too, having been in and around Nokia and Symbian, using Maemo regularly, a Forum Nokia Champion and writing a book that included a lot about Qt and the need to follow the Qt tech previews very closely for that. (BTW, my book is about porting to Symbian and a lot of it about porting from Linux-based platforms, so this is a subject very close to my heart. Qt was the holy grail and Nokia have shown it to us and then pulled it just out of reach again.)

Nokia has been through a hugely challenging time, but they've spent about 9 of the last 18 months re-organising internally - it can only be concluded that politics has trumped technical strategy and pragmatism in this process (actually I've seen lots of evidence of that elsewhere in the organisation too - ask about PlatSim vs QEMU internally on the Symbian side for example...). I'm not saying a single team to create the framework was required, just a cross-platform co-operation to define a common API set (doesn't have to be 100% common, just a common core). There would still have been a need for two implementations of this API and some agreements on who does which core bits that are pure Qt code. This suggests that despite significant improvements, Nokia hasn't yet integrated the Qt way into its DNA - it's still a company that puts products first and developer platform second. (Although the Symbian side of the organisation is much more guilty of this than Maemo I have to say!)

Yes, there were many market pressures and some people were probably in a panic but still I find that sad. However, it's crying over spilt milk now. I don't really care why we got here (except that Nokia should take this back for its lessons learned).

What are we going to do about it?

Yes, we can all get more fully involved in the conversation when some alpha SDKs are available. But the information we have already is enough to throw up red flags. I hope that you also take this back internally and get people to review things.

However, there are specific things in this thread that I wouldn't want to see dismissed. For example QApplication works across so many platforms, and you can build and test code on any one of them. Why then must I build a DuiApplication? I'm not going to be at all surprised if the Symbian^4 UI framework does something similar. If there is platform specific initialisation to be done, why can't it be pushed into the private implementation of QApplication for each platform? Just because KDE does it too doesn't make it right. ;-)

Oh, and don't worry, I'm only complaining at Maemo first because they've released their code first. I'll be giving the Symbian guys even more of a hard time when I get the chance.

By SDK I also mean an environment where you can see that code in action, both providing the UI under discussion and the API to play with.

Discussion around source code only is possible but it requires similar levels of knowledge and abstraction to keep a fruitful discussion. Like now. Some people see the N900, see the N97 and conclude that there are no strong reasons to have different Maemo and Symbian optimizations on top of Qt. I bet things will be clearer when the first pre-releases come.

Having SDKs out also allow people to see how plain Qt apps integrate in both platforms with the same source code, somethng that currently you have no other choice than imagining it yourselves.

Remember the intense No Cancel Button discussion? Big deal, and yet nowadays everybody agrees it was a good decision. Ths is what I mean when I say that some discussions need something tangible to base the debate. We are discussing UI code here without having seen any actual UI.

What would be interesting feedback now would be features, widgets etc that you are missing in Qt 4.6. Specially interesting if they happen to be expected by, say, iPhone or Android developers.

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....

I think most people see that there is the need for a different UI on different devices. But the differentiation should be on the visual level. Not on the API level.
Of course there also might be the need for different APIs, but that does not mean that you should have two _completely independent_ APIs with two completely different inheritance trees.

And this was the mistake that was made back in 2005 with Hildon. I'm sure it was the "right" decision given the constraints and expectations at the time, but duplicating an API (GtkButton/HildonButton) to prevent back-end forking and maintenance of an internal version of Gtk+ meant much more work (in the form of retraining) for developers; and I'm not convinced much less work for Nokia.

Maybe C/Gtk+ wasn't the right technology to do a proper OO API; but Qt supposedly is. Indeed, the earlier Qt porting efforts did exactly this.

I don't care - in fact, I expect - to have to change the layout and content of my app for different platforms. I DO NOT WANT to have to learn 3 different APIs to put a button on screen depending on whether I'm targetting a desktop, Symbian or Maemo app.

+1