Skip to content

MeeGo Thoughts

Now I have digested an idea of MeeGo for few days, I decided to take a look at it little closer and write a small article about it. The reason for writing this article is to self educate myself and trying to solve what MeeGo really is. Note that this is not a review of the MeeGo platform.  A good starting point for doing this study is the online information that Nokia and Intel has provided. I have used the following material as a bases of this article:


It is a merge of Maemo 6 and Mobilin 2 – it takes the best pieces of the both platform and combines them into a one called MeeGo. MeeGo is fully open, cross-platform and it targets not only to mobile devices, but to netbooks, automotive and basically to any hardware. This means that MeeGo platform is available for any device manufacturers or network operators and for developers of course.

Yet, a one important thing to mention is that MeeGo is a project that is hosted by Linux Foundation. As a Qt developer, I of course want to mention here, that the default UI toolkit for MeeGo is Qt. As NOKIA advertises it, code once and use everywhere. I hope that this is what we really get this time.


I know most of you already are aware of what MeeGo is, but I want to go little bit deeper here. All the”sales talks” saying that MeeGo is a merge of Maemo (6) and Moblin doesn’t say much. Basically MeeGo could be something like the RdUX that I wrote last time. RdUX runs on Moblin Core 2.0 based device and it’s built on top of Qt so there are components from Moblin and from Maemo. Isn’t that a MeeGo application then? I don’t know. To get better understanding of MeeGo, I will go through little bit architecture and I’m trying to understand how it will be built.

I linked the architecture diagram above from and from there you can find all the explanations for the boxes in the diagram. I am mostly interested in about the MIDDLEWARE and UX layers, not so much about OS BASE layer. Therefore I start from the bottom and I will go quickly through the OS BASE layer.

One comment about the MeeGo architecture is that it follows a layered architecture model. In that model a layer “X” can only depend on other layer “Y”, if and only if, the layer “Y” is below the “X” layer. For example the UX layer depends on MIDDLEWARE, but MIDDLEWARE can’t have a dependency to UX.


OS BASE layer consists of HW Adaptation Software e.g. software components that vendors must provide e.g. drivers and patches in order to make their HW to work on the platform. The kernel is a kernel from which is configured to that specific platform.


MIDDLEWARE layer provides bunch of services: Comms, Internet, Visual, Media, Data Management, Device Service and Personal Services. It doesn’t make sense much for me to re-explain these components here because you can read the official descriptions from MeeGo Architecture page. The documentation page doesn’t explain  what is the exact “subsystem” which is used e.g. for Media Services or Data Management. Maybe this is a detail that they don’t want to reveal yet.

I guess what these boxes could contain for example GStreamer for Media Services and Tracker/libQtTracker for Data Management. I believe that Qt Mobility will be part of this MIDDLEWARE layer, because it provides APIs for Bearer Management, Contacts, Location, Messaging, Multimedia, Publish and Subscribe, Service Framework and System Information.

The MeeGo architecture document didn’t say anything about the interfaces of the MIDDLEWARE, but I believe that most of the services use dbus for providing an interface or a “wrapper” built on top of dbus such as Qt Mobility’s Service Framework. But this is just a guess.

The most interesting component in my point of view is of course the MeeGo UI Toolkit aka Qt. MeeGo also provides GTK / Clutter to satisfy old GTK developers and this way “Nokia” can continue to support the old legacy code. I know this comment may have pissed off many GTK developers, but the fact is that Qt is the main toolkit and GTK comes after that.

If I have understood right, the Moblin Core applications are mostly based on GTK/Gnome applications, so I guess GTK is not there just to support old Maemo apps. So if you want to develop applications for MeeGo, you can just create a new Qt application or just to reuse your old Qt application and it should work on MeeGo platform.


User eXperience is the layer that provides a device specific user experience. This means that depending on your hardware for example a type of the display, the UX varies – it may have a single or multitouch display or a non-touchscreen display. This means that each device type (handheld, netbook, automotive, etc), may provide different kind of user experiences. For example Maemo 6 device user experience might be a bit different compared to NetBook user experience. Btw, it will be interesting to see if Nokia will release a MeeGo image for Nokia Booklet at some point.

According the MeeGo architecture documentation: “The MeeGo handheld UX provides a user experience for handheld devices, including the core system user interface and applications which are built on a handheld optimized UI framework.” For me this is a bit vague here. Does this mean something like Maemo 6 UI Framework or Uiemo for handhelds and Moblin UI for Netbooks?

