[svdwal]

I just visited the Maemo Summit in Amsterdam 9-11 october, and in the Maemo 6 talk it was mentioned that Maemo 6 will get a Qt-based multi-touch enabled UI, (provisionally) called Maemo 6 UI. This is apparently different from the Qt-based multi-touch enabled UI called Orbit on Symbian ^4.

So now I am wondering, why two different UI's for devices that will be very similar in functionality and target market? We had this situation for years in the Symbian world, ad it was not a good situation.

I would also like to point out that I cannot add Qt as a tag, because it is 2 characters. That's a bit silly. Qt is the name of an important Symbian technology and one should be able to tag a message with it.

[teknolog]

I think it is important to separate the concepts here.

• Qt is the underlying application framework.
• Orbit is a set of new handheld device UI controls.
• Direct UI is the new Symbian UI.

Presumably the Qt Maemo UI you are referring to is their equivalent to Direct UI.

For 3rd party developers I would assume they can use Orbit on both Maemo and Symbian, but I haven't studied this in detail. The Mobility Extensions to Qt sound like they will be cross platform too.

I raised your issue about the Qt tag as a bug.

[bdonegan]

From what I've seen of the proposals for the Maemo 6 UI (i.e. their equivalent to Direct UI), it would never work on the type of devices Symbian is intended for, so it's really for the best I think.

http://www.umpcportal.com/wp-content...ture_00078.jpg

[koshui]

AFAIK Maemo Direct UI and Orbit are two different set of widgets.
Will they ever meet, I don't know.

If you are interested you can take a look at Direct UI project on Gitorious: http://qt.gitorious.org/maemo-6-ui-framework

[teknolog]

Originally Posted by koshui

AFAIK Maemo Direct UI and Orbit are two different set of widgets

Direct UI is built using Orbit widgets, or so this Wiki page says.

[koshui]

Originally Posted by teknolog

Direct UI is built using Orbit widgets, or so this Wiki page says.

That "Direct UI" is referring to the UI concept of which implementation Orbit is.
Maemo "Direct UI" is referance to the implementation that is present in the given Gitorious repository.
Esp. pay attention to http://qt.gitorious.org/maemo-6-ui-f...er/src/widgets

Orbit implementation is not yet available.

Edit: and I'm hoping that I'm dead wrong here.

[markw]

Interesting. All the people I've spoken to about this in Nokia seemed to believe that Orbit would be common between Symbian and Maemo but they would indeed have separate versions of the UI built on top.

If the Maemo guys within Nokia have independently decided to go their own way with this, that would be a very bad thing indeed (and also surprising since Nokia wants to be able to re-use applications and services across their own platforms). However, they may just be in an advanced prototyping stage since, as koshui says, Orbit is not available yet.

I did hear that DirectUI wasn't the original name for the new Symbian UI, it was the Maemo UI, but it got mis-used in the Symbian^4 proposals publicly and now it's too late to fix - so that may be a source of confusion.

[koshui]

Originally Posted by markw

Interesting. All the people I've spoken to about this in Nokia seemed to believe that Orbit would be common between Symbian and Maemo but they would indeed have separate versions of the UI built on top.

Painters are working with big stencils. It is very difficult to see what the picture represents from street level (or is it sewers?). And even if got a glimpse i couldn't tell due to 3 familiar uppercase letters forming acronym that we've grown to love in corporate world.

I love good speculation and gossiping, so keep at it

[markw]

To be honest, the disconnect between the people putting together the high-level strategy and those implementing it is worrying, but not quite as worrying as the level of secrecy still embedded in an organisation that claims to have embraced open innovation. You can't go open source and then dump all the new code into open source just before shipping it and expect to get any benefit from it being open!

Change takes time though - so I guess we'll all just have to wait and see how it turns out over the next year or so.

[mgroeber]

Originally Posted by teknolog

I think it is important to separate the concepts here.

• Qt is the underlying application framework.
• Orbit is a set of new handheld device UI controls.
• Direct UI is the new Symbian UI.

Something that crossed my mind when reading this (very clear) description:

