The Ultimate MeeGo Dictionary

There is quite a blizzard of very similar terms when it comes to discussing MeeGo and Qt matters, so I decided to put together a small dictionary which will hopefully clear up some terms and help follow up info on them. Don't worry if it's slightly confusing or contradictory at a first read, that's normal. Here we go, in alphabetical order:


DirectUI - see MeeGo Touch Framework

DUI - see MeeGo Touch Framework

Fremantle - see Maemo 5

Harmattan - see MeeGo-Harmattan

Harmattan UI framework - see MeeGo Touch framework

Harmattan UX - the user interface and applications of MeeGo-Harmattan. 

MADDE - Maemo(/MeeGo) Application Development and Debugging Environment, offers the following features:

• Command-line cross-compiling
• Multi-platform support (Linux (32-bit/64-bit), Windows, Mac OS X)
• Configurable for different targets & toolchains
• Client for the device to simplify the development process
• Will be used as part of future releases of the MeeGo SDK, along with QEMU, to enable cross-OS development.

Maemo - a software platform developed by Nokia for smartphones and Internet Tablets. It was initially based on the Debian Linux distribution. One of the predecessors of MeeGo, along with Moblin.

Maemo 5 - the default operating system on the Nokia N900, and current latest stable and independent version of Maemo. Based on the GTK toolkit. Aliases: Fremantle

Maemo 6 - see MeeGo-Harmattan

Maemo 6 UI framework - see MeeGo Touch framework

MeeGo - an open source, Linux project which brings together the Moblin project, headed up by Intel, and Maemo, by Nokia, into a single open source activity. Managed by the Linux Foundation. The important thing to note that you end users will mostly be using an edition of MeeGo, MeeGo itself is not a single product (that’s why "will X run/get MeeGo" is a bad question), just like people are using a Linux distributions, not Linux (as in kernel) alone. 

MeeGo Compatible - something that implements the MeeGo APIs, but is not necessarily based on MeeGo Core (for example Meego-Harmattan).

MeeGo Core 1.0 - the base of every MeeGo system (diagram), contains

• Kernel based on Linux 2.6.33
• DeviceKit and udev for interacting with hardware devices
• Modern 2D / 3D graphics stack including Kernel Mode Setting, non-root X
• Voice and data connectivity with Connman connection manager, Ofono telephony stack and BlueZ Bluetooth
• Qt 4.6
• Universal Plug and Play (gUPnP)
• Media frameworks
• Next generation file system BTRFS, as the default file system
• Does NOT contain a user interface or end-user applications !

MeeGo Garage - A client app installer in the MeeGo 1.0 Netbook release containing miscellaneous applications not part of the official MeeGo release and open for contributions from community. The name "Garage" may be changed in future releases. Ongoing community work is happening to create the official community repositories.

MeegGo Handheld - MeeGo Core + MeeGo Touch Framework + Reference Handheld UX (not yet released).

MeeGo Hardware adaptation project for the N900 - Nokia as founding member of MeeGo project is using N900 as the ARM reference platform of MeeGo at the moment. This means that we have an active project that focuses to make a MeeGo hardware adaptation for the N900. The goal of the project is thus to open as much N900 specific drivers as possible in MeeGo scope.

MeeGo Hardware adaptation project for the N8x0 - a 'skunkworks' project by the maemo.org community and others to bring MeeGo to Nokia N8x0, hence not a vendor-pushed hardware adaptation. Initially focus will be on Nokia N810. Some additional work to add support for ARMv6+VFP is also included in this.

MeeGo-Harmattan - the default operating system of the Nokia N9. Successor of Maemo 5, but based of the Qt toolkit. Originally named Maemo 6, but later rebranded as MeeGo-Harmattan (provisional name). It is MeeGo compatible (that is, has a MeeGo API) but is not to be confused with MeeGo 1.0 Handheld (as it is NOT based on MeeGo Core). MeeGo-Harmattan will not be released as a Nokia product for the N900. Aliases: Harmattan, Maemo 6.

MeeGo Netbook - MeeGo Core + Reference Netbook UX

MeeGo SDK - A software development kit for MeeGo

MeeGo Touch Framework (MTF) - provides the features needed for developers creating applications for touch-enabled devices. Features include standardized window navigation, list and other widget behavior, and common theming for components.

MeeGo Web RunTime - Web Runtime (WRT) allows web developers to use standard web languages — HTML, CSS, and JavaScript — to create applications for mobile devices. WRT exposes the features of the underlying platform so that applications can interact with device data and combine location-based context with web information.

Moblin - short for 'mobile Linux', is an open source operating system and application stack for Mobile Internet Devices (MIDs), netbooks, nettops and embedded devices. One of the predecessors of MeeGo, along with Maemo. 

Moblin 2.1 - last stable independent release of Moblin 

Moblin 2.2 - see Meego 1.0 Netbook 

Nokia Qt SDK - A custom version of the Qt SDK, which includes additional functionality for developing for Symbian/Maemo devices (with announced MeeGo support later on). These include tools for cross compiling (see MADDE) and simulation. Not to be confused with the Qt SDK as the two are not interchangeable due to a custom mix of features (neither is a a superset of the other)