If, it means something like that then MeeGo doesn’t solve the problem that Maemo Community has raised about the code compatibility. With this I mean that if you have a plain Qt application like the one in the example: “Create a basic MeeGo Application“, is it really a MeeGo application in that sense, that it will also get all the benefits that UX layer provides or do you need to build an application that is based on the UX layer API? If the latter one is the case, I guess then we have the same problem that we had with Maemo 6.

Well anyway it will be nice to see something concrete here at some point.


In the beginning of this article I mentioned that one of the references for this article is “Nokia Software Strategy” document describes bit better what MeeGo is and what it contains. See the diagram below:

From this diagram  you can see where the business is in all this (in my opinion). This diagram shows what layers are open and what are closed. Nokia and other service providers can provide APIs so that application developers can use services via those.  If I interpret this diagram correctly the the API can be used by app developer but the source code for the API is not public.

Hardware may also be private. I understand this so that hardware manufacturer may provide a HW with private specs, but in order to make it work in the MeeGo platform, the manufacturer must provide required drivers. I may have understood this completely wrong also.


Nokia has put lot of effort to develop Qt WebKit based Web RunTime (WRT). With WRT you can develop MeeGo applications using web tools and techniques (HTML, CSS, JavaScript and Ajax), but you can access to the platform services via JavaScript. Examples of these services are phonebook, location (GPS) and Ovi. Usually it’s faster to create applications using this kind of approach which of course means that there will be more applications available for devices in shorter time. In my opinion this is just a way it should be done because as you can see from the Ovi, there isn’t too much applications for N900 also compared to some Nokia competitors.


Hybrid development is the future, at least I think so. Hybrid application means that you can combine C++ and WRT into a same application. With hybrid development you can create applications faster. I consider Qt Quick as a one technique to create hybrid applications e.g you can create the business logic in C++ and the UI components are created in QML files by graphics designer. Also you can use JavaScript from the QML files so I don’t see there any reasons why Qt Quick application would not be a hybrid application.

Why this makes application development faster then? The business logic implemented in C++ can basically stay same in all the platforms or devices, but the UI components can vary between devices. As you might have noticed Qt Quick is pretty neat tool for this – you can develop new UIs fast without need to know C++.


As I stated earlier, MeeGo project is hosted by Linux Foundation. Linux Foundation hosts the Moblin project so it is quite natural that it will continue hosting the MeeGo project. One of the main goals of Linux Foundation is to “spread the word of Linux”. With this collaboration scenario where Intel and Nokia join their forces, the Linux Foundation can be sure that in a short future there will be millions of devices that run Linux. I think one of the reasons why Linux Foundation is there is that this kind of political decision makes especially Nokia to look better in the front of open source world. But in anyway this is a good news for software openness.


As you probably know, oFono project is an open source project for developing an open source telephony solution. This project has been started by Intel and Nokia some time ago. When I was trying to search information about oFono, there wasn’t much new information around so it is quite hard to say will oFono be part of the MeeGo platform.


It is not so clear for me what is the motivation behind MeeGo when it comes to the business. This chapter is just my speculations about the business behind the MeeGo so please feel free to comment if I’m on a wrong track. The following business motivations are not in a specific order.

Services like Ovi is probably one of the biggest reason to make MeeGo platform open. As I showed in the diagram above Nokia will provide Ovi APIs and APIs for other services. For an application developer this is a possibility to build an application which uses these APIs. In a business side this means that there will be more MeeGo applications that are using different services i.e. more customers for online services.

By making MeeGo platform available to all, including device manufacturers, means that there will be not just Nokia devices, but Intel devices, Qualcomm devices and probably devices from other manufacturers. From the service point of view this means that there will be more users for services, again. Also making MeeGo available not just for handhelds or netbooks, but for TV, automotive and for set-top-boxes (basically for anything that can run linux), I believe that this can be a success, because the same application can be ran by each of these device. At least this is how I have understood it.

I understand the motivation of Intel to get together with Nokia. I haven’t seen too many mobile devices that contain Intel chipsets. LG GW990 is actually the first one that I’ve seen, but I must admit that I haven’t followed Intel too closely. Intel has a quite good position in a Netbook side and therefore I believe that most of the MeeGo Netbook UX comes from Intel camp. For Intel mobile devices is a pretty new area (I guess), but for them this means that in the future there will be more devices with Intel chipsets. In other words more business for Intel.

