tag:blogger.com,1999:blog-60923133055778569472024-03-16T19:49:51.870+01:00The penguin movesRandom musings on embedded/mobile linux platforms and Free/Commercial ecosystems built around them.Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-6092313305577856947.post-60840653987738182372014-12-22T18:00:00.000+01:002014-12-22T18:37:33.723+01:00Meteor and Qt: match made in heaven<div dir="ltr" style="text-align: left;" trbidi="on">
Meteor, say hello to cross-platform native app-development. Qt, say hello to a modern, reactive web back-end.<br />
<br />
<b>TL;DR You can write a native Qt / QML app and have Meteor as the back-end for <i>real-time</i> data distribution and remote procedures.</b><br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjg6e4FDug4NGMgisDBwNNBxq14PGkKcF1DRNchSfLlkS1ZIVZh2fsvSQ0IzcVP3r8LtvOoRHOCxQ1PqEjEMJAaaXwi0yPLjBAqjEIAAgL-ayrE5uyCVxZ1CdDnfuiwjt9nk_dGP1gMtqk/s1600/qondrite.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjg6e4FDug4NGMgisDBwNNBxq14PGkKcF1DRNchSfLlkS1ZIVZh2fsvSQ0IzcVP3r8LtvOoRHOCxQ1PqEjEMJAaaXwi0yPLjBAqjEIAAgL-ayrE5uyCVxZ1CdDnfuiwjt9nk_dGP1gMtqk/s1600/qondrite.png" height="180" width="320" /></a></div>
<div>
<br /></div>
I've been looking at recent developments and since <a href="https://www.meteor.com/blog/2014/10/28/meteor-1-0" target="_blank">Meteor had it's 1.0 release</a> recently, decided to take it for a spin... with Qt.<br />
<br />
For those that have been living under a rock, <a href="https://www.meteor.com/" target="_blank">Meteor </a>is a <a href="http://node.js/">node.js</a> based web framework that can be used to create modern, responsive web apps. It does have Cordova/Phonegap support, so you can package your website as an app and deploy to Android or iOS, but obviously that leaves you short when it comes to truly native look and feel, performance, and full range of APIs.<br />
<br />
<a href="http://www.qt.io/" target="_blank">Qt </a>on the other hand is a native cross-platform application development platform and has an excellent track record when it comes to the sheer number of <a href="http://doc-snapshot.qt-project.org/qt5-5.4/supported-platforms.html" target="_blank">supported native platforms</a>. It does have some server/cloud oriented functionality and services (see engin.io and <a href="https://qtcloudservices.com/">https://qtcloudservices.com/</a> in general), but it's hard to beat the popularity and ecosystem (and therefore development speed) happening around Meteor.<br />
<br />
Can we make this a match? Meteor for web and server-side, and Qt/QML for making snappy native applications that go beyond calling RESTful APIs and polling on one side, and packaging node.js and phonegap API/performance limitations on the other?<br />
<br />
The answer is luckily yes - what makes Meteor so uniquely well positioned for this is it's <a href="https://meteorhacks.com/introduction-to-ddp.html" target="_blank">Data Distribution Protocol</a>, or DDP for short. It's a websocket-based channel where Meteor sends JSON messages to the clients. There is nothing special about this, so we can have a Qt client (turns out there is already a healthy list of <a href="http://meteorpedia.com/read/DDP_Clients" target="_blank">DDP clients/libs</a>, but none C++ or Qt-oriented).<br />
<br />
Enter <a href="https://github.com/achipa/qondrite" target="_blank">Qondrite</a>, a lightweight QML wrapper for <a href="https://github.com/mondora/asteroid" target="_blank">Asteroid</a>, a Javascript client for Meteor. With Qondrite, you can use Meteor as the source of your models (yes, everything shown goes through models, not hardcoded lists and data). To check the feasibility, I took the Todo example from Meteor (meteor create --example todos) and used Qondrite to interface to the meteor application. As usual, the <a href="https://github.com/achipa/outqross_blog/tree/master/3_OutQross.Meteor_demo" target="_blank">source of this demo</a> is available on github.<br />
<br />
The end result?<br />
<br />
<br />
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/A9KqDrqYRsc?feature=player_embedded' frameborder='0'></iframe><br />
<div>
<br /></div>
As promised, an integrated Meteor-Qt stack, with a whole lot of opportunity to take the idea even furher. For example, there is no reason why we couldn't send QML instead of Meteor's Blaze HTML templates, making fully dynamic UIs for <i>native </i>applications - how awesome would that be?<br />
<br />
This makes Meteor super-well suited for multiplayer games, chat applications and any type of app that benefit from a scalable, client-agnostic back-end, and low-latency, high-performance on the client side.<br />
<br />
Feel free to discuss at <a href="https://news.ycombinator.com/item?id=8783879" target="_blank">Hacker news</a> or on <a href="https://groups.google.com/forum/#!forum/meteor-talk" target="_blank">meteor-talk</a> !<br />
<br /></div>
Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com1tag:blogger.com,1999:blog-6092313305577856947.post-72915064166813324972014-11-24T18:00:00.000+01:002014-11-24T18:04:16.276+01:00QML wrappers for native Android components<div dir="ltr" style="text-align: left;" trbidi="on">
TL;DR It might be simpler than you think to wrap native UIs with the QtQml module, but it does require a good understanding of the underlying platform<br />
<br />
In my <a href="http://achipa.blogspot.com/2014/11/native-ui-in-qt-on-android-without.html" target="_blank">previous post</a>, I showed how you can work with platform-native classes and use the QtAndroidExtras module to create UIs from code. One of the downsides was the extra code complexity you had to manage. The "Qt way" of doing UIs is, however, by using QML, for the reasons of brevity, development speed and flexibility. I cobbled together a custom Android component module to demonstrate this (<a href="https://github.com/achipa/outqross_blog" target="_blank">sources available</a> on GitHub) - the 40+ thick line C++ UI example suddenly becomes a lot more readable and fun to work with.<br />
<br />
<script src="https://gist.github.com/achipa/f3bbee5bba17e258e060.js"></script><br />
<br />
Qt does have a solution for native-looking UIs on Android in the form of <a href="http://qt-project.org/doc/qt-5/qtquickcontrols-index.html" target="_blank">QtQuick.Controls</a>, so my reasoning here is more to show<br />
<br />
<ul style="text-align: left;">
<li>what are the advantages of custom components</li>
<li>how custom components are done</li>
<li>what are the pitfalls of custom component sets</li>
</ul>
<div>
What are the advantages? If there is no native-looking component set, it's quite clear - you simply have no alternative. If QtQuick.Controls does exist for your platform (see the case of Android), there is still a number of reasons why you might consider going custom. First, you get the full functionality and availability of the platform-native set. QtQuick.Controls gives you something that is closer to a lowest common denominator, with a lot of platform-specific components/functionality missing and occasionally some input method quirks. By skipping this, you create UIs which are not just "close-to-platform-native", but effectively *are* platform native. Second, you get the full performance. By having a wrapper, there will still be a slight penalty for loading Qt, and parsing/constructing the QML objects, but there is no compromise once the UI is instantiated. I personally also like that you can use the platform-native documentation and examples, since you're just using QML syntax, but class names, properties and general usage pattern remain the same as on the platform.</div>
<div>
<br /></div>
<div>
How does one go about creating a new component set? As you've seen from the first QML snippet, all we really need is the <a href="http://qt-project.org/doc/qt-5/qtqml-index.html" target="_blank">QtQml </a>module. If you start creating with a completely custom *native* component set (ie not deriving from an existing QtQuick or QtQuick.Controls base) you get a really basic set of components to work with, namely Component, QtObject, Binding, Connections, Timer. All you native components will be actually QObject derived C++ objects, registered with the QML system, as described <a href="http://qt-project.org/doc/qt-5/qtqml-cppintegration-definetypes.html" target="_blank">here</a>. The classes themselves are still plain Qt classes, here's how my activity.h looks like:<br />
<br />
<script src="https://gist.github.com/achipa/9a37c44a4ca53550b4fe.js"></script><br />
<br />
After that, you need to register every such object with the QML engine (usually in your main.cpp) :<br />
<br />
<pre>qmlRegisterType<activity>("OutQross.Android", 0, 1, "Activity");</activity></pre>
<br />
With this we can start instantiating our custom objects from QML. The QtObject class/element unfortunately does not have a lot of the functionality normally coming from Item (including having a default children property), so I created an OutQrossItem helper class for this purpose, which is the base class for all my Qml elements.<br />
<br />
<script src="https://gist.github.com/achipa/cc58f90cbc781b2082f0.js"></script><br />
<br />
Finally, let's see the gritty innards of a custom component class, an Android Button in this case<br />
<br />
<script src="https://gist.github.com/achipa/13d78d57e7ec5f1d2779.js"></script><br />
<br />
As you can see, I still use the same UI inflate paradigm as Android to actually instantiate the button (this way we also avoid the question of the order of object initialization or property settings), and you can also see how a property can we wrapped. This means that the <b>full power of QML - bindings, signals/slots and JS are available</b> to us as the properties are mapped to the native components. This is crucial if you are building your own component sets, as otherwise you're just making a syntax converter - and this is also the answer to how this is different to just converting QML to <a href="http://developer.android.com/guide/topics/ui/declaring-layout.html" target="_blank">Android .XML UIs</a> or vice versa.<br />
<br />
For completeness' sake, let's mention that the .APK was 6.9MB and the memory usage of the HelloWorld app was 61510kb (about halfway between the version in my previous blog post and the "full" QtQuick experience)<br />
<br />
There are some pitfalls as well. First, while not rocket science, it's actual work. If you have an extensive GUI widget set or library (like Android), you probably want to use or write some sort of wrapper code generator as manually creating and maintaining a full wrapper set can be daunting. Second, there might be specific UI caveats - for example, in the case of my Android example, to keep it simple, I'm not actually running on the UI thread. This means that in my particular implementation while native component and property updates happen via the bindings, they might not immediately appear on the screen. This can be resolved, but it does require a very good understanding of how the native platform works. My advice is that you shouldn't consider writing wrappers because you don't know how the platform-native UIs work - it should primarily be done to accelerate future development and prototyping.</div>
</div>
Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com7tag:blogger.com,1999:blog-6092313305577856947.post-81120509521831275352014-11-17T20:00:00.000+01:002014-11-17T20:07:33.525+01:00Native UI in Qt on Android (without QtQuick.Controls)<div dir="ltr" style="text-align: left;" trbidi="on"><div dir="ltr" style="text-align: left;" trbidi="on">TL;DR - Yes, you can do a fast, no-compromise native UI without QtQuick on Android, and you'll use a lot less resources than a full QtQuick app, at the cost of somewhat messy code.<br />
<div dir="ltr" style="text-align: left;" trbidi="on"><br />
Nowadays <a href="http://qt-project.org/doc/qt-5/android-support.html" target="_blank">Qt for Android</a> comes with a nice QtQuick-compatible set of native-looking Android controls in the form of <a href="http://qt-project.org/doc/qt-5/qtquickcontrols-overview.html" target="_blank">QtQuick.Controls</a>. This blog post is not about them :) Let's go a bit off the beaten path - can we create a Qt application with a graphical, performant, native UI <b>without</b> using QtQuick (or QWidgets)? What are the advantages and disadvantages to such an approach?<br />
<br />
In a <a href="http://www.codingsubmarine.com/qt-on-ios-and-android-looking-native-today-or-maybe-tomorrow/#whats-possible">blog post</a> Artem Marchenko lists a couple of approaches how a Qt based native-looking UI would be possible, but these all include QML in one form another, which is not quite what we're after in this particular case. Another interesting project is Ben Lau's <a href="https://github.com/benlau/qtandroidexamplecode/tree/master/qtandroidrunner">QAndroidRunner</a> which combines native UIs and QML. Here, however, we'll focus how far can you get without ever touching QML or QtQuick.<br />
<br />
The key to using Android classes and resources is the <a href="http://qt-project.org/doc/qt-5/qtandroidextras-module.html" target="_blank">QAndroidExtras</a> module (it's an add-on module that has been around since Qt 5.2). The class I'm heavily relying on is <a href="http://qt-project.org/doc/qt-5/qandroidjniobject.html" target="_blank">QAndroidJNIObject</a> which allows Java class/object instantiation and manipulation. Thus, the two includes we'll use to enable creating native objects are<br />
<br />
<pre>#include <QtAndroidExtras/QAndroidJniObject>
#include <QtAndroidExtras/QtAndroid></pre><br />
When it comes to Android UIs, the first stop is the <a href="http://developer.android.com/reference/android/app/Activity.html" target="_blank">Activity</a> - on Android activities are how we interact with the user. This is effectively a window on which we put all our widgets and UI elements. Luckily, starting with Qt 5.3, we have a simple way of retrieving an activity with the <a href="http://qt-project.org/doc/qt-5/qtandroid.html#androidActivity" target="_blank">QtAndroid::androidActivity</a> function.<br />
<br />
<pre>QAndroidJniObject activity = QtAndroid::androidActivity();</pre><br />
Let's get to the meat of the matter - we'll need to create native layout and widget objects and set their parameters from Qt. Here's how that looks like<br />
<br />
<pre>QAndroidJniObject layout("android/widget/RelativeLayout",
"(Landroid/content/Context;)V",
activity.object());</pre><br />
The first parameter is the Java class name, the second the Java method signature (see <a href="http://www.rgagnon.com/javadetails/java-0286.html">here</a> for a few more examples, "javap -s" is your friend), and the third parameter is the actual object used as the parameter (as activity is a QAndroidJniObject, we need to use the object() method). With the call above we create a Layout and assign it to the activity.<br />
<br />
We can also call methods of our objects:<br />
<br />
<pre>button.callMethod<void>("setTextColor", "(I)V", -1); // Color.WHITE</pre><br />
Putting all these together, we can create a basic, but full-fledged Android application:<br />
<br />
<script src="https://gist.github.com/achipa/47f1202ec3bce3c356f8.js"></script><br />
<br />
...resulting in...<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRvXpaBGs-3Syv-tMv0XxE06rCDAxXa_ZvVFqjgfvW47sjJ0kdO-MhFBv5HfpX9DO_FJR_FSNdfzjktmfTuHdvW9cUtkf04XpPlk7x8WIuqfLD6l3gZeiprX7ZPah7-OllqQSuu1tLUXA/s1600/Screenshot_2014-11-17-14-59-15_low.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRvXpaBGs-3Syv-tMv0XxE06rCDAxXa_ZvVFqjgfvW47sjJ0kdO-MhFBv5HfpX9DO_FJR_FSNdfzjktmfTuHdvW9cUtkf04XpPlk7x8WIuqfLD6l3gZeiprX7ZPah7-OllqQSuu1tLUXA/s320/Screenshot_2014-11-17-14-59-15_low.png" /></a></div><br />
This "Hello world" code is clearly quite a bit more complicated than it's QML counterpart:<br />
<br />
<script src="https://gist.github.com/achipa/832a6070893b89bf5f38.js"></script><br />
<br />
The complexity downside is quite obvious - it's hard to beat QML's brevity and clarity. Another, perhaps not immediately visible downside is that this particular style of C++ code is more error-prone - there is no type safety as the objects are generated dynamically, so on errors, it's easy to end up with NULL objects and segfaults. <br />
<br />
Why would anyone use it, then? Let's take a look at resource consumption:<br />
<br />
The APK size for the non-QML Android version of Hello World is 5,663,420 bytes, while the APK with the Controls included is 10,406,706. The difference could be even bigger, though, as the default android mkspec includes a few extra Qt modules. It should be possible to get the minimum APK size down to around 3MB. If you are using Ministro, this might not be as big of an issue, but for self-contained applications, or embedded, this can shave a few precious megabytes off of the application.<br />
<br />
It's not just flash storage and network bandwidth we can save though - there is a memory-usage difference as well. While adb dumpsys meminfo is not a perfect way to measure memory usage, it is indicative:<br />
<br />
<pre>40761 kB: org.qtproject.example.QtJavaHelloWorld
77531 kB: org.qtproject.example.QmlHelloWorld</pre><br />
While a ~35MB of minimum framework tax might not sound like much in the era of devices with several gigabytes of RAM, using a complex QML structure can inflate the difference further. On embedded and legacy devices every megabyte counts, so even this 35MB difference can help (plenty of low-end Android devices with 256-512MB of RAM).<br />
<br />
There are other benefits to not using QtQuick controls - controls are a "lowest common denominator" approach designed to easy cross-platform development. It does not contain all UI widgets and elements, nor functionality offered by Android APIs. By using the approach as demonstrated, there is no compromise - the full UI arsenal is at our disposal, at the exact same performance as for regular Java apps.<br />
<br />
Finally, the QtQuick controls version depends on the Qt version shipped with the application. In the non-Controls version we always get the native controls, with native styling and behavior, even if the platform release is newer than what our QtQuick.Controls version supports.<br />
<br />
To summarize, the advantages to a Controls-less approach are:<br />
<ul style="text-align: left;"><li>Native UI performance</li>
<li>Smaller APK size (currently at least ~5MB less, potentially ~7MB)</li>
<li>Smaller memory footprint (35MB for Hello world, more as app complexity increases)</li>
<li>Full UI functionality available, regardless of Qt version</li>
<li>Styling always latest platform-native</li>
</ul>Disadvantages<br />
<br />
<ul style="text-align: left;"><li>Not cross-platform</li>
<li>Significantly increased code complexity, especially with more complex UIs</li>
<li>Harder to debug due to dynamic nature and lack of tooling support</li>
</ul><br />
It's actually possible to mitigate some of the disadvantages, so stay tuned for further posts on this topic!<br />
<br />
</div></div></div>Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com169tag:blogger.com,1999:blog-6092313305577856947.post-62844945162029046282011-07-09T18:22:00.004+02:002011-07-10T10:29:24.942+02:00Qt Components - The story of the ugly QWidgetlingDisclaimer: these are my own, personal thoughts, not necessarily matching those of my employer, neighbor, goldfish or innocent bystanders.<br />
<br />
Paradigm shifts are always difficult, especially when linked to <a href="http://www.developer.nokia.com/Community/Blogs/blog/kate-alholas-forum-nokia-blog/2010/11/14/how-to-make-modern-mobile-applications-with-qt-quick-components">technology changes</a>. <a href="http://doc.qt.nokia.com/qt-components-symbian-1.0/qt-components-introduction.html">Qt Components</a> are here and seeing that there and at least three component sets (<a href="http://www.blogger.com/goog_1202795453">MeeGo Harmattan</a><a href="http://labs.qt.nokia.com/2011/07/06/ready-made-ui-building-blocks-at-your-service-qt-quick-components-for-symbian-and-meego-1-2-harmattan/">, Symbian</a>, <a href="http://appdeveloper.intel.com/en-us/blog/2011/04/04/intel-meego-12-tablet-ux-now-open-sourced-available-meegocom">MeeGo UX</a>) and counting, it is hard to see how components will help solve the cross-platform problem that has been plaguing mobile developers. Hard to see, if you think about Components as a QWidgetling, that is. In the vein of the story of the ugly duckling, I will try to explain how you can utilize Components and avoid the feeling of being given a square peg when you are looking at a round hole. To repeat, this is about figuring about just what QML with Components is, how it's supposed to be used. Disclaimer #2: Those who think <a href="http://doc.qt.nokia.com/latest/qwidget.html">QWidgets</a> should have been the long term technology of choice, or hate QML with a passion, please skip this article. You're not going to like it, and I'm usually delete-button-happy, so save the angst and skip it. Sorry and thanks.<br />
<br />
<b>QWidgets </b><br />
<br />
If I was trolling, I would say they were (mobile-wise) the cross-platform solution that never existed - it certainly *sounded* good that I, as a developer, work against an API and the UI framework works out everything, resolution, input method, hardware be damned. This, however, is a bit like listening to politicians - just vote for me and I will solve all problems. Well, not quite. As many have outlined, the paradigm shift from the "I wrap everything to native controls which<br />
kinda look/work the same" characteristic for the desktop spelt doom for the classic widget based approach. I have gotten nasty looks IRL for saying this, but Maemo5 did not prove QWidgets is the solution - it proved that it is NOT (yes, I be trollin', but only to make a point :). It was a great effort, and while the looks were certainly on par, your supposedly cross-platform code was a mess, full of #ifdefs, <a href="http://doc.qt.nokia.com/qt-maemo/qtmaemo5.html">modules and classes specific to Maemo5</a>. As I sometimes say, well, with enough ifdefs, you could switch between GTK and Qt, right ? At the same time, development was not made any easier - there were no specific UI tools for creating Maemo interfaces.<br />
<b><br />QML, and the long road to Components</b><br />
<br />
<a href="http://en.wikipedia.org/wiki/QML">Enter QML</a>, a radically different approach. As people soon realized, QML is a base technology, it does not provide you with buttons or much higher level functionality you previously had with QWidgets. Also, at the same time, it was said <a href="http://labs.qt.nokia.com/2010/09/10/building-the-future-reintroducing-the-qt-quick-components/">Qt Components will solve this</a>. All was well, it was just a little wait and we will have our new incarnation of QWidgets, right ? Well, not quite... <br />
<b><br />QtComponents have hatched... </b><br />
<br />
... and it turns out they harbor a pretty ugly QWidgets replacement. People trying to make QML that runs equally well on <a href="http://swipe.nokia.com/">Harmattan</a> using the Harmattan components, Symbian using Symbian components already felt this is not good. Recently I got a contribution for <a href="http://projects.developer.nokia.com/qtinfo">QtInfo</a> in the form of a cool <a href="http://qtsource.wordpress.com/2011/07/06/qtinfo-goes-qt-quick-components-on-symbian/">Symbian components UI</a>. I tried to kick it around a bit to <a href="http://www.developer.nokia.com/Community/Blogs/blog/kate-alholas-forum-nokia-blog/2011/07/08/porting-meego-1.2-harmattan-qt-quick-components">make it work on Harmattan</a>, with bleak results, with projects diverging already at the HelloWorld. Something was wrong. This duckling was really ugly. After a few days, however, it dawned on me... <br />
<br />
<b>A chainsaw cuts trees faster than an axe only if it's on</b><br />
<br />
The reason I was suffering and losing time was because for years I have been taught to think (much in the vein of QWidgets) almost axiomatically that I want a single codebase and with enough tweaking (ifdefs) it would run equally well on platforms. That is no longer necessarily true (if you think I'm losing my mind, that's understandable, but read on). In terms of the title of this paragraph, I had Components (the chainsaw) and I was hitting the tree with it like I would with an axe, and it really is a horrible experience. However, there is a paradigm shift on the horizon. Turns out, <b>Components solves the cross-platform challenge NOT by providing a singular API. It attacks the problem by making is super-easy to write throwaway code</b>. WHAT ? (if you think I *completely* lost my mind, that's understandable, too, but read on).<br />
<br />
<b>Live fast, die young</b><br />
<br />
One of the key appeals of the old widget approach was their enduring nature. If you wrote a desktop application 10 years ago with it, it would likely work okay today. However, this age of UI tranquility, taken for granted for so long, is in it's final days. As we've seen, <a href="http://www.youtube.com/watch?v=WqC0xVLGdAY">today even the most conservative desktop OSs are undergoing UI paradigm shifts</a>. Mobile is even faster, 4 years in mobile is an eternity. Writing an UI as if it was there to stay for decades is losing appeal quickly - the life expectancy of mobile UIs is dramatically shorter, which coincidentally also lowers the long-term maintenance burden, traditionally so important to developers.<br />
<br />
<b>Use the Force. Let go, Luke.</b><br />
<br />
As Ben Kenobi said. And even though it seemed weird to the people in the rebel base for Luke Skywalker to use the Force instead of the targeting computer, it shows us what's happening here. <b>Let go of the idea of monolithic, single UI codebases. <i>Let. Go.</i></b> Like the huge armor of European medieval knights on appearance of the guns - the armor no longer provided real protection, but made you slow and unmaneuverable. So, what should I do, I hear you asking ? <b><i>EMBRACE DIVERSITY</i>. Use the weapon/components best suited for the platform. Don't be afraid to improvise or include your own Elements, or borrow (barring license limitations) from Components of other platforms. Keep your UI (QML) layer as thin and nimble as possible, keep the logic on the C++ side</b>, it will help you both in terms of portability and speed. Spawn as many UIs as you wish. Think about the UI as a throwaway component. Is it Harmattan ? Okay, I'll just drop in the QML from the examples, who cares if it runs on Symbian. Different resolution ? I'll just include a different QML optimized for that. I can see the disbelief in your eyes. How can this work ? The point is that spawning UIs with QML is *fast*. Really fast. Actually way, way, way faster than tweaking for a certain subset/common API or resolution independence. You will write (and maintain !) 5 different UIs *faster* than you would write a monolithic QWidgets UI that would work truly cross-platform. It is a radically different setup. Returning to my QtInfo porting example - it took me nearly a day to create a port from the Symbian-only version to a version that ran on both Harmattan and Symbian, but it meant a lot of compromises and visual artifacts, rotation and integration issues. However, when I realized the new paradigm I outlined above, I had a sexy Harmattan fully integrated native UI up and running in 30 minutes, just appended the QML to the package and now the application is cool on Symbian, Maemo, Harmattan, the Desktop, and I could add a tablet MeeGo UX in another 30 minutes.<br />
<br />
There you go, with all the acknowledgement that this might be hard to swallow for many of you, trusty old QWidget veterans, hopefully I now explained just what kind of square peg Qt Components I see and you will hopefully stop trying to shove it in that round hole :) Now go and make Qt Components shine and create beautiful swans of Harmattan, Symbian, MeeGo, or whichever platform the Qt winds might blow on.Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com16tag:blogger.com,1999:blog-6092313305577856947.post-25124987655881005682011-04-10T14:31:00.000+02:002011-04-10T14:31:24.767+02:00Is Open a dirty word now ?<div dir="ltr" style="text-align: left;" trbidi="on">
Open technologies gained a lot of momentum in the past couple of years, but what became of the term Open ? Does it still hold and mean the same values it did previously ? Were the purists speaking about differences between Open and Free right ?<br />
<br />
If you're reading this blog you're probably aware that I'm fairly fond of FOSS, both as a concept and a business model. Undoubtedly, open technologies made huge inroads in various industries -
servers in the IT industry, various OSes in the telecoms industry, etc.
However, there is a disturbing tendency going on in the world of Open. Meaning that Open implies Free less and less. You might be surprised at this point - what ? How can you be Open and not Free ? Well, if you look at the 'classic' FOSS definition on Wikipedia, you'll see Open Source is defined as "An <b><a href="http://en.wikipedia.org/wiki/Open_source">open source</a> license</b> is a <a href="http://en.wikipedia.org/wiki/Copyright">copyright</a> <a href="http://en.wikipedia.org/wiki/License">license</a> for <a href="http://en.wikipedia.org/wiki/Computer_software">computer software</a> that makes the <a href="http://en.wikipedia.org/wiki/Source_code">source code</a> available for everyone to use." - this is the type of open we all cherish and love. But let's take a look at who sports the Open sticker nowadays ? The 500lbs gorilla is of course the Open Handset Alliance, and the Android Open Source project. Despite the lot of "Open" in the names, in the open is not where development happens, and lately even the <a href="http://www.zdnet.com/blog/google/google-android-30-honeycomb-open-source-no-more/2845">source availability became selective</a>. Another infamous example is the <a href="http://www.openscreenproject.org/">Open Screen Project</a> run by Adobe intended to bring Flash related technologies for everybody - but in fact being nothing more than another industry alliance to try and grab market share from competitors, Open Source and values not accounting for much<strong></strong>. There are other organizations that also ride the Open moniker - let's take for example the <a href="http://www.opendesign.com/">Open Design Alliance</a> - a nonprofit organization that focuses on development of CAD-related libraries... However, open here means pay for the binaries, and pay (<a href="http://www.opendesign.com/Founding">a lot - 25K$</a>) to see the sources, unless a board of members deems you worthy. Not the type of open libraries you were expecting, right ? That's where the problem lies - Open is more and more a sinonym for the "For Sale" sticker, and the term "Alliance" is becoming a marketing lingo equivalent of "<a href="http://en.wikipedia.org/wiki/Cartel">Cartel</a>". This problem was recognized fairly early on by <a href="http://en.wikipedia.org/wiki/Open_Source_Initiative">OSI</a> and hence the term OSI approved Open Source license, but if the term Open becomes diluted enough, will it even mean anything except for marketing purposes and a counter-term for "exclusive technology" ? Will the O in FOSS become meaningless ? To be honest, the term Open was used long before Free, before the software industry, and it meant "public", mostly in the context of standards. However, now even that, decades old meaning is losing it's value. Today's Open is far too open unrelated to Free or even Public.<br />
<br />
What's the takeaway, you might ask ? Be careful of how you yourself use the term, and be vary of supporting any project or (especially big business) initiative just because it uses the word "open". Support the values, and projects that promote those values, not the names. </div>Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com3tag:blogger.com,1999:blog-6092313305577856947.post-4865938525371478252011-04-02T14:13:00.001+02:002011-04-02T14:13:44.903+02:00The age of pointless mobile benchmarks<div dir="ltr" style="text-align: left;" trbidi="on">
Mobile devices are ever-more like their counterparts and we're starting to see benchmarks popping up on popular gadget sites. Sadly, most of these sites have not yet gone through the analytical phase of what most PC review sites did many many years ago and if effect turn into simple marketing vehicles. Let's see the common pitfalls !<br />
<br />
To be clear I'm not talking about bad journalism, that result in <a href="http://www.engadget.com/2011/04/02/qualcomms-1-5ghz-dual-core-msm8660-destroys-the-competition-in/">articles like this</a> (note how they manage to leave out from the title the ONE thing - GPU performance - that the article is about) even if the source a very reasonable <a href="http://www.anandtech.com/show/4243/dual-core-snapdragon-gpu-performance-1-5-ghz-msm8660-adreno-220-benchmarks/">article</a>. I'll try to describe the differences why the methods and criteria established in the PC field that are starting to be applied to the mobile arena (like the Anand article above) make a lot less sense than they did for the original personal computers.<br />
<br />
Pitfall no. 1: Level of integration - hardware<br />
<br />
Mobile devices are nowadays mostly built around what is known as a SoC (System-on-Chip), which means that most components that would be separate chips or even replaceable units even on a notebook computer, are all rolled into one, which makes it very difficult to benchmark *single* components as they are inseparable from the rest of the system. How
much is a NVidia vs ATI benchmark worth if you're comparing a Dell Inspiron 13" notebook with a NVidia card against a HP desktop one with an ATI and a 22" display ? To make it worse, some of the devices include additional video processing units (which again might be good only for some formats and bitrates) so the original chipset-style comparison is even more difficult to make.<br />
<br />
Pitfall no. 2: Architectural differences<br />
<br />
<br />
X86 CPUs is incremental - hardware backwards compatibility
is pretty much a given, the only difference in capabilities is the in
reality only in the timeframe when vendors add in extensions (like the
different iterations of SSE). Mobile devices have to be a lot more
transistor-count an usually binary compatibility is the first one to go. For example the relatively new Tegra2 chose to forego the
NEON multimedia instructions that were common in Snapdragon and OMAP
chips. OpenGL ES 2.0 is not backwards compatible with OpenGL ES 1.1, etc. Depending on what you use and how your software works, this makes things a lot murkier as the fact that device X works better with Quake 123 means nothing in terms whether what you want to run works better.<br />
<br />
Pitfall no. 3: Form factor difference<br />
<br />
A variation of the previous point - the resolutions are vastly different, but this does not only touch on the graphical performance, but also on our usage patterns and perception of performance. Nominally a device can have a better framerate, but because of screen size and distance-to-eye differences you might actually subjectively prefer the one with the marginally lower framerate.<br />
<br />
Pitfall no. 4: Multicore is a sword with two edges<br />
<br />
Any multicore design is only as good as the software that runs it. This was true on the desktop, but multicore is a whole different beast on mobile devices, as the quality of software determines whether that dual-core monster is better or, actually, worse than a well executed singlecore one, both in terms of performance and battery usage.<br />
<br />
Pitfall no. 5: Software platform diversity<br />
<br />
In the desktop and notebook world, just by taking Windows, Mac (and Linux of course ! :) you cover 99%+ of users. On the other hand, in mobile you literally have a jungle of OSes (there are almost a dozen OSes that are above the million mark) which are optimized for very different hardware and very different use-cases. This is not an issue in the X86 world because the application-level performance is comparable with at best a few percent difference, but on mobiles, due to drivers and being optimized for various modes of operation, the same HW can behave vastly differently with different OSes, so those extra FPS in a benchmark can again be very misleading.<br />
<br />
Plenty more pitfalls, but let's not overdo it, so for the conclusion - since the complexity of these devices now rivals personal computers, it's only normal that people want to compare them the way they did with personal computers. The trouble is, these are not NEARLY as uniform as their bigger brethren so new ways of benchmarking will have to come up that will be less hardware or device oriented even if that means we'll have to give up FPS measures as such.</div>Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com1tag:blogger.com,1999:blog-6092313305577856947.post-40115580121487100862010-09-22T12:16:00.008+02:002010-09-22T16:08:03.153+02:00The Maemo Community Council elections - Why you should care<br />
<div style="margin: 0px; text-indent: 0px;">
The maemo.org community is something of a rare bird in the mobile environment - a self-organizing community centered around Nokia's tablet line, with a very strong infrastructure and unique spot where users, developers and hackers come together resulting in a lot of synergy and powerful base compared to the niche aspect of Maemo. One of the most peculiar aspects of it is the <a href="http://wiki.maemo.org/Community_Council">Community Council</a>, a representative body that deals with all things Maemo. What it can do, why should you care and, most importantly, why should you <a href="http://maemo.org/vote/vote.php?election_id=10">vote *TODAY*</a> if you are a community member with enough karma ? Read on to find out ! I also hope this to shed a little light and be a short introduction of the inner workings of maemo.org to people NOT familiar with the intricate community workings of <a href="http://maemo.org/">maemo.org</a> . </div>
<div style="margin: 0px; text-indent: 0px;">
<br /></div>
<div style="margin: 0px; text-indent: 0px;">
The Community Council was formed two years ago as a representative body, with a <a href="http://wiki.maemo.org/Community_Council/FAQ">role</a> to "<span style="font-weight: 600;">represent the Maemo community's best interests to Nokia, and to act as a community conduit for Nokia-generated information.</span>" This role has <a href="http://blog.jeremiahfoster.com/?p=253">recently been expanded</a>, as Nokia has transferred control of maemo.org to the community (=the Council as a representative body). This gives it a fairly complete control over all things that happen in maemo.org, a lot of which many users are not even aware of:</div>
<div style="margin: 0px; text-indent: 0px;">
<br /></div>
<br />
<ul>
<li>the rules that define criteria for software in extras and related repositories</li>
<li>determining forum policies</li>
<li>overseeing collection of documentation/wikis/howtos </li>
<li>ability to issue tasks to maemo.org staff (you DO care if the forums or Extras breaks down or is difficult to use, right ?)</li>
<li>disseminate important information through the Council blog</li>
<li>help coordinate community events (Summits/Conferences/meetups)</li>
<li>help with grassroots efforts (competitions, hackfests, anything Maemo)</li>
<li>formalize concerns and issues and pass them to Nokia</li>
<li>define goals/strategies for the future of maemo.org</li>
<li>really, anything maemo.org related</li>
<li>in fact, anything community related goes - it it's cool, support it !</li>
</ul>
<br />
<div style="margin: 0px; text-indent: 0px;">
So yes - if you would like more of the things above, or you have a peeve you'd like changed - the Council is the body whose attention you need. Generally - if you have an idea relating to Maemo, and you don't know who to turn to, the council is the address (with a notable exception - the Council is not <a href="http://www.nokia.com/about-nokia/contacts/customer-service">Nokia Care</a>, Nokia has proper customer care channels, the Council focuses on community aspects).</div>
<div style="margin: 0px; text-indent: 0px;">
<br /></div>
<div style="margin: 0px; text-indent: 0px;">
</div>
<div style="margin: 0px; text-indent: 0px;">
Even with fairly complete control over the maemo.org realm, I cannot emphasize enough the facilitation character of the Council when it comes to Nokia. Nokia does not obey the Council - but certainly does listen to it as it represents the most vibrant and passionate base of it's users.</div>
<div style="margin: 0px; text-indent: 0px;">
</div>
<div style="margin: 0px; text-indent: 0px;">
<br />
I've listed a short (far from complete !) list of what the Council can do - but there are things, often sources for confusion, of what it CANNOT do. Can the Council guarantee that a particular firmware will be made available to your device ? No - it's not a community call. Can the Council force Nokia to include/exclude components from firmwares ? No - it's not a community call. </div>
<div style="margin: 0px; text-indent: 0px;">
<br /></div>
<div style="margin: 0px; text-indent: 0px;">
</div>
<div style="margin: 0px; text-indent: 0px;">
Some of you Maemo device owners will stop (or already stopped with tldr ;) ) reading as they don't really care about this maemo.org stuff (something I doubt, as Extras, a central part of it, is the main source of applications).<br />
<br /></div>
<div style="margin: 0px; text-indent: 0px;">
However, if even if all this community-talk jibberish means nothing to you and and you define the bottom line as Apps Apps and Apps (with Flash), you should pay attention. The Community Council is in the unique position to make a strategy for the future of the community. It *does* direct the work of maemo.org people and will be pivotal in determining for example what software will be available from MeeGo repositories, or just how difficult it will be for MeeGo/Harmattan developers to support the Extras repository. They can (and IMO should !) also be the voice of the Maemo community inside MeeGo - MeeGo doesn't have a council, and if you have an itch, it won't get resolved unless you or your representatives do it.</div>
<div style="margin: 0px; text-indent: 0px;">
</div>
<div style="margin: 0px; text-indent: 0px;">
<br /></div>
<div style="margin: 0px; text-indent: 0px;">
All this brings us to the bottom line - in my opinion, the Council matters, but only to the extent of the abilities of people in there. In a worst case scenario, the people you elect to it do nothing - that's the same as if it didn't exist. However, <b>YOU, the community member have the power to elect <a href="http://mobiletablets.blogspot.com/2010/09/maemo-community-council-election-q3.html">people who ARE capable of affecting the future of maemo.org</a> and all the people and device it touches on, be that apps, events or other</b>. Today is the last day of the <a href="http://wiki.maemo.org/Community_Council/Council_election_Q3_2010">community elections </a>for the next term, so if you care the tinyest bit about Maemo, MeeGo, maemo.org or your Maemo device - <b><a href="http://maemo.org/vote/vote.php?election_id=10">use that voting token and make a difference</a></b>. </div>
<div style="margin: 0px; text-indent: 0px;">
</div>
<div style="margin: 0px; text-indent: 0px;">
</div>
<div style="margin: 0px; text-indent: 0px;">
</div>
<br />Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com2tag:blogger.com,1999:blog-6092313305577856947.post-50608564371732500222010-08-28T10:02:00.000+02:002010-08-28T10:02:36.244+02:00Java mobile apps today - a technology/weapon misunderstoodWhen you look at the present landscape of available mobile technologies to develop apps with, you'll see an abundant offering. Depending on what platform you're developing for, you'll see a mix of native applications, web technologies and similar. These are all cool and powerful, but what is not often talked about is the scope of the applications written and how choice of these technologies is linked with business models. What am I talking about here ? People working with J2ME will be eager to point out that there are several hundred million phones capable of running such apps and that phones that have that as the primary application platform are still going strong (for example Nokia's S40 phones). Others will say that means nothing as owners of such phones are unlikely to pay for apps and that their hardware is so limited that you couldn't make something impressive anyway. Both are right in a way, but the story doesn't end here. What is often overlooked that shiny, flashy apps, sold as a product are not the only business model here even though originally most of the J2ME offering were just that - games. Think about SMS for a moment here. It is a super simple service, basically a specialized application, that earns huge amounts of money. But is the money in selling this 'SMS application' as it would be in selling 'Angry Birds' ? No, it's in the services it supports. It's somewhat similar to the problem that some people first encountering Open Source business models have - if you give your app away, how do you make money ? And this is why Java mobile app programming of today is misunderstood - it should not be viewed as a competitor to the write-app-sell-app-...-profit business models of iOS, Android or Symbian, but as a gateway that allows addressing a huge user base otherwise currently unreachable with other technologies. You don't need super-high technologies and sophisticated devices to check for a public transport schedule, arrange reservations, inventory/availability checks, etc. In that light, it's far from dead and/or useless. It's just about realizing that you have a business that CAN benefit from such a userbase.Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com5tag:blogger.com,1999:blog-6092313305577856947.post-33563655273717239672010-08-02T08:00:00.001+02:002010-08-02T08:00:03.862+02:00Flash versioning gone wrong, or, should the abusers be abused ?A painful fact is that Flash 10.1 is not currently available for the Nokia N900 (well, at least painful for N900 owners). If we look at the bigger picture, applications (like my version-forging <a href="http://talk.maemo.org/showthread.php?t=59336">TweakFlashVer</a>) uncover a few non-N900 specific problems with the way things are done in Flash land. <br />
<br />
TweakFlashVer is an awful hack - it just makes the Flash plugin report a faked version string (much like browsers in the old times <a href="http://www.mydigitallife.info/2010/01/27/how-to-spoof-or-change-opera-user-agent-string/">forged their agent strings</a>). Seasoned Flash developers are naturally very displeased with such an approach, as the plugin itself does not gain any additional functionality or acceleration, it's still the same Flash it was prior to the intervention. I can hear you ask - well, what good is it, then ?<br />
<br />
And here is the problem - cludgy as it is, it DOES work, as seen on the N900, Facebook videos work again and many sites came back to life. How is that possible ? Sadly, often the real requirements of the content presented by Flash do NOT match the requested version in the loader/web page. But why do people declare wrong versions and make lives of their own users miserable ? Because Flash is doing it wrong in the first place, and then it gets abused by webmasters and flash devs further (making TweakFlashVer an abuse of an abuse). What are the reasons for this abuse in the first place ?<br />
<br />
<ul>
<li>Using version detection as an upgrade mechanism. The
assumption is that if someone does not have the latest version, it is simply
because they simply have never been nudged into upgrading it. The developers doing this think they are making users a favor since
they will be upgrading to a version which is faster, safe, but are forgetting that different platforms have different upgrade cycles, and that latest version might not be available just yet.</li>
<li>Using the wrong loader. This can be caused by copy-pasting flash loader code from other projects or on-line tutorials, without matching the version requirements in the loader with the actual content. In other words - plain sloppiness.</li>
</ul>
Both of these, however, only go to show that Flash is doing it wrong in the first place, for the following reasons<br />
<br />
<ul>
<li>The queries should be for *features*, not versions. This important as we will be seeing Flash players with different preferred feature sets. For example, a platform with hardware video acceleration might prefer a different codec to a platform that has no such thing (currently this role is done - again, in a wrong way - by checking for Flash Lite). Not to mention the pipe dream that one day Flash becomes a real Open industry standard with multiple content player plugins, which would obviously have different, partially overlapping feature sets.</li>
<li>The version requirement should not be a statically coded thing in HTML that is unrelated to the actual content. If there is (any) Flash version available, the versioning requirement/handshake should be done *inside* Flash.</li>
<li>If possible, the server should present multiple versions. Sure, Flash 10 has new features, but there is no fallback, meaning there is no systematic way of saying 'hey, give me a Flash 9 version of that content'. As it is now, the server acts as a bouncer, asks 'whatcha got' and the client says 'errr.. 9.0.260 ?' and then the server just says "you're too old for this" and slams the door. </li>
</ul>
<br />
The question in the end thus remains. There is no doubt TweakFlashVer is a super-hacky solution to frankenstein Flash in order to allow users to access the content they want, but the Flash powers that be will have to come up with two solutions before this approach becomes widespread and turns from a hack into a modus operandi of abandoned Flash platforms, like Maemo 5 and 64-bit Linux:<br />
<br />
<ul>
<li>A system that can address the sloppiness of it's users and their (mis)use of HTML loaders</li>
<li>Change the upgrade-upgrade-upgrade mantra. Sooner or later the range of devices that will (try to) run Flash will get so wide that a version number will not guarantee anything, and the Open Screen Project changed nothing in that aspect - users of particular platform are still at the mercy of Adobe and/or their vendor if they will get Flash player in a firmware without any guarantee that a sloppy coder won't render their device obsolete in a couple of months.</li>
</ul>Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com8tag:blogger.com,1999:blog-6092313305577856947.post-25750948404950333822010-07-30T11:00:00.004+02:002010-07-30T11:00:05.666+02:00Where are those mobile Qt apps ? (Part 3, Resolution)After a <a href="http://achipa.blogspot.com/2010/07/so-where-are-those-mobile-qt-apps-part.html">short historical</a> overview and a <a href="http://achipa.blogspot.com/2010/07/where-are-those-mobile-qt-apps-part-2.html">short list of growing pains</a>, in this, third installment of the mobile <a href="http://qt.nokia.com/">Qt</a> app story, I will focus on what boulders remain in the path of widespread adoption of Qt among app mobile developers. Most of the technical groundwork has been laid down, but to reach a final resolution, it needs to include a bit more than just a healthy base.<br />
<br />
<br />
<b>Decouple Qt releases from firmware releases</b><br />
<br />
As seen from the infamous PR1.2 delay, a coupled-with-the-firmware release cycle is detrimental to the platform. If multiple devices are on the market, it would mean instant-fragmentation as developers would have to code for the Qt released with the last firmware. This is eating Android alive, too, as various handsets have different upgrade cycles. A separate distribution mechanism HAS to be employed. It will be tricky as with MeeGo and Symbian^4 Qt is part of the OS and many teams will be reluctant to bet firmware functionality on the backward compatibility of Qt. But that is not the only thing that can cause fragmentation if it isn't true that...<br />
<br />
<b>One mobile widget framework is enough</b><br />
<br />
<br />
I harp about this regularly (and will continue to do so until I get good news from an official source :), the option to have separate widget frameworks for Symbian (Orbit/uiemo) and MeeGo (DirectUI/MeeGo Touch Framework) is something that is completely against what Qt is trying to accomplish by bridging the two OS-es.<b> </b><br />
<br />
<b>All you bases are belong to us</b><br />
<br />
Qt is almost a country of it's own, addressing (or having a
development version that addresses) various aspects of software
development, both mobile and desktop. However, there is one thing where it is sorely lacking - the wizz-bang games department. Yes, QGraphicsView and 3D enablers are cool and all, but that is not enough (even with QML and UI scripting). It would certainly be an overkill and unnecessary delay to implement a complete game engine in Qt, but there are alternatives - make a Unity3D port, or, better yet, in the spirit of open source, sponsor Ogre binding (and GLES) development for Qt, with the necessary physics libs.<br />
<br />
<b>Build it and they will come - Ovi and devices</b><br />
<br />
Professional mobile developers can and will materialize only after the market for the Qt apps materializes. The prerequisite for this is that Qt gets a first-class treatment in the Ovi store, and the QA process is not a hit-and-miss, something that developers are guessing about. Once the Ovi store really starts accepting Qt apps en masse, the question turns into how many devices can be targeted via Qt. I can hear you say "well that's like almost all Symbian handsets in the last 2-3 years". Yeah, but...<b> </b><br />
<br />
<br />
<b>Market share is not necessarily mindshare</b><br />
<br />
Devices that can be retrofitted with Qt already exist in the (tens of) millions range. However, these devices are mostly low to midrange devices as there were no runaway Symbian successes in the high-end segment for a while now. It will be hard to convince people to target a market, no matter how objectively big if they believe/see it as a relic, which means...<b> </b><br />
<br />
<b>You've got to be cool</b><br />
<br />
The vehicles for the Qt platform need to be cool and carriers of high tech. This is the wave Android is riding in 2010. Now, the best way to do this is having iconic devices (iPhone killers if you wish), but this is not ONLY about devices, it's about how you handle your technology in general, your devs, your community, blogs and everything related to it. Qt has to be <b>perceived</b> cool, a must-have even by non-tech people, not just a sticker on the corner of a box and something geeks nod over on irc. It IS the differentiating factor. Take for example the happenings of last week in the Nokia N900 land. A triple-release is done - preview of the <a href="http://developer.qt.nokia.com/forums/viewthread/307/">Qt Web Runtime</a>, a <a href="http://labs.trolltech.com/blogs/2010/07/27/qt-mobility-110-technology-preview/">new version of Qt Mobility</a> and the super-cool <a href="http://fcam.garage.maemo.org/fcamera.html">fcamera</a> project. This triplet just oozes with tech-cool demo potential, but it just isn't leveraged, hardly getting even a blog post. Instead there is a campaign and an 'exciting news' about Ovi doing a comic (I'm sure it will be good, but... ). This points to comms issues, but also lack of<br />
<br />
<b>Communication/Community Focus</b><br />
<br />
While I don't know how many different communities and aspects of Qt should there addressed separately, I'm pretty sure we are already overloaded, even before the hordes of the new Qt developer generations emerge. There is the <a href="http://developer.qt.nokia.com/">Qt Developer Network</a>, then we have <a href="http://www.forum.nokia.com/">Forum Nokia</a> (home of the Nokia Qt SDK), followed by a more specific <a href="http://meego.com/community">MeeGo</a> community that is vested (well, at least the handset variant) in Qt, and the same will be true for Symbian. OTOH If you want to publish/talk about Qt development on currently available devices, you should go to <a href="http://maemo.org/">maemo.org</a>. While in community waters, we should also mention <a href="http://www.qtcentre.org/">Qt Centre</a>. Quite a handful of forums, mailing lists and irc channels to follow, and I have not even talked about communities focused squarely at end-users ! Speaking of end-users, some people who even knew about those Qt/fcam releases I mentioned above were quite discontent, because there is/was no concept of...<br />
<br />
<b>Control and drive expectations</b><br />
<br />
The 'other' platforms and ecosystem have built up and trained users to expect certain things in a certain way, and if they are not educated, they will not understand what is going on and will easily dismiss even good news when it is not is a form they expect it in. See the above - new releases of QtMobility, WRT, etc were not treated by many as real news or support by Nokia for the N900, even though they were done by official Nokia teams. The concept of the 'holy firmware release' is still strong, because people don't understand the concept of libraries and components (as that is not how most other platforms operate).<br />
<br />
<br />
Those would be my major points, and while they might sound a bit grim (some not even related to Qt itself), I don't think they are insurmountable at all, it just takes a little effort (some already underway) and presto, the arid Qt mobile app landscape can bloom like a savanna after a rain. <br />
<br />Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com8tag:blogger.com,1999:blog-6092313305577856947.post-30610162715798339942010-07-12T14:15:00.003+02:002010-07-14T18:13:12.297+02:00Where are those mobile Qt apps ? (Part 2, Adoption)After my <a href="http://achipa.blogspot.com/2010/07/so-where-are-those-mobile-qt-apps-part.html">last blog post</a> that discussed the <a href="http://qt.nokia.com/">Qt toolkit</a>'s history, present and future in the Nokia ecosystem, in this second part of my blog series I will talk about the problems of Qt adoption among developers so far and the effects these problems had on (the lack of) mobile Qt applications today.<br />
<br />
This will not be an article about the flaws of C++, bloatedness of frameworks and similar issues. Sure, some people prefer other languages, other frameworks, or have a personal beef with Qt, but that is a different story. Here, I will talk about the WAY things happened, are happening and what <a href="http://tabulacrypticum.wordpress.com/2010/06/10/maemo-missteps-for-2010/">could have been better handled</a> - albeit from a Qt angle.<br />
<br />
<br />
<b>Are we there yet ?</b><br />
<br />
Qt was originally a desktop application framework, but has been dabbling with embedded applications way before Nokia took over. However, the focus shifted dramatically and Qt (and derived technologies) went to overdrive, introducing new (and exciting !) technologies and approaches by the boatload (see <a href="http://forum.meego.com/showthread.php?t=524">MeeGo Touch</a>, <a href="http://labs.trolltech.com/page/Projects/Graphics/Kinetic/DeclarativeUI">QML</a>, etc). This not unlike what <a href="http://www.android.com/">Android</a> was/is doing - a <a href="http://www.trustedreviews.com/mobile-phones/news/2010/06/02/Google-VP--Android-Updates-Will-Slow-to-One-Per-Year/p1">forced growth</a> where the race is on to pump R&D *before* the large footprint of deployed tech becomes a maintenance nightmare. On the flip side, this makes developers reluctant to write for *current* stable releases as stable is a mostly-working-kind-of-stable and they know not only there is something new and shiny coming up (it always is), but that it is coming *soon*.<br />
<br />
<br />
<b>Desktop vs Mobile</b><br />
<br />
The long and successful history of Qt means there are (tens of) thousands of developers fairly familiar with Qt. However, this does not translate to mobile applications galore for several reasons. First of all, those people need to be motivated to write high quality mobile apps. They will not start to develop for mobile devices just because they are there, not any more than an <a href="http://java.sun.com/javaee/">enterprise Java</a> developer would drop everything to make <a href="http://en.wikipedia.org/wiki/MIDlet">midlets</a>. Sure, if someone is already familiar with a technology, that person will likely use it in it’s hobbies too - and that’s it, "desktop Qt people" are NOT the base that will spawn the bulk of serious mobile Qt developers/companies - those people will come from people with existing mobile background or interests. This seems to be slowly being realized now, as porting tutorials for <a href="http://wiki.forum.nokia.com/index.php/Porting_from_Android_to_Nokia_Platforms">Android</a> and <a href="http://wiki.forum.nokia.com/index.php/Porting_from_iPhone_to_Nokia_Platforms">iPhone</a> started appearing on Forum Nokia. This is an important shift, and while might be characterized as aggressive, it’s exactly those developers that need to be targeted to get the Qt ecosystem on the mobile industry radar.<br />
<br />
<br />
<b>The big GTK+ migration</b><br />
<br />
Since July 2009, it has been known <a href="http://flors.wordpress.com/2009/07/05/maemo-harmattan-keynote-at-gcds/">Qt will take the place of GTK+</a> in Maemo/MeeGo. To be precise, this is not as much about GTK+ itself, but about the GTK+ based <a href="http://en.wikipedia.org/wiki/Hildon">Hildon </a>application framework, initially developed by Nokia. It is understandable that such a major change touches on many existing developers and that such transitions are always difficult to manage. However, there were a lot of indecision and mixed signals from both Nokia and the community as to what exactly should be done "for now" and "for the future", what is or isn’t available in Qt and just how important it is for Qt to mimic/fit in the existing, but deprecated Hildon environment. In retrospect, once the strategic choice of going Qt was made, the push for Qt should have been much stronger, helped with migration plans/tutorials for existing developers.<br />
<br />
<b>The big Symbian migration</b><br />
<br />
Almost literally the same applies to Symbian people. While nowadays it will be hard to find large gangs of fierce <a href="http://en.wikipedia.org/wiki/Avkon">AVKON</a> supporters and the <a href="http://developer.symbian.org/wiki/index.php/Migrating_to_the_Symbian_Foundation_Platform#Cross-Platform_APIs">public/private API</a> approach of Symbian, there is still a significant "why do we need Qt" notion. It has to be made clear AVKON is dead and, again, just as with GTK, handing out Qt tutorials that start from scratch will not help as much as good, targeted migration plans/tutorials for Symbian people. Just putting Qt on a Symbian handset preinstalled will NOT be a sufficient motivator for existing developers.<br />
<br />
<br />
<b>New vs existing developers </b><br />
<br />
As seen from my stance in the "desktop vs mobile" section, it is clear why I think people already doing or interested in apps for mobile devices are important, and there has simply not been a widely successful effort (yet) to help ease people into Qt’s way of doing things. This is well illustrated in the experience with Maemo - most Qt apps were written by people who came to Maemo *first* and *then* started doing Qt.<br />
<br />
<b>You have Python - use it. </b><br />
<br />
There are two Python binding projects available for Qt, both open source but neither have the status of being an "official" Nokia binding and Ovi not supporting Python apps at all. Again, from Maemo experience we see that there is a huge interest in these because even with the limited documentation and support available the number of Python apps is comparable to the number of pure C++ Qt apps due to the low entry barrier of Python.<br />
<br />
<b>TIMTOWDI<a href="http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it">*</a></b><br />
<br />
Some people will snarl at this, but.. there are simply too many ways to do things. Or, rather, there aren't (sufficiently) recommended ways of doing things. Quality training material is starting to appear, but any time somebody asks how do I do a GUI there needs to be a longish discussion as to what version is being targeted, what tools are acceptable, etc, etc. If there are 5 ways of popping up a Hello World dialog (many of them quite 'old school'), know that people WILL get lost or at least discouraged when they try do merge docs from all over the net.<br />
<b><br /></b><br />
<b>Show me the money</b><br />
<br />
As seen/heard from many professional (as in for-money) developers on various Maemo forums, they do not really care about Qt. Sure, it’s cool and a lot friendlier than some previous approaches, but the ultimate test for them is the market. If a super-appstore existed and it required you to code in assembler, it wouldn’t matter much, these guys would just bite the bullet and do it that way. The morale ? Technical merit seems to influence adoption rate a lot less that many believe and the primary aspect are really cost and perceived benefit. Let me emphasize - this only applies to large-scale commercial development, FOSS and hobby coders *will* be affected a lot more. And while we are talking about money...<br />
<br />
<b>The closed door</b><br />
<br />
One of the lures of application stores is that they are simple to use, accessible to one-man-show developers, and, well, 'just work'. Unfortunately, Ovi was not really ready for the Qt apps (or the N900) in the planned 'end of 2009' timeframe - whether they had more important things to do or more important holes to fix, I wouldn’t know. In any case it took a hefty extra 6 months until you could actually submit Qt applications to Ovi, and the Ovi QA process for these is still trailing the community QA process in many ways.<br />
<br />
<b>Chuck Norris releases PR1.2</b><br />
<br />
Well, at least for onlookers it felt like it would take Chuck Norris' superpowers to get the infamous PR1.2 firmware released for the N900. This alone was not a problem, firmware delays happen, but the bundled nature of firmwares meant that Qt4.6 that was ready at the end of March could not be distributed until the end of May, a 2 month delay for no reason at all. On a side note, due to bad communications, this issue caused an outage of several weeks for community developers unlucky enough to depend on packages that have been changed in the update. While this particular incident was Maemo-specific, the Symbian counterparts are not immune to such risks.<br />
<br />
<br />
So, does all this mean Qt is doomed, the future is grim and is all hope lost ? Not at all, as you might have noticed, many of the issues are growing pains, have already been resolved, or are at least in the phase of being taken care of. The change that is going on is really huge, a lot bigger than a lot of people realize, however, it would be not be sincere to say all will be peachy from here on. Even though the time for reaping the benefits is finally closing in, there are a few points that need to be addressed before Qt becomes a no-brainer for both commercial and community development and all those apps start pouring in. Tune in for for the final, third part of this series to see what these are.Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com9tag:blogger.com,1999:blog-6092313305577856947.post-45823789505675834092010-07-09T23:10:00.004+02:002010-07-09T23:38:37.293+02:00So, where are those mobile Qt apps ? (Part 1, History)As part of a testing and compatibility effort, <a href="http://www.noka.com/">Nokia</a> announced Qt to be officially available on <a href="http://maemo.nokia.com/">Maemo 5</a> (i.e. the Nokia N900) on the Maemo Summit in October 2009. A lot of time has passed since then, and despite the sizeable Qt developer community and popularity of Qt on desktops, the number of Qt applications remained fairly low. This is true for both among the (admittedly few) commercial apps and in the (thousands strong) Extras community repository. In this three part blog series I’ll try to analyze what are the causes for this shortage and what needs to be done to remedy this situation lest it continue onto MeeGo and future Symbian versions.<br />
<br />
This series consists of three parts (yes, I finally realized my posts are too long) :<br />
<br />
<ol>
<li>History - the timeline of Qt with regard to Symbian and Maemo/MeeGo</li>
<li>Adoption - describing what problems have hindered a "more than words" Qt adoption so far</li>
<li>Resolution - what are the remaining logjams and how to break them</li>
</ol>
<br />
As described above, in this part, I’ll write about the history of the Qt timeline in Maemo/MeeGo in order to gain some perspective:<br />
<br />
<ul>
<li><b>2008 Jan</b> - Nokia <a href="http://www.nokia.com/press/press-releases/showpressrelease?newsid=1185531">buys</a> <a href="http://en.wikipedia.org/wiki/Qt_Development_Frameworks">Trolltech</a> (makers of Qt) </li>
<li><b>2008 Apr</b> - Qt support for Maemo is <a href="http://maemo.org/news/announcements/qt_to_be_supported_in_addition_to_gtk/">announced</a></li>
<li><b>2008 Oct</b> - First Android <a href="http://en.wikipedia.org/wiki/HTC_Dream">handset released</a></li>
<li><b>2008 Dec</b> - Qt4.5 becomes available as a community edition for Maemo 4.1</li>
<li><b>2009 May</b> - Symbian^4 <a href="http://www.allaboutsymbian.com/news/item/9409_More_on_Symbian_release_plans-.php">deprecates</a> AVKON and carbide C++ in favor of Qt4.6 and the Nokia Qt SDK</li>
<li><b>2009 Jul</b> - Qt4.6 is <a href="http://flors.wordpress.com/2009/07/05/maemo-harmattan-keynote-at-gcds/">announced</a> as the base application framework of Maemo 6 (Harmattan)</li>
<li><b>2009 Oct</b> - Official Qt support (4.6 for 2010Q1) <a href="http://blogs.forum.nokia.com/blog/kate-alholas-forum-nokia-blog/2009/10/20/maemo-qt-and-maemo-summit">announced</a> for Maemo 5 on the Maemo Summit, and beta made <a href="http://labs.trolltech.com/blogs/2009/10/09/qt-on-the-n900">available</a></li>
<li><b>2009 Nov</b> - The N900 <a href="http://www.linuxfordevices.com/c/a/News/Nokia-N900-ships/">ships</a> with the not-overly advertised community Qt4.5 version, first post-ARM11 Android 1.6 is <a href="http://en.wikipedia.org/wiki/Motorola_Droid">released</a></li>
<li><b>2010 Jan</b> - Stable Python Qt bindings are <a href="http://forums.internettablettalk.com/showthread.php?s=3d53f32b5fe63a5fbd4b64211a4d4676&t=42754">released</a></li>
<li><b>2010 Feb</b> - Nokia and Intel <a href="http://conversations.nokia.com/2010/02/15/nokia-and-intel-create-meego-for-new-era-of-mobile-computing/">announce</a> MeeGo, <a href="http://blogs.forum.nokia.com/blog/nokia-developer-news/2010/02/23/qt-4.6.2-announced-with-smart-installer-other-new-features">Qt4.6.2 released with Smart Installer beta</a> allowing install of Qt apps to existing S60 devices </li>
<li><b>2010 Apr</b> - The Nokia N8 is <a href="http://blogs.forum.nokia.com/blog/forum-nokia-web-developer-alert/2010/04/29/nokia-n8-with-symbian-3-qt-4.6-and-flash-lite-4.0">announced</a>, the first Symbian^3 handset that will ship with Qt4.6 preloaded, bridging old AVKON based S60 and the future Qt based Symbian^4</li>
<li><b>2010 May</b> - After much delay, the PR1.2 firmware for the Nokia N900 is <a href="http://conversations.nokia.com/2010/05/25/nokia-n900-software-update-release-1-2/">released</a> with Qt4.6.2</li>
<li><b>2010 Jun</b> - <a href="http://conversations.nokia.com/2010/06/23/developer-announcements-to-boost-nokia-app-marketplace/">The Nokia Qt SDK is released and Ovi store starts accepting Qt apps </a></li>
</ul>
The <a href="http://qt.nokia.com/">Qt toolkit</a> is one of the pivotal points of Nokia’s future strategy as it will be the base of it’s <a href="http://www.meego.com/">MeeGo</a> handheld user experience and also the umbrella that will unite <a href="http://www.symbian.org/">Symbian</a> and MeeGo from an application developer perspective in the future. We can see that this is no short term plan - it took quite some time to arrive here. Just to put things into perspective I included a few Android events. This should also make it clear how "new" the Android arrival is and how it hardly fits the Qt strategy on the platform level - though I would still like to see Qt apps on Android.<br />
<br />
In any case, seeing the timeline it is obvious that the Qt strategy was not a whim, it was a broad, consistent strategy. Qt has come a long way, it has been available to developers living on the mobile edge for well over a years (and two decades for those that are familiar with Qt from the desktop). It fought it’s way to actual devices and stable repositories (an install base of several million handsets via the Smart Installer and the N900 since PR1.2). Ovi now accepts Qt apps. The Nokia Qt SDK is released with the nifty QtCreator IDE largely reducing the pains of the powerful-but-linux-guru-oriented scratchbox environment of the Maemo SDK. The Qt API is a lot friendlier than the AVKON APIs or the generic rag-tag Linux APIs ever were. There are already thousands of developers (both FOSS and commercial) with a lot of previous Qt experience. Qt is touted as the future of all Nokia smartphones. We should be swimming in cool Qt apps, right ? Well, sadly, as many N900 owners are painfully aware, that is still not quite the case, and while there are a few community efforts and the telltale commercial app, it’s far from a landrush. In this blog post I have outlined the Qt’s history, it’s promise on mobile platforms and all the good stuff. If you want to know where the sand is slowing the gears down and what both Nokia/Intel <i>and</i> the community can do to unblock the cogs, check back in a couple of days for parts two and three !<br />
<br />Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com5tag:blogger.com,1999:blog-6092313305577856947.post-59878711635569531812010-06-14T19:53:00.010+02:002010-07-09T23:50:54.441+02:00The Ultimate MeeGo DictionaryThere 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:<br />
<br />
<br />
<b>DirectUI</b> - see MeeGo Touch Framework<br />
<br />
<b>DUI</b> - see MeeGo Touch Framework<br />
<br />
<b><a href="http://en.wikipedia.org/wiki/Fremantle_Doctor">Fremantle</a></b> - see Maemo 5<br />
<br />
<b><a href="http://en.wikipedia.org/wiki/Harmattan">Harmattan</a></b> - see MeeGo-Harmattan<br />
<br />
<b>Harmattan UI framework</b> - see MeeGo Touch framework<br />
<br />
<b>Harmattan UX</b> - the user interface and applications of MeeGo-Harmattan.<b> </b><br />
<br />
<a href="http://wiki.maemo.org/MADDE"><b>MADDE</b></a> - <b>M</b>aemo(/MeeGo) <b>A</b>pplication <b>D</b>evelopment and <b>D</b>ebugging <b>E</b>nvironment, offers the following features:<br />
<ul>
<li>Command-line cross-compiling</li>
<li>Multi-platform support (Linux (32-bit/64-bit), Windows, Mac OS X)</li>
<li>Configurable for different targets & toolchains</li>
<li>Client for the device to simplify the development process</li>
<li>Will be used as part of future releases of the MeeGo SDK, along with QEMU, to enable cross-OS development.</li>
</ul>
<b><a href="http://maemo.nokia.com/">Maemo</a></b> - a <a class="mw-redirect" href="http://en.wikipedia.org/wiki/Software_platform" title="Software platform">software platform</a> developed by <a href="http://en.wikipedia.org/wiki/Nokia" title="Nokia">Nokia</a> for <a href="http://en.wikipedia.org/wiki/Smartphone" title="Smartphone">smartphones</a> and <a href="http://en.wikipedia.org/wiki/Internet_Tablet" title="Internet Tablet">Internet Tablets</a>. It was initially based on the <a href="http://en.wikipedia.org/wiki/Debian" title="Debian">Debian</a> <a href="http://en.wikipedia.org/wiki/Linux_distribution" title="Linux distribution">Linux distribution</a>. One of the predecessors of MeeGo, along with Moblin.<br />
<br />
<b>Maemo 5</b> - the default operating system on the <a href="http://en.wikipedia.org/wiki/Nokia_N900" title="Nokia N900">Nokia N900</a>, and current latest stable and independent version of Maemo. Based on the GTK toolkit. Aliases: Fremantle<br />
<br />
<b>Maemo 6</b> - see MeeGo-Harmattan<br />
<br />
<b>Maemo 6 UI framework</b> - see MeeGo Touch framework<br />
<br />
<b>MeeGo</b> - 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 <i>edition</i> 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.<b> </b><br />
<br />
<b>MeeGo Compatible</b> - something that implements the <a href="http://meego.com/developers/meego-api">MeeGo APIs</a>, but is not necessarily based on MeeGo Core (for example Meego-Harmattan).<br />
<br />
<b><a href="http://meego.com/downloads/releases/meego-core-software-platform">MeeGo Core 1.0</a></b> - the base of every MeeGo system (<a href="http://www.blogger.com/"><span id="goog_328073331"></span>diagram<span id="goog_328073332"></span></a>), contains<br />
<ul>
<li>Kernel based on Linux 2.6.33 </li>
<li>DeviceKit and udev for interacting with hardware devices</li>
<li>Modern 2D / 3D graphics stack including Kernel Mode Setting, non-root X</li>
<li>Voice and data connectivity with Connman connection manager, Ofono telephony stack and BlueZ Bluetooth </li>
<li>Qt 4.6</li>
<li>Universal Plug and Play (gUPnP)</li>
<li>Media frameworks</li>
<li>Next generation file system BTRFS, as the default file system</li>
<li>Does NOT contain a user interface or end-user applications !</li>
</ul>
<br />
<b>MeeGo Garage</b> - 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.<br />
<br />
<b><a href="http://meego.com/devices/handheld">MeegGo Handheld</a></b> - MeeGo Core + MeeGo Touch Framework + Reference Handheld UX (not yet released).<br />
<br />
<b><a href="http://wiki.meego.com/ARM/N900">MeeGo Hardware adaptation project for the N900</a></b> - 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 <a href="http://talk.maemo.org/showthread.php?t=53571">project</a> is thus to open as much N900 specific drivers as possible in MeeGo scope.<br />
<br />
<b><a href="http://wiki.meego.com/ARM/N8x0">MeeGo Hardware adaptation project for the N8x0</a></b> - a 'skunkworks' <a href="http://talk.maemo.org/showthread.php?t=48929">project</a> 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.<br />
<br />
<b>MeeGo-Harmattan</b> - 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.<br />
<br />
<b><a href="http://meego.com/devices/netbook">MeeGo Netbook</a></b> - MeeGo Core + Reference Netbook UX<br />
<br />
<a href="http://wiki.meego.com/Getting_started_with_the_MeeGo_SDK_for_Linux"><strong>MeeGo SDK</strong></a> - A software development kit for MeeGo<br />
<br />
<b><a href="http://www.slideshare.net/peterschneider/maemo-6-ui-framework">MeeGo Touch Framework (MTF)</a></b> - 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.<br />
<br />
<b>MeeGo Web RunTime</b> - 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.<br />
<br />
<b><a href="http://moblin.org/">Moblin</a></b> - short for 'mobile <a href="http://en.wikipedia.org/wiki/Linux" title="Linux">Linux</a>', is an <a href="http://en.wikipedia.org/wiki/Open_source" title="Open source">open source</a> <a href="http://en.wikipedia.org/wiki/Operating_system" title="Operating system">operating system</a> and application stack for <a class="mw-redirect" href="http://en.wikipedia.org/wiki/Mobile_Internet_Device" title="Mobile Internet Device">Mobile Internet Devices</a> (MIDs), <a href="http://en.wikipedia.org/wiki/Netbook" title="Netbook">netbooks</a>, <a href="http://en.wikipedia.org/wiki/Nettop" title="Nettop">nettops</a> and embedded devices. One of the predecessors of MeeGo, along with Maemo.<a href="http://en.wikipedia.org/wiki/Moblin#cite_note-0"></a><b> </b><br />
<br />
<b>Moblin 2.1</b> - last stable independent release of Moblin<b> </b><br />
<br />
<b>Moblin 2.2</b> - see Meego 1.0 Netbook<b> </b><br />
<br />
<b><a href="http://www.forum.nokia.com/info/sw.nokia.com/id/e920da1a-5b18-42df-82c3-907413e525fb/Nokia_Qt_SDK.html">Nokia Qt SDK</a></b> - 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)<br />
<br />
<b>Orbit</b> - see UI Extensions for Mobile<br />
<br />
<b><a href="http://labs.trolltech.com/blogs/2009/05/13/qt-declarative-ui/">QML</a></b> - 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+<br />
<br />
<b><a href="http://qt.nokia.com/products/">Qt</a></b> - <b style="font-weight: normal;">a cross-platform application and UI framework</b>. Using <span class="highlightedSearchTerm">Qt</span>, you can write web-enabled applications once and deploy them across desktop, mobile and embedded operating systems without rewriting the source code.<br />
<br />
<b><a href="http://blog.qt.nokia.com/2010/02/15/meet-qt-quick/">Qt Quick</a></b> - 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.<br />
<br />
<b><a href="http://qt.nokia.com/downloads/">Qt SDK</a></b> - The software development kit for the Qt framework<br />
<br />
<b><a href="http://doc.qt.nokia.com/qtmobility-1.0/index.html">QtMobility</a></b> - 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.<br />
<a href="http://www.blogger.com/goog_33601239"><br />
</a><br />
<a href="http://meego.com/devices/netbook/netbook-screenshots"><b>Reference Netbook UX</b></a> - 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.<br />
<br />
<b>Reference Handheld UX</b> - 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.<br />
<br />
<b>Uiemo</b> - see UI Extensions for Mobile<br />
<br />
<b><a href="http://developer.symbian.org/wiki/index.php/Orbit">UI Extensions for Mobile</a></b> - an extension library for <a href="http://developer.symbian.org/wiki/index.php/Qt_Technical_Overview" title="Qt Technical Overview"> Qt</a>, which contains more than 50 UI elements tailored for mobile user experience. There is a <a href="http://developer.symbian.org/wiki/index.php/Proposals_pipeline" title="Proposals pipeline"> proposal</a> to use Orbit and Qt together with <a href="http://developer.symbian.org/wiki/index.php/Direct_UI" title="Direct UI">Direct UI</a> as a replacement for the existing <a href="http://developer.symbian.org/wiki/index.php/S60" title="S60">S60</a> '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<br />
<br />
<br />
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.<br />
<br />
<br />
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).Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com5tag:blogger.com,1999:blog-6092313305577856947.post-32446348982544381402010-06-05T22:39:00.003+02:002010-06-07T13:19:22.746+02:00Much 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.<br />
<br />
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.<br />
<br />
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).<br />
<br />
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).<br />
<br />
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.<br />
<br />
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 <a href="http://www.adobe.com/devnet/devices/articles/content_mobilization_faq.html#q07">minimum hardware requirements, software requirements, etc</a>. 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).<br />
<br />
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 ?<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com0tag:blogger.com,1999:blog-6092313305577856947.post-85078466500459760862010-04-28T11:29:00.001+02:002010-05-06T16:39:54.746+02:00Fighting The Curse Of Plenty: Nokia's Qt SDKOne of the key differences between mobile and desktop development (apart from the obvious GUI stuff) is that applications cover different use cases from their desktop counterparts. How does this difference in application focus and required tool complexity reflect on open, modern, Linux based mobile platforms, and how does Nokia's <a href="http://conversations.nokia.com/2010/04/27/nokia-rolls-out-qt-sdk-for-unified-mobile-developer-experience/">newly announced Qt SDK</a> address this ?<br />
<br />
<a href="http://www.android.com/">Android</a> and <a href="http://developer.palm.com/">WebOS</a> took the top-down approach, and made a streamlined development process heavily based on existing technologies (the Java language in the case of Android and web related tech in WebOS). This allowed for fast application development, leveraging existing developer resources and knowledge for the particular platforms, at the expense of making the jump to native code a bit more difficult or the realm of hackers. The very important lesson here was also that they very successfully hid their Linux roots, not making the Linux heritage a drawback (to the point that very few people will actually regard Android as a Linux mobile platform).<br />
<br />
However, there was another camp, the bottom-up one, with <a href="http://maemo.nokia.com/">Maemo</a>/<a href="http://www.meego.com/">MeeGo</a> and <a href="http://www.limofoundation.org/">LiMo</a> as the more prominent representatives, which promised most of the desktop technologies in a mobile environment. The advantage should have been the obvious 'just apply whatever technology you know', but in reality, this has slightly backfired up until now. While they proved to be a great basis to hack on and immediately took the hearts of many Linux diehards, there was a steep learning curve that was unappealing to many developers with little Linux background. For example, Maemo's <a href="http://scratchbox/">Scratchbox</a> environment and lack of a traditional IDE/SDK are cited being the points where many hobbyist devs gave up on these platforms. In retrospect, these factors sentenced this group of platforms to be seen in the eyes of mainstream end-users as a land of ports and emulators, with the occasional community gem application in the sea of working-but-not-quite-there-yet apps. <br />
<br />
Returning to the title - how does this <a href="http://www.forum.nokia.com/Tools_Docs_and_Code/Tools/IDEs/Nokia_Qt_SDK/">Nokia Qt SDK</a> change any of this, especially with regard to the latter group ? The key is to understand that this is not a classic platform SDK. Let's see what exactly is happening here:<br />
<br />
<ul><li>While the technologies present in the package (Qt, Qt Creator and the cross-compiling tools) are not new by a long shot, this is the first time they start to appear as a cohesive, focused way of creating applications A-Z style. </li>
<li>A classic IDE-style approach is employed that will appeal to many devs used to such tools, while keeping the power of console and functionality of other existing custom tools.</li>
<li>It's a <b>toolkit</b> SDK, not a platform SDK. This in turn allows access to the vast array of various platforms and devices. Currently the focus is obviously on Nokia's Symbian and Maemo platforms, but here's where Qt really shines - you're not learning to code Symbian or code Android stuff. The Qt skills you learn are actually just as applicable to the desktop, whether that be Windows, Linux or Mac. </li>
<li>Multiplatform authoring tools. Currently Windows and Linux, but my guess is that a Mac version could be produced fairly quickly if serious interest appears.</li>
<li>While Qt provides a level of abstraction, the underpinning platform is not being crippled, and thus applications are being able to take full advantage of it.</li>
</ul><br />
As you can see, the goal seems to be to provide a streamlined way of producing modern applications for a range of platforms, while avoiding the dumbing down of platforms to make them fit into a particular mold. I hear you say, okay, so you think this Qt SDK thing will take over the world, right ? Well, while not excluding the possibility, there are a few obstacles that the Qt SDK needs to address before going for world domination in the mobile app development arena:<br />
<br />
<ul><li>Unified (declarative) UI. Cool compilers and cool IDEs do not necessarily mean cool apps. It is paramount that a unified API (based in some form on the Declarative UI of Qt4.7) exists for widgets and app UIs. If each app will have to have it's UI rewritten due do Orbit/DUI/vendor specific/desktop widget issues, that will significantly reduce the appeal of Qt and proliferate curse-of-plenty problems.</li>
<li>Do a final release in a reasonable time-frame. Today we have seen a beta to whet our appetite, but the other tools and platforms have a serious headstart. Winning Symbian folks over is a good start (the <a href="http://blog.qt.nokia.com/2010/04/27/qt-gets-more-mobil/">inclusion of Qt libs on the new Nokia N8</a> will kickstart this process nicely), but the real race is to get on the radar of developers currently under heavy influence by Android and the iPhone.</li>
<li>Go for Android. This topic alone is grounds for another blog post. Technically, it's known to be possible, there is even is a community level <a href="http://code.google.com/p/android-lighthouse/">Qt for Android</a> port floating around. I will not go in the business/technical reasoning of the dangers/wins of such a move (maybe in another post), but I feel that it needs to be kept at least as an option, an ace up the Qt sleeve if you wish. </li>
<li>Add python support. The use of Python Qt bindings has a long and successful history. Python is easy, and on modern hardware, a Python and Qt combination is much less a drag than it ever was on embedded platforms, as proven by <a href="http://www.riverbankcomputing.co.uk/software/pyqt/intro">PyQt</a> and <a href="http://www.pyside.org/">PySide</a> on Maemo. C++ is not everyone's cup of tea, and Python is an excellent complementary language for it, while maintaining a solid Qt based 'upgrade' path should developers need it. Doing this without switching SDKs or IDEs would go a long way of making Qt even more appealing to new developers.</li>
</ul><br />
If you want to take this new SDK for a spin, you can do it <a href="http://www.forum.nokia.com/Tools_Docs_and_Code/Tools/IDEs/Nokia_Qt_SDK/">here</a>.Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com6tag:blogger.com,1999:blog-6092313305577856947.post-81517573142131538022010-04-22T15:00:00.001+02:002010-04-22T15:09:34.057+02:00Operation Qt Shuffle<div style="margin: 0px; text-indent: 0px;">I know you all like (cough) my <a href="http://achipa.blogspot.com/2010/03/harmattan-last-of-maemos-or-first-of.html">long winded</a> and <a href="http://achipa.blogspot.com/2010/03/danger-of-weak-branding-or-which-meego.html">analytical</a> articles, but we'll take a short break from that to allow for a service announcement concerning our busy <a href="http://qt.nokia.com/">Qt</a> developers, <a href="http://maemo.nokia.com/">Maemo 5</a> and your evergreen <a href="http://talk.maemo.org/showthread.php?t=50330">favourite</a> update, <a href="http://wiki.maemo.org/Maemo_5/PR1.2">PR1.2</a>. </div><div style="margin: 0px; text-indent: 0px;"><br />
<br />
</div><div style="margin: 0px; text-indent: 0px;">If you're an end user, the short version is - the doors are open for more (and prettier) apps, plus we have a bridge that will make it easy to backport MeeGo apps to Maemo 5. If you're a developer and/or are interested in the gritty details, read on:</div><div style="margin: 0px; text-indent: 0px;"><br />
<br />
</div><div style="margin: 0px; text-indent: 0px;"><br />
</div><div style="margin: 0px; text-indent: 0px;">[Maemo community council hat]</div><div style="margin: 0px; text-indent: 0px;"><br />
<br />
</div><div style="margin: 0px; text-indent: 0px;">One of the big changes PR1.2 brought us is official Qt support in the form of Q4.6 in the Nokia SDK and repositories. This change affects all applications depending on Qt currently in extras-devel. We had some talks with Qt/Nokia folks about Qt-related repository changes in Maemo 5 (triggered by aforementioned PR1.2 and potentially again later on by updates to Qt or related components). Here is the short summary:</div><div style="margin: 0px; text-indent: 0px;"><br />
</div><div style="margin: 0px; text-indent: 0px;"><ol><li>remove qt4-maemo5 (4.6) after PR1.2</li>
<li>upload Qt 4.7 snapshots as qt4-experimental to extras-devel afterwards</li>
<li>as soon as 4.6 QtMobility is released, get those packages to the nokia-apps repository</li>
<li>remove 4.6 QtMobility from extras-devel</li>
<li>maybe upload new QtMobility packages to extras-devel, but only for qt4-experimental (4.7) and with 'experimental' in the package name</li>
<li>maintainers of bindings and extensions to Qt are encouraged to follow the same nomenclature in their package names (i.e. using experimental in the name if depending on qt4-experimental)</li>
<li>use a Provides/Replaces/etc libqt4-maemo5 clause in the qt4-experimental packages (Qt4.7 packages should be binary compatible with the current 4.6 ones) so the packages can be deprecated peacefully</li>
<li>QML/declarative will be released as part of Qt4.7 (so qt4-experimental only, no 4.6.2/PR1.2 support)</li>
</ol></div><div style="margin: 0px; text-indent: 0px;"><br />
</div><div style="margin: 0px; text-indent: 0px;"></div><div style="margin: 0px; text-indent: 0px;"></div><div style="margin: 0px; text-indent: 0px;">[/Maemo community council hat]</div><div style="margin: 0px; text-indent: 0px;"><br />
<br />
What does this mean in plain English ? <b>The libqt4-maemo5-* package names are deprecated in extras-devel</b>. Use <b>libqt4-experimental-*</b> if you need Qt4.7 features, or <b>libqt4-*</b> if you want Qt4.6. Qt4.5 will no longer be supported after the release of PR1.2<br />
<br />
<br />
</div><div style="margin: 0px; text-indent: 0px;">Have a nice day ! </div><div style="margin: 0px; text-indent: 0px;"> </div>Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com4tag:blogger.com,1999:blog-6092313305577856947.post-40678186210496094152010-03-28T11:55:00.004+02:002010-03-28T19:19:04.757+02:00Busy week in Nokia landThe following week is shaping up to be a very busy one for Nokia. Starting today, there is a (largish) <a href="http://blogs.forum.nokia.com/blog/ovi-publisher-alert/2010/03/26/scheduled-maintenance-for-ovi-store-and-publishers-from-3-28-3-29">scheduled maintenance</a> in the Ovi Store, nearly two days for publishers and most of Monday for end-users. There were hints of some major spring Ovi improvements in the past months, let's hope this maintenance introduces at least some of the new & improved functions.<br />
<br />
The second (even bigger) event will be the first MeeGo code drop (a technical preview release for developers), also known as "Day One", which is <a href="http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-03-24-19.58.log.html">scheduled for Wednesday</a> (search for March 31), and also a <a href="http://meego.com/community/events">TSG meeting</a> later that day.<br />
<br />
Last, but not least, while not really announced, the <a href="http://wiki.maemo.org/Maemo_5/PR1.2">Nokia N900 PR1.2 firmware </a>release, probably the most important one so far (as it brings all-important official Qt4.6 compatibility) could easily happen this week. The early access PR1.2 SDK has been released a week ago, and the autobuilders on maemo.org have already been transitioned to PR1.2, so the firmware itself can't be far.<br />
<br />
The MeeGo release is certainly the most important of all these events, so prep your hacking skills, you're going to be able to put them to good use in just a few days !<br />
<br />
EDIT: As pointed out below, this week will also see the election of the <a href="http://wiki.maemo.org/Community_Council">Maemo Community Council</a>, which while not strictly a Nokia activity, still plays an important role in the Maemo world. If you are a Maemo community member and have received a voting token, take a gander at the <a href="http://wiki.maemo.org/Community_Council/Candidate_declarations_for_March_2010">candidate list and their programs</a> and make sure the candidates who you think are best take the seats!Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com2tag:blogger.com,1999:blog-6092313305577856947.post-66117452569835809572010-03-28T10:00:00.004+02:002010-03-28T19:31:58.070+02:00Harmattan: Last of the Maemos or First of the MeeGos ?It has been over a month now that <a href="http://www.meego.com/">MeeGo</a>, Nokia's and Intel's joint mobile linux effort has been announced. The original formula was for <a href="http://maemo.nokia.com/">Maemo</a> 6 (also known as Harmattan) and <a href="http://www.moblin.org/">Moblin</a> 2.2 to merge, and form a Maemo 1.0 in the next iteration. This was cool and was generally well accepted (except for a few not too well communicated points like <a href="http://meego.com/about/faq">switching from Maemo's DEB to Moblin's RPM</a>). Let's delve into the branding/community aspect of Harmattan, the upcoming protoMeego!<br />
<br />
The Maemo 6 device is not even out yet, only announced for the second half of 2010. So, how does one prevent the <a href="http://en.wikipedia.org/wiki/Osborne_effect">Osborne effect</a>? Well, the immediate, and understandable reaction was dropping the Maemo 6 brand for Harmattan. This seemed a bit of a middle ground, but it is evident that most people have never heard about Harmattan and will have trouble placing it in the correct position with regard to Maemo and MeeGo, so later a MeeGo / Harmattan name started appearing. In interviews and blogs, even <a href="http://jaaksi.blogspot.com/2010/02/meego-time.html">top Nokia folks regarded Harmattan as MeeGo compatible, or an instance of MeeGo</a>. In theory, if a device implements the MeeGo API, it is MeeGo device, if it doesn't, well, then it isn't. What does this mean in practice? Hard to tell, unfortunately. The first problem is that the MeeGo API itself has not yet been publicly released, only outlined in a very rough architectural sketch. Furthermore, as discussed in my previous article, this Harmattan / MeeGo is not the MeeGo the N900 users (think they) will be getting. Many of you will say, why does it matter? If the SDK helps overcoming the RPM/DEB divide, isn't it pointless to point out "differences is obscure middleware components"? Well, sadly, the question is a lot more complex than that.<br />
<br />
Arguably one of the biggest differentiators and unique aspects of the Maemo platfom is/was the well organized community at <a href="http://maemo.org/">maemo.org</a>. Many of you unfamiliar with the inner workings might think it's just a <a href="http://talk.maemo.org/">forum</a> or a <a href="http://maemo.org/downloads">download portal</a> of some sort, but in reality, it's almost a country of it's own. It encompasses several communication media, from forums through blogs to mailing lists, documentation and the complete community development and distribution process (which accounts for 95% of available software for Maemo devices). Another way this little country is unique is that is has elected representatives, and encompasses all sorts of users, from casual surfers through power users to hardcore developers - something very few communities of this size manage to do. This makes maemo.org and everything it stands for an invaluable asset of the Maemo platform. What does this mean with regard to Harmattan?<br />
<br />
I hope the problem is starting to become apparent - by pushing Harmattan users into the meego.com fold, they will miss out the experience and momentum maemo.org has. At the same time, there will be a realization that the only thing in common with their Intel, LG, etc 'neighbours' at meego.com is the name itself - they will be using a different package format, different repositories, different DRM, different architecture, different (but similar) APIs, different application store and IMO it won't be long before it will be perceived as a MeeGo stepchild and the Harmattan section will be littered with 'when will the Harmattan device get a real MeeGo?' or 'why does everything have to work differently on Harmattan?' threads. <br />
<br />
Okay, I hear you say, then they just integrate it with maemo.org and let it live through it's protoMeeGo days along with it's N8x0 and N900 predecessors until it really gets to be MeeGo 1.0. Unfortunately, that's not a decision without drawbacks, either. Right off the bat, there is the marketing problem of this making saying it somehow 'old', obsolete. In reality, it's not Harmattan that is obsolete, I feel that it was the MeeGo announcement that was in many ways premature as it is really something that affects the 2011 time frame of devices, anything before that will be MeeGo in name, not essence. And this brings us to the second problem of this approach - if the community coming with the Harmattan device is part of the Maemo community, there will be no substantial (read: one including end-users) Nokia device community present on meego.com until well into 2011 and the first 'designed for MeeGo' devices.<br />
<br />
What's the solution, then? Harmattan is in a tough spot, Nokia aiming for high and noble long term goals, but that does not ease necessary near-term choices (especially considering they already made the most important one - going forward with Harmattan as planned regardless of MeeGo). I already talked about the branding problems - this is something only Nokia can decide on. On the platform side, I feel the maemo.org community can help, but solid bridges need to be built between maemo.org and meego.com, to allow for users to harness present-day community resources and experience, at the same time allowing them to grow/migrate into meego.com when the time is right. Trying to push them into a future meego.com infrastructure now could easily hurt Harmattan (and indirectly Nokia's own long term MeeGo) efforts. <br />
<br />
DISCLAIMER: A lot of things about MeeGo are in flux, things becoming more clear when the first Harmattan and MeeGo SDKs are released (this should happen in just a few weeks). I'm pretty certain there will be updates based on those coming for my little analysis above, so let's see what the future (and various MeeGo stakeholders) hold !Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com7tag:blogger.com,1999:blog-6092313305577856947.post-76970207954717773582010-03-25T14:29:00.004+01:002010-03-26T16:13:00.094+01:00The danger of weak branding or: which MeeGo is the real MeeGo?By following various blogs and forums, it occured to me there is quite a confusion as to what actually <a href="http://www.meego.com/">MeeGo</a> is. The basic idea, <a href="http://conversations.nokia.com/2010/02/15/nokia-and-intel-create-meego-for-new-era-of-mobile-computing/">announced in Barcelona</a> during the MWC, was to have <a href="http://maemo.org/">Maemo</a> and <a href="http://moblin.org/">Moblin</a> merged into a new OS called MeeGo. So far so good (number of MeeGos: 1). However, recently Nokia re-branded Maemo 6 as MeeGo / Harmattan, which uses a different package format, repositories, so not quite the same MeeGo that was originally announced, despite the general similarity (number of MeeGos: 2). In the same vein, Moblin folks started calling Moblin 2.2 simply MeeGo (number of MeeGos: 3). But wait, the plot thickens! It has recently been confirmed that the N900 will be Nokia's reference platform for ARM-based MeeGo devices. Now, this is closest to the MWC MeeGo, but is just a developer reference platform, not something that end users are expected to install/use (number of MeeGoos: 4). Getting dizzy? Take a look at meego.com, you'll see that MeeGo also intends to provide separate versions (as in different user experience) of MeeGo not just for Pocketables. There will be distinct editions for Netbooks, Media Phones, TVs, In-vehicle devices and, as you probably guessed it by now, they're all called MeeGo (number of MeeGoos: 5, 6, 7, 8). So the next time somebody asks for or talks about MeeGo, make sure it is clear what the object of the talk is, lest the discussion turn into <a href="http://www.urbandictionary.com/define.php?term=marklar">Marklar</a>.<br />
<br />
This problem has been usually tackled by subbranding, for example <a href="http://www.ubuntu.com/">Ubuntu</a> very successfully uses names like KUbuntu, XUbuntu, Edubuntu, Ubuntu Netbook Remix, etc. Why is this so important you ask? MeeGo targets a very wide range of devices and users, far more diverse than Ubuntu. By allowing everything to be called MeeGo, despite having different UIs, architectures, application stores, DRMs, APIs, packaging systems and repositories, MeeGo becomes a weak brand. It will no longer be important whether something is MeeGo as it provides no guarantee of anything except for a generic <a href="http://qt.nokia.com/">Qt</a> based compatibility (which means little to end-users). It's crucial this branding mess gets cleared up by the powers that be before the first releases are made and the first devices hit the streets, otherwise MeeGo (all 8 of them if I counted correctly) risks going from a strong distribution brand for the embedded industry to being just a generic synonym for 'Linux with Qt'.Attila Csipahttp://www.blogger.com/profile/11082060370940070595noreply@blogger.com16