Orbit - see UI Extensions for Mobile

QML - a Declarative UI tool, in effect a markup language that defines UI elements and their behavior in a declarative manner, allowing, snappy, whizzy UIs. Present in Qt4.7+

Qt - a cross-platform application and UI framework. Using Qt, you can write web-enabled applications once and deploy them across desktop, mobile and embedded operating systems without rewriting the source code.

Qt Quick - the Qt User Interface Creation Kit, which consists of QML, a specialized editor in QtCreator and all-around support for the declarative approach. Present in Qt4.7+. Aliases: Qt Declarative, Declarative UI, Bauhaus.

Qt SDK - The software development kit for the Qt framework

QtMobility - extends Qt with libraries providing additional features for applications targeting mobile platforms. These include the Service Framework and Contact and Bearer Management APIs, Messaging, Sensors, Camera, etc.


Reference Netbook UX - a reference (example) implementation of a user interface for netbooks, utilizing Moblin’s Clutter-based MX toolkit. It is expected to be replaced or augmented with manufacturer provided user interfaces/system applications on actual devices.

Reference Handheld UX - a reference (example) implementation of a user interface for handheld devices, based on the MeeGo Touch framework. It is expected to be replaced or augmented with manufacturer provided user interfaces/system applications on actual devices.

Uiemo - see UI Extensions for Mobile

UI Extensions for Mobile - an extension library for  Qt, which contains more than 50 UI elements tailored for mobile user experience. There is a proposal to use Orbit and Qt together with Direct UI as a replacement for the existing S60 'Avkon' set of UI elements in Symbian^4, but has been demonstrated to work on Maemo, too. It was previous known as Orbit before getting renamed to UI Extensions for Mobile (uiemo) and open sourced. Aliases: Uiemo, Orbit


That’s it, if you feel there is a Maemo/MeeGo/Qt term that needs clarification and is missing from the list, or that I’m wrong on a term, please leave a comment, thank you.


EDIT: This page is also present on  http://wiki.meego.com/Meegodict and will be merged into http://wiki.meego.com/Glossary (pending review and corrections).

Much Ado(be) over noth(tml5)ing ?

By now the Apple - Adobe war is in full swing and the the sides in this conflict are stating that they hold the key to the technologies for the ultimate user experience. But let us just take a peek behind the big words and statements and see what exactly is on offer here.

First, let's set up the initial positions - with the processor power and resolution of mobile devices increasing at a breakneck pace, a rich web experience has become very important to companies wanting to sell the latest & greatest gadgets. Apple has clearly pledged itself to supporting HTML5 for the rich user experience on it's platform, while Adobe (obviously) claims that 'full Flash', on mobile devices is the answer to that problem. The important thing to notice here is that both technologies are in essence desktop technologies that are expended to fit the use-case of mobile devices.

So far, most of the Apple vs Adobe dispute has been on the level of announcements, open letters, endless speculation on gadget forums, but now, the first tangibles are showing up. For a long time, full Flash (at least for 9.x) was an exclusive for Maemo devices, but with the Open Screen Project Adobe promised to bring Flash to the masses, primarily to Android, whom Adobe sees as the prime opponent to the iPhone platform. It sounds a bit like a rebound affair, as Adobe tried really hard staying within Apple's walled garden, but in the end, it became clear that it was not welcome (whether the end of the affair was more to technical or business reasons, I leave up to you to decide on).

What happened happened, Android is the newfound love for Flash, even overtaking the ultimate-flash-experience incumbent, Maemo, and promised to be included with FroYo, aka Android 2.2, with some people already testing the beta on the Nexus One. So Android gets Flash 10.1, everything gets peachy and super-hardware-accelerated, right ? Well, as usual with major shifts in technology, it's not that simple. Let's see what EXACTLY is the Flash 10.1 promise on mobile devices and if actually is what you expect from it (don't worry, I'll talk a bit about HTML5 later, too).

First of all, it's important to understand how Flash works. Just having a 10.1 in your version string will not make everything super fast and instant. Yes, Flash 10(.1) brings a plethora of generic improvements, but 'AS engine improvements' and similar just don't sound as good as 'hardware accelerated'. Does it matter, if we're getting both anyway, you ask ? Well it does, as there might be a whole lot less hardware acceleration than you think. Mobile devices are far more diverse, and peope take a lot for granted when coming from desktop environments, especially when it comes to drivers.

Phones and drivers ? What is this guy talking about ? Well, if you take a look at what the Adobe beta test page, you'll notice that there are minimum hardware requirements, software requirements, etc. I can already hear - but my device is getting FroYo, so why should I care ? Think about it this way - does the fact that your computer is getting a new OS automatically mean all the new cool games will run on it, too (and well, while we are at it) ? To take things into further perspective, notice that even the FroYo beta does not have all that hardware accel snazz - a very notable point is for example is that it does not yet have hardware enabled h264. Sure, you say, but it will come with the stable release, right ? Certainly, but are you sure that your hardware actually supports hardware functionality required for it ? Flash will fall back to the trusty software decoder (just as it does now), but the important lesson here is that Flash (like HTML5 for that matter) can only leverage hardware functionality already present. Even having h264 support on the chip or chipset manufacturer does not guarantee hardware acceleration as such hardware requires the proper drivers and middleware, and, more importantly, that the content is encoded in a profile and resolution that is supported. Before you rush off to dig in some hardware spec chart, let me say that 'most' chips support 'most' popular codecs, but that the landscape is nowhere as nearly uniform as in the X86 world - ARM chips get customized quite a bit by the actual manufacturer, so saying 'Cortex A8' does not give you anything, you have to be more specific than that. This is especially true with HD content, which is practically unmanageable without dedicated hardware support (the real question as to why you would want to play back high-end HD apart from maybe as a video out to a TV or projector is a different matter altogether).

