Maemo 6 and Concerns of the Community

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.

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:

DirectUI vs. DirectUI

DirectUI vs. DirectUI

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.

Solution… No:(

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!

Tags: , , , , , ,

9 Responses to “Maemo 6 and Concerns of the Community”

  1. reader says:

    Given the massive resources Nokia seems to put on all kinds of Qt related topics, maybe the (intentional?) strategy is simply “survival of the fittest”? I can imagine that not being very ideal for an application developer…

  2. timsamoff says:

    Aside from a few typos and bad English grammar (but, you’re forgiven since you’re not a Native English speaker ;) ), this was a great summary of all of the conversations that are going on. Thank you — I hope some people fom Nokia are able to find the time to read it.

    But, the downfall of being community members and not company employees (as always) is that we cannot see the heirarchical roadmap of what Nokia is planning… What we have been promised is an easier, more streamlined approach for development under Maemo 6. What we know is that Maemo is the current “flagship” operating system at Nokia. Therefore, it can probably be presumed that methods are being created to allow developers to code once for every (mobile/Maemo/Symbian) platform.

    Of course, as stated, this is just a presumtion. I wish I knew. ;)

    Still, the issue that’s always existed within Maemo — and, to some extent, every major open source project — is that there are a bunch of very smart people who think they know what’s best (for their own ends, of course). The fly in the oinment concerning Maemo is that it exists (and survives) because of corporate sponsorship. And, unfortunately, the corporate sponsor has the bigger vote in what’s “best.” We, as a community, are fortunate enough that the corporate sponsor allows us to voice opinions in the first place. But, more importantly, we are extremely lucky that they really are thiking about the best way to allow the community to develop software for their platform(s). And, let us not forget, that Maemo Devices is made up of a number of Linux developers — many who lived and developed in the open source world before going to Nokia. This may not be as “poorly planned” as everyone thinks.

    Then again… It might be. :p

  3. zchydem says:

    @reader & @timsamoff: Thank you for your comments. Sorry about the bad English grammar. I try to improve it in the future.

    @reader: It really might be that Nokia strategy is the “survival of the fittest” as you stated, but when I’m thinking of all the money and resources that are spent for that, is that really a wise strategy? I don’t know…

    @timsamoff: You have many good points there. Thank you.

    I understand that Nokia is doing business with Maemo and the community is important, but the it is not a priority #1. I guess the priority #1 is to create a mobile device for masses, sell millions of it, and only after that comes the community. The community is important because it will produce the most of the applications available for Maemo 6.

    I’m NOT saying that Nokia is treating community bad, actually I think they are doing it pretty WELL – Maemo Summits, maemo.org, pre-released devices for community members, etc. I assume, the community would be more than happy if they could be part of the Maemo development even more earlier. Community has also provided valuable information about how it feels about the things that Nokia is doing. This has probably had an effect at least at some level inside the Nokia, or if it hasn’t, then I’m disappointed. Of course you can’t please everyone, that’s a fact.

    I believe that the previous versions of Maemo (including Maemo 5) have been sort of “training lessons” for creating a linux based Maemo device and the real target is the Maemo 6. This could be one of the reasons for incompatibility between Maemo versions. I also believe that after Maemo 6, we are not going to see such a huge differences between Maemo versions, especially when it comes to the application development. It’s not a wise thing to change API too often if they want to beat other commercial app stores and keep applications available even for a new devices.

    Still I’m interesting to see how Maemo 6 and Symbian orbit/DirectUI will fit together.

    Yet, all this is just a speculation ;P

  4. Jak Crow says:

    There are huge problems with Maemo 5 that haven’t even been addressed. How can anyone even think of 6 right now? If Nokia doesn’t pull its collective head out of its collective ass and get the infrastructure running for 5 and the n900 and get some major 3rd party devs on board, no one will give a damn about 6.

  5. zchydem says:

    @Jak Crow

    Thanks for your comment. If you want, you can also raise these Maemo 5 problems here or give me a pointer to a specific discussion thread in maemo.org. I can add a link to this article also if you want. It seems that some of the Nokia people are actually reading this blog, but also creating a new topic to the Maemo TALK forum and make it active is a good way to get some publicity for the problems.

    The reason why I have started to think of Maemo 6 is that there seems to be problems also. If it is possible to raise these issues in early phase (but I think we are already late) maybe Nokia could change something before the final release.

    I think you’re right that things must work for Maemo 5 and make people to want to do development on top of that. If Nokia doesn’t get it work properly, it’s definetly not a good base for Maemo 6, but I’m also worried that the difference between Maemo 5 and Maemo 6 might be quite huge. Will the work on Maemo 5 has an effect to Maemo 6?

  6. dubik says:

    Personally I think it’s cool that there are so many frameworks and API’s. I could choose the coolest and develop software for it. Somehow people who don’t like frameworks and start arguing about fragmentation want to dominate the world with their super app (otherwise why they complain?). Come on, leave world domination to microsoft :)

    • zchydem says:

      @dubik So you like frameworks? I like those too and I’m not saying that they are bad:)

      I guess that people are mostly worried about if they want to port their plain Qt application to Maemo 6 or to Symbian DirectUI they need to create two different UIs. But personally I was surprised that Nokia will introduce two Qt based UI frameworks that are not compatible at the same time. Unless I have understood something wrong? For me this just sounds waste of resources and money.

      I can understand why there are DuiWidget based widgets in Maemo 6. If you want to create “cool” Maemo 6 applications you should build (at least) your application UI based on Dui widgets. If you’re using Maemo 6 widgets in your application then you will gain all the benefits that application framework can provide your app. Apple does the same thing in their application framework in order to “force” applications to have the same and a consistent look and feel all over the platform. Personally I think this approach ok from the perspectives of OVI Store, marketing and the future Maemo releases. Unless Nokia decides to introduce a new incompatible UI framework for Maemo 7:)

      But as I stated in this blog article, I believe there is nothing that prevents you to use plain Qt and run that application on Maemo 6.

      • dubik says:

        They didn’t seem to worry about GTK which is not compatible with anything. They don’t seem to worry about QML, QWidget, QGraphicsWidget and itemview-ng which are _already_ different. I’m not saying that having Orbit and directui is a smart move just be consistant! :)
        Nokia is big, it’s not that big deal for it to have several frameworks. When I look at N900 I see a lot of fresh ideas, comparing to 5800 or N97. So I’m really happy that maemo had to reinvent certain things which are solved for years in Symbian.

        I’m not worrying much about different frameworks. After all they are based on QT, so you can just compile DirectUI and run it on Symbian device :)
        I’m sure community will make Symbian theme. It’s easy and fun.

  7. tangential says:

    For what it’s worth, there are planned degragmentation efforts in qt. We don’t want fragmentation and duplication as much as you guys don’t.

Leave a Reply

You must be logged in to post a comment.