In the platform side MeeGo means that it takes advantage of community resources. I know this sounds bad, but that is not bad at all. With this I mean that because it will be fully open, there are more developers that can develop the platform. Sometimes big companies might have fixations how things must be done, but making the platform open should open the minds and eyes also. There will probably be more fresh ideas how things can be done, like in the linux world – many open source ideas have been later deployed by commercial applications.

Having more developers involved in MeeGO, also means that the maintenance is sort of “out sourced” for free or at least for cheaper than in a traditional model. I know this sounds bad also, but that’s not bad at all. I think the open source community is usually more motivated to do work on a areas that they really want to work. On the other hands I’m not sure how all this fits on hard requirements in industrial side for example the implementing unittests for software and making the coverage high enough.


One thing came to my mind is that MeeGo seems to rely on X Server in each platform. Could it possible to have a device that is using just framebuffer because there is Qt Embedded which makes possible to run Qt applications without X? In some cases X just brings more overhead and the UX layer like window management can be implemented on top of Qt Embedded because it provides tools (QWServer,..etc) for that? From application developer’s point of view this doesn’t effect on your application code much, unless you have used X11 specific functions in your application.

In general, the idea of MeeGo sounds good for me. I think it will take some time before we’ll see what kind of form MeeGo will get. The architecture of MeeGo is quite high-level atm and basically it can contain almost anything inside those top level domains. In my opinion the direction is right especially when it comes to the software openness. I’m really interested in to see where all this will go.

That’s all folks. Thanks for reading my blog.

Marko Mattila on sabtwitterMarko Mattila on sabinstagramMarko Mattila on sabgoogleMarko Mattila on sabflickr
Marko Mattila
Marko Mattila is a nerd, father, husband, snowboarder, photographer, mountain biker, runner and I love open source.

This is a blog, where I share my thoughts about technology or sometimes about life in general.
Published inMaemoMeeGoQt


  1. saikoushik saikoushik

    hi ,
    in above you said some examples for WRT like phonebook ,location and ovi , can you please help me by providing links to the above examples source-code , and i am newbie to WRT and web apps , it will be helpful to me and i will make reference of those apps

  2. zchydem zchydem


    Yes, I mention those as examples of the services that you can use via WRT. I didn’t mean that there are source code examples. I guess the best way to get familiar with MeeGo is to follow what happens in gitorious: I’m sorry that I couldn’t point you any real examples.

  3. lapnd lapnd

    Hi Zchydem,
    Thank for your information.
    I’m thinking about your first paragraph of your conclusion. As we know, for embedded devices with limited resource capacities, it is not good solution when build GUI based on X11.For this kind of devices, if we want to port Meego on them, I think we need eliminate X11 and then build our UX from scratch by using QT embedded.
    1. To build our UX from For Meego (use QT embedded). Based on requirements of UI by ourself,I think it’s ok
    2. To eliminate X11 from Meego. I checked Meego source code core, I found that around 8% packages related to X11 directly.Do you think it is hard work to eliminate X11?

    • zchydem zchydem

      Hi lapnd! Good thing about MeeGo is that you can always take it, modify it to your purposes and use it. Afaik, the X11 is only needed by UX layer which can be replaced by your own UX layer implementation. To be honest, MeeGoTouch is too heavy for doing anything sensible and therefore it I highly recommended to throw it away and replace it with something better.

      Actually I’m working atm in project where we have done it. Another thing which is interesting, is to see how Wayland ( could provide an alternative for X11. I’m not a Wayland expert and haven’t done anything on top of it, but it’s certainly something to worth to think about.

  4. lapnd lapnd

    Hi Zchydem! Thank for your comments.
    I’m sorry for trouble you again.
    Could you please help me to understand one more thing about UX layer of Meego?
    As we know, UX layer includes 2 parts:
    – UI framework ( Netbook UI framework, Handset UI framework, IVI UI framework)
    – Applications
    I’m confusing about UI framework and Applications. In my understanding:
    – UI framework is the GUI part is displayed when start up for end-user such as pannel, homescreen,taskbar.
    – Applications are some application such as chatting,web-browser, calculator,open-offices…
    Is my understanding correct?

Leave a Reply

Your email address will not be published. Required fields are marked *