If Qt is a cross-platform framework, and Orbit UI controls are built using Qt, does it still make sense to call Direct UI a "Symbian UI" - in other words, in what sense is it still specific to Symbian, when it is built on a platform-indepdenent foundation? Or does this term indicate rather that its development and maintenance is for now owned by the Symbian foundation?

One thing that personally worries me a bit about this grand plan is that it might discourage a lot of incremental evolution in the Avkon space for the next year or so (since "Avkon is bound to go away anyway"), and potentially also lead to a greater disconnect between keyboard-only (still Avkon?) and touch devices.

ciao marcus

ps: I second markw's concerns about the tension between secrecy and openness, especially as it currently appears in the UI domain. But only time will tell...

[markw]

If Qt is a cross-platform framework, and Orbit UI controls are built using Qt, does it still make sense to call Direct UI a "Symbian UI" - in other words, in what sense is it still specific to Symbian, when it is built on a platform-indepdenent foundation?

DirectUI isn't just a UI, it's the replacement application suite. As has been discussed quite widely, Qt isn't currently complete from a mobile perspective. To create all the applications in S^4 a reasonable amount of Symbian C++ will still be required. As such, DirectUI will be Symbian-specific for a while yet. As I understand it, DirectUI will be contributed to the Symbian Foundation, whereas Qt and Orbit will not - we will just have a mirror of the master on Gitorious.

One thing that personally worries me a bit about this grand plan is that it might discourage a lot of incremental evolution in the Avkon space for the next year or so (since "Avkon is bound to go away anyway"), and potentially also lead to a greater disconnect between keyboard-only (still Avkon?) and touch devices.

Of course Nokia's priority has massively shifted from making a major overhaul of Avkon for Symbian^3 to re-writing the whole thing with Qt for Symbian^4. With their limited engineering resource this makes total sense. Ixonos have stepped in to make a major improvement to Symbian^3 with the single tap contribution - there's still room for others to do so.

Similarly, Symbian^4 is currently touch and hybrid only, so keypad-only devices would still have to use Symbian^3 and Avkon. Symbian^5 is supposed to resolve this but there's opportunity for earlier contributions to create a keypad-only UI for Symbian^4. In my opinion there should be a major disconnect (from a UI design perspective) between keypad-only and touch/hybrid devices. Trying to create a common UI for both, as has been attempted with Avkon, massively restricts the potential to utilize the touch-screen input. Imagine designing desktop apps to be used without a mouse or the memorization of lots of multi-key shortcuts. Third-party app developers would be well advised to consider the differences and design separate UIs for different form factors. This has been a nightmare historically because the bulk of the development effort has had to go into the UI, but with upcoming technologies like the declarative UI (QML) from Qt, this should become increasingly easy going forward.

Mark

[svdwal]

Ok, I have now asked Nokia about this officially in Forum Nokia. Not only because of the difference between Symbian^4's and Maemo 6's UI libraries, but also because on Maemo 6 they also stopped using Qt classes for everything (like QtApplication) and started usinf Dui classes like DuiApplication.

If making a difference between Symbian and Maemo versions of Qt-enabled libraries is not a bright idea, loosing Qt's single-source/multiple-deployment promise is even less bright an idea, especially because Nokia is still advertising their use of Qt as enabling ISV's to deploy on multiple platforms with a single source.

I would advise to clear this up as soon as possible as it is going to be a major PR problem for third party developer relations.

[markw]

Sander, I agree completely. Qt was a great choice of application framework and the cross-platform promise is very appealing but if they break that with separate variants on each platform then it will be a spectacular FAIL.

Of course you'll be able to run pure Qt apps on both platforms, but if they don't look like native apps because they don't use native widgets that's a big problem for many. There'd be no major problem with separate implementations of the widgets on the two platforms as long as they shared a common set of interfaces (i.e. as long as we have source compatibility - and functional compatibility, not just "it compiles on both"). However, that doesn't appear to be the case from what I've seen so far...

I was planning to blog about this on Forum Nokia and hopefully get discussion of the topic out in the open. I'll do so as soon as I have a spare hour.

[mgroeber]

Originally Posted by markw

Of course you'll be able to run pure Qt apps on both platforms, but if they don't look like native apps because they don't use native widgets that's a big problem for many. There'd be no major problem with separate implementations of the widgets on the two platforms as long as they shared a common set of interfaces (i.e. as long as we have source compatibility - and functional compatibility, not just "it compiles on both"). However, that doesn't appear to be the case from what I've seen so far...

What also worries me in this is the precedent set by the CEik.../CAkn... design split in the S60 UI: from the perspective of an outside developer, this also started out based on the relatively generic, abstract Eikon classes, which even include some amounts of geometry and layout management. However, the top-level Avkon widgets for implementing the S60 look&feel turned out to introduce a large number of "convenience methods" and "helper classes" that had very little to do with the original design of the base classes.

As an example, compare implementing a tabbed settings dialog using S60 UI and the original CEikDialog, or the way how semi-documented architectural innovations like MObjectProvider turned up that you just had to do some cut&paste magic with from sample code in order to get skins to display right. As an exercise, count the number of undocumented "public" methods in the S60 UI vs. those in the Eikon UI.

Of course, some of this is to be expected as you get to more specialized classes, but Avkon always felt to me like "we'll need to make this work" rather than "we're building a solid foundation for application developers".

In order words, I am skeptical about Nokia's ability to get the design of "one set of mobile widgets on top of another" right when faced with the competing pressure of getting a device with Symbian^4 out in time for whatever deadline has been set. On the other hand, given the amount of code in that contribution, and the momentum behind it, once the first version of the API has been published, there is likely going to be little time for the rest of the community to get involved, in case Direct UI becomes another Avkon...

ciao marcus

ps: After posting this, I remembered why I probably feel so strongly about this - I have seen Nokia do this once before, with the FOAM layer on top of the GEOS operating system for the 9000/9110 Communicator series: GEOS also started out with a very elegant abstracted set of geometry-managed UI classes that were intended to be flexible across screen resolutions and input methods, and skinnable in a way that had some parallels to Java Swing, but several years earlier.

However, the implementation on the Nokia 9000/9110 put a layer (FOAM) on top to achieve the Communicator UI by cutting through most of the underlying concepts and introducing very task-specific classes and helper functions which clearly did not preserve the "spirit" of the underlying design, and thus included many ad-hoc extensions that could only be guessed from code samples. Of course, preserving the cross-device nature of GEOS was not an explicit goal here, but this was perhaps the first example that release cycles of mobile phones and UI innovation do not get along well.

[teknolog]

The comforting thing here is that Nokia now has the Qt people, who have been designing frameworks for years.

[markw]

The comforting thing here is that Nokia now has the Qt people, who have been designing frameworks for years.

Comforting only if they're in charge of the APIs. Orbit and DirectUI are not being written by the trolls.

From my intelligence gathering so far it seems that Qt Development Frameworks are reduced to trying to make pure Qt apps capable of looking like native apps, whatever extensions are built on top - they're trying to do the same thing with KDE too. For KDE, it would seem to make sense to improve the look of pure Qt apps on the externally controlled desktop as far as possilbe. However, this is not the way to go when you control both platforms.

Marcus is right, Nokia do have a history of screwing this up by creating a framework (or multiple frameworks) that are essentialy designed for building devices rather than for developers to write apps. However, the reason it looks like a particularly bad choice this time is that they aren't building one set of widgets on top of another, it appears that they're building two completely new sets of widgets, one for each platform.

This leaves developers with the choice to build very different versions of the app for each platform (much like the old S60/UIQ days) or ignore the device UIs and use pure Qt, but then have to create their own widget set. Lets hope this isn't the case and there's actually some master plan in place to resolve it all!

[svdwal]

Originally Posted by markw

Comforting only if they're in charge of the APIs. Orbit and DirectUI are not being written by the trolls.

From my intelligence gathering so far it seems that Qt Development Frameworks are reduced to trying to make pure Qt apps capable of looking like native apps, whatever extensions are built on top - they're trying to do the same thing with KDE too. For KDE, it would seem to make sense to improve the look of pure Qt apps on the externally controlled desktop as far as possilbe. However, this is not the way to go when you control both platforms.