Let us return to the story about Flash though. The already mentioned requirements page tells us about interesting things - like minimum processor speed for a given screen resolution, or operating system. For example, it says that a minimum for VGA (640x480) displays is a 550 MHz Cortex A8 (up from last year’s ARM11 requirement), and for a 800x480 resolution, an 800MHz variant is required. Surprise, surprise ! The first resolution/processor combination covers very few devices (sounds very much like the Palm Pre, but PalmOS is not on the supported list, so who knows) ? The second group is, however, more interesting. WVGA (800x480) Cortex A8 based devices ? Well, we have plenty of those by now, but curiously quite a lot of them fall just a little bit short of the requirements. For example, the Motorola Droid/Milestone only clocks it's OMAP3 to 600MHz, and the Nokia N900, another OMAP3 600MHz device misses out on the supported OS list altogether even in it’s MeeGo incarnation (even though Maemo, MeeGo’s predecessor was THE platform to go to if you needed full flash in your pocket). At this point, the notion is that all devices that Flash 10 has been demonstrated on last year are rumoured NOT get it (HTC Hero, the Nokia N900, etc). The real question thus becomes, how rigid and/or selective these requirements will be. The Droid has been promised FroYo but it's unclear whether it will NOT include Flash 10.1. What ?

This brings us to the next point - why said Flash HAS to be part of any Android build starting with 2.2 ? Supports and contains are neighbouring but vastly different terms. Will the official 2.2 Droid build it perhaps include a custom build or good ole Flash Lite instead ? Or will there a special exception be made ? Will it be available only on a hacked ROM (Milestone needs not apply) ? As you can see, Flash and it's performance is not exactly a given on any platform. Another example for this from the requirements table is the mention of Symbian S60. If you think this means your good ole S60 Nokia will suddenly get a new life, you might be expecting too much. How many Cortex A8 VGA (or, rather nHD) touting S60 phones do you know about ? Nokia doesn't make any and even with Samsung and other manufacturers included, the list of devices is real short and mostly obscure. Which brings us to the - yes, you guessed it - next point.

One of the key difference the Open Screen Project, and the latest Flash releases within it tried to address is the problem of fragmentation. A million versions of flash were a pain to upgrade, especially with the diverse hardware base mobile devices give. So one of the ideas was to be able to make Flash updatable so the content and support would not get bogged down by supporting everything they have release in the past 5 years. Cool, but there is a catch - first, who will provide the initial update to the new flash platform which will then be able to update itself ? Correct, you will have to receive it via a firmware upgrade, and considering Flash 10.1 is for most platforms still months away, until it gets released, then productized and finally pushed to end users, it will be a huge commitment for manufacturers of then-legacy devices, and I not at all sure how many of them will actually commit to it. Second - the story does not end with your device and Adobe. How will your manufacturer deal with out-of-order updates to core software ? The provider you are using can also say a word or two and/or prevent the upgrade (will the upgrade checks be filtered ? Will they cost money ? Will they ultimately require a 'go ahead' ?). A lot of uncertainty there, too.

You might be thinking I'm writing all this for pitching HTML5 and saying how it will solve all these problems - well, it won't. In fact, it will have to face exactly the same problems (just having a video tag and a HTML5 compliant browser alone sure won't make your video accelerated, ditto for fancy canvas operations). Another issue is the famous codec question (whether h264 is really free and set to be a real standard). In many ways, that reminds me of the GIF/PNG feud (for those not familiar with the matter, GIF was the widespread, but patent encumbered format, while PNG was the Free, but with limited support from major players of the time - namely Internet Explorer). Having a standard is one thing, having a standard that everybody supports and does that in a reasonable way is entirely different. On top of this, those who dissmiss Adobe often neglect that the time until HTML5 matures (which will certainly take a a year-or-two-or-three) will not be met idly - Adobe will be wanting to provide added value to the web more than ever and they will certainly be looking to find things not covered by or inherently problematic under HTML5 - we are now just at a point where the small hops of Flash and the giant jump of HTML5 happen to be in a fairly similar area.

All in all - don't worry about what device you choose, as there are no guarantees about anything at this point it's almost impossible to tell what exactly will you get with *proper* Flash 10.1 or HTML5, and whether either will be included in the ever-awaited next firmware update, or how the web itself will use and embrace these technologies - both will be staying with us for a long time, and actual ’unavailability’ will be determined by the technologies and version requirements of specific sites, not the devices themselves.