Maemo community members have expressed their concern of Maemo 6 UI Framework and Nokia strategy related on code compatibility and differences between Maemo 6 and Symbian DirectUI/Orbit frameworks. There are at least two threads in maemo.org and one thread in symbian.org that have ongoing discussion of these topics. You can check them from the links below. Please, let me know if you know more threads related on this topic and feel free to comment if you disagree on someting.
- Maemo.org: Maemo 6 loosing source compatibility
- Maemo.org: Nokia lacks strategic planning?
- Symbian.org: Why Orbit, when Maemo 6 will also have a new UI
I think some of the community members have made a good a point in the discussions and some of the comments are irrelevant. My point here is that there are seeds of truth in these threads. What is this article for then? I decided to write little bit about this topic, refer to some of the comments in those threads and raise couple of issues that should be taken into consideration.
Nokia Way of Doing Things…
There are many comparisons made between Maemo devices (N900), iPhone and Android phones. First of all, I think what Nokia does with Maemo is bit different and I’m not sure if these stated comparisons are really justified. For example, Nokia tries to do the development more open than Apple/iPhone or Android devices are done. Nokia uses pretty much open source components and is doing development to the upstream for example tracker development. I see that releasing technical previews of Maemo 6 UI Framework and Home Screen is a positive gesture of trying to be more open towards the Maemo community. Even though, I think they were bit surprised of the feedback that my “Peek to Maemo 6 UI Framework” articles caused (discussion in the community). I’d also like to see Nokia to develop these Maemo 6 components to the upstream, not just release some snapshots every now and then. But in the end, they are trying to be more open.
Of course, it would be nice to see more community members participating on the Maemo development from the very beginning. This way they would be able to raise issues that may cause any problems in the future. This is one of the reasons why I’m writing this article now.
Maemo 6 UI Framework vs. Orbit / DirectUI vs. Qt
One of the biggest issues in the Maemo 6 loosing source compatibility and Why Orbit, when Maemo 6 will also have a new UI threads have been the discussion of why Nokia will provide two Qt based frameworks (Maemo DirectUI and Symbian DirectUI / Orbit) and incompatibility between them. More information about Orbit you can found from the following links:
In my opinion, the community has a point. (Check Mark Wilcox post.) If you read the Orbit Technical Solution Description, you might notice that these both DirectUIs are based on Qt Graphics View, but according the discussion in the “Why Orbit, when Maemo 6 will also have a new UI” thread, it seems that these two frameworks have nothing to do with each others. I see this scenario something like as presented in the diagram below:
I’m not sure if this diagram is 100% correct, but let me explain little bit what I’m trying to say with it. Both frameworks are based on Qt framework. On top of Qt there is a bunch of widgets. In Symbian there are HbWidgets and in Maemo there are DuiWidgets. Both widget types are based on Qt Graphics View framework. I don’t know details of how HbWidgets are constructed e.g. do they use something similar than Dui’s MVC model uses, but based on naming conventions, I believe that HbWidgets and DuiWidgets are not compatible. There are also two different DirectUIs. As far as I know both act here as an application framework i.e. they provide some services, notifications, window management etc. These DirectUIs use widgets e.g. for constructing a home screen and so on.
If you want to write an application that is number one citizen in one of the platforms, you are forced to build the application on top of the widget sets that application framework of that platform provides. In Maemo that means that your application must be based on DuiWidgets and in Symbian it must be based on HbWidgets. If you want to port your Maemo 6 application to the Symbian, then you will need to rewrite your UI code.
An interesting point here is that actually this model shows the portability of Qt. If you have a QWidget and QApplication based application, it can be ported to the both platforms without a need to rewrite basically anything. The reason for this is, it is based on Qt Framework, not on Symbian or on Maemo DirectUIs and therefore it’s still runnable in both platforms, if you have implemented it correctly from the beginning. Of course if you want to make it to Symbian or Maemo widget based application then you need to rewrite the UI part. There might be some issues (e.g. localization) that may require you to make your application to use DuiApplication. Check this post from Tomas Junnonen.
One solution to avoid, at least, the compatibility problems between Maemo and Symbian is that these both frameworks could have been based on the same code base. Only thing that is different is the underlying Qt and probably the window management code. As I stated earlier, I don’t know much about Symbian world, so I’m not sure of how things should be implemented in the Symbian side. With my knowledge of Qt and of building UI frameworks, I don’t see there any technical reasons why this is not possible to implement.
But as someone stated in one of the threads, a reason for this double framework thingy is that there might be some internal competition in Nokia. Nokia is a large company – do they always know what is happening in some other department? I don’t know, I’m not a Nokian:) I also believe that, at this point it is too late to start to think how to combine these two frameworks (unless they have started to do that in the very beginning) and to start to do any work on that.
Qt Source Compatibility
Qt source compatibility was the one of the hot subjects that started the discussion originally. The community members were worried about Maemo 6 UI Framework will break the whole idea of Qt – Code once, use everywhere. I guess they are right, partially. One of the key ideas of Qt is that you write your application once and after that you can use it on different platforms. The only thing that is required, is that you just recompile your application. In most cases this works out-of-box.
The biggest issue with Maemo 6 and Qt compatibility is that QWidget based applications are sort of second class citizens in Maemo 6 platform and DuiWidget based applications are number one citizens. I can understand why Maemo 6 is based on QGraphicsView and QGraphicsWidgets – basically because Graphics View provides an easy way to do animations, transformations and even 3D without forgetting OpenGL rendering. Another thing is that Nokia wants to provide a ready made set of widgets that can easily to be used to build your application. You gain the look and feel for free when using DuiWidgets. Also in the future, there will be a QML – the declarative UI which is quite strongly bound on QGraphicsView. (I know that the declarative UI has already been released, but I’m not sure if Maemo 6 will support it.)
Community is still worried about how existing Qt applications can be easily ported to Maemo 6. I guess there is no reason why you shouldn’t be able to run QApplication and QWidget based applications on Maemo 6 device (see the previous chapter). There is Qt, so just compile your app. I believe that there will be Maemo 6 QStyle that makes the general look and feel as close as possible to Maemo 6 style, but the down side is that you don’t probably get those cool stuff that comes from QGraphicsView. I also believe that there will be somekind of mechanism to handle plain Qt application menu items in a similar manner than it’s done in previous Maemo Qt ports, thanks to Antonio.
Possible Solution… No:(
Some time ago I ran into a project called itemviews-ng. The idea of itemviews-ng is to provide QGraphicsView based solution for Qt’s Model View mechanism. I also noticed from the discussion that they are planning to move all QWidget based widgets to run on QGraphicsView at some point. Project itemviews-ng uses MVC model, but it differs quite much from a DUI’s MVC model. I guess the biggest issue here is that in DUI the controller object is in the scene, but in itemviews-ng the view object is in the scene. So I guess, if Qt will introduce a new QGraphicsView based implementation for QWidgets, they will not be compatible with DuiWidget based widgets. Still here I suggest, that if you want to code once – use everywhere, do it based on QWidget:)
OVI Store and Applications
Community has also expressed their concern of OVI Store and the amount of the applications for the Maemo devices. Related on the previous chapter about rewriting an application each time when a new Maemo device is being introduced, is one of the reason for this. For example when N900 was introduced there were only few applications provided by the community. Main reason for this was the new API and the lack of devices (of course Maemo summit fixed this problem little bit). But here we will get to the next problem: how many applications there will be available when the Maemo 6 device is out for public? This is not a problem for nerds, but mainstream users will want to have plenty of applications available from day 1.
When talking about the Maemo and OVI store, they will always be compared to iTunes and iPhone. Android is also compared to Nokia devices and the amount of available applications for it. I believe this will be one of the challenges that Nokia must able to solve somehow. The community could help here in a similar manner than it did with pre-released N900s, but only after Maemo 6 device has been released. I really wish to see that they don’t break the API or provide a new framework for Maemo 7 device:)
Reinventing a Wheel?
As you might have noticed from this article, the Maemo community hasn’t been worried for nothing. I have a one more thing to worry more. For me, it seems that there are several different projects doing almost same kind of things. Good examples are:
- DuiLayout & DuiLayoutPolicies vs. Qt Kinetic’s Animated layouts
- Maemo 6 Service Framework in Dui vs. Qt Mobility Service Framework
- Dui MVC model vs. itemviews-ng MVC model
- Maemo 6 UI Framework vs. Symbian Orbit / Direct UI
This makes me wonder that are the goals of Maemo and Symbian organizations and Qt Software so different that they must end up to have different solutions? Could there be a common solution which is usable for all? Why for example Dui MVC model needs to have controller in scene, but itemviews-ng must have a view object in scene? I don’t know which way is better, but I guess after little thinking there could be a solution that suites well for all.
Addition: Maemo as a platform will probably update Qt version every time when a new Qt version is released or even before that. This means that when Qt will have animated layouts, then there will be two different animated layouts available on Maemo plaftorm. When/if Qt will release itemviews-ng project as a part of the Qt master branch, then there will be two (or three) different MVC models on Maemo platform. This is due the fact that Qt must continue its existence as a product and Maemo 6 UI and Symbian DirectUI / Orbit frameworks are based on that product. In my opinion this is not a very good strategy. Instead this kind of basic functionality should come only from Qt, not from any framework built on top of Qt.
For me, these kind of strategies mean that there are resources (people) that are doing almost “identical” things but they have different goals. If these resources would have the same goal, it means that things are going to be ready sooner. ( I know that increasing amount of people doesn’t make software to be ready faster, but I guess you’ve got my point).
After all I believe there is room for improvement when it’s coming to the strategy in general. This is also stated by community quite strongly in many cases. I hope that you liked this article. Let’s see, what I’m gonna write next. Happy New Year for You!