From what I heard is that the Q classes are what in Pattern Speak is a Bridge, i.e a set of device-independent abstractions that point to and are implemented in terms of device-specific classes. If that is indeed the case (it looks like it is, but the Qt sources are big), then you do not build system-specific classes on top of Qt, you add them as one of the implementations. Even if these implementations are also implemented in Qt itself (using lower level classes), you do not expose them.

Marcus is right, Nokia do have a history of screwing this up by creating a framework (or multiple frameworks) that are essentialy designed for building devices rather than for developers to write apps. However, the reason it looks like a particularly bad choice this time is that they aren't building one set of widgets on top of another, it appears that they're building two completely new sets of widgets, one for each platform.

Now you got me really scared. Making a mistake once, nobody is perfect. Making the same mistake twice, that's bad. Making the same mistake thrice, oh boy. I bet Steve J. is laughing his head off.

This leaves developers with the choice to build very different versions of the app for each platform (much like the old S60/UIQ days) or ignore the device UIs and use pure Qt, but then have to create their own widget set. Lets hope this isn't the case and there's actually some master plan in place to resolve it all!

Well, one of the good things of using open source is that it is possible to fix the mistakes of the creator. Luckily the number of widgets needed is not very big, and implementations are available, the only thing we need to do is to create Adaptors that conform to the standard QWidget interface, and implement them in terms of either Orbit or Direct UI classes. At least, this works as long as thei do not put stuff in QApplication, QWindow or other such high-level classes, because then we are screwed.

Another good thing about both Maemo and Symbian ^4 being Open Source is that people can now see for themselves what engineering mess Nokia is making of a perfectly good platform. The Android fanbois are going to run and run with it. If that is not going to kill their developer credibility, nothing will.

[teknolog]

Thanks for all the valuable questions. I'll definitely bring points from this conversation to our Qt delivery meetings to try to gain some insight into what the plan is and how we can mitigate these potential issues.

[markw]

From what I heard is that the Q classes are what in Pattern Speak is a Bridge, i.e a set of device-independent abstractions that point to and are implemented in terms of device-specific classes.

This is not the case for the GUI classes, Qt emulates the style of the native platform widgets rather than providing an abstract wrapper around them. They basically try to use QStyles to create near pixel-perfect copies on whatever rendering back-end you choose - it's faster and less buggy that way.

Making a mistake once, nobody is perfect. Making the same mistake twice, that's bad.

I'm not sure it was really a mistake historically, 3rd party developers just weren't anywhere near as important as getting devices out quickly. The landscape has changed though. Buying Qt was a great solution... I just hope everyone is on the same page about the new priorities.

I'd agree with the rest of the post except:

the only thing we need to do is to create Adaptors that conform to the standard QWidget interface

QWidget is the old way. The standard QWidgets work in Qt for Symbian now but they create UIs that look like Avkon and traditional desktop apps on other platforms. I assume there will be some modifications to the style on Symbian^4 onwards to keep the general look and feel consistent if they are used, but Orbit is supposed to include a collection of QGraphicsWidgets, as is the Maemo UI I beleive. The Graphics View architecture and animation framework are what the new UI will be built on, to be replaced with a declarative UI (QML) built on top of that in Symbian^5 (current plan anyway I understand).

[petteri]

I think it has been clear thing at least to me quite long time that Maemo and Symbian are taking separate routes here with their Qt story. Symbian is talking about Orbit and Maemo is talking about Direct UI and their "own widgets". This is breaking the cross platform story once again. Should there be more discussion between Symbian and Maemo?

[markw]

Should there be more discussion between Symbian and Maemo?

Yes! Absolutely that is the problem. They should have agreed some common interfaces for app development at the beginning and gone off to implement their own back ends. Now they need to refactor to a common interface.

What I really don't understand is that Nokia's services strategy is based around being able to deliver common applications and services efficiently across both platforms. Why doesn't someone have more control over the output of these teams?