Mardy (Articoli su Nokia)http://mardy.it/it/categories/nokia.atom2024-02-02T20:10:58ZAlberto MardeganNikolaIntroducing Mappero Geotaggerhttp://mardy.it/it/blog/2012/08/introducing-mappero-geotagger.html2012-08-23T19:05:00+04:002012-08-23T19:05:00+04:00Alberto Mardegan<div style="float: right;"><a href="http://www.mardy.it/archivos/imagines/mappero-geotagger.png"><img src="http://www.mardy.it/archivos/imagines/mappero-geotagger.png" width="400px"></a></div>
<p>A few days ago I published the first version of <a href="http://www.mardy.it/mappero-geotagger">Mappero Geotagger</a>, an open source geotagging application for Linux, Mac OS X and Windows.</p>
<p><em>Geotagging</em> a file means assigning a geographic location to it, and it's an action typically performed on picture files, so that the geotagged photo can be shown on a map at the location where it was taken. Many photo-sharing websites, like for instance <a href="http://flickr.com">flickr</a> and <a href="http://picasa.google.com/">picasa</a>, will show your pictures on a map, as you can see for example <a href="http://www.flickr.com/photos/mardytardi/2915024236/in/set-72157607758948089">in this picture</a> of mine. Some services also allow you to view all photos taken in a certain area; for instance, here are some nice pictures taken in <a href="http://www.flickr.com/map?&fLat=60.3834&fLon=25.6776&zl=13">Porvoo</a>, Finland.</p>
<p>Mappero Geotagger is a simple graphical tool to geotag your photos. You can manually move pictures on the map to set or change their location (removing the geotag is also possible) or, if you happened to record your way with a GPS while you took the pictures, the program can automatically correlate the time of the photos with the time of the GPS signal, and therefore establish with a certain precision where the pictures where taken. Since the time of the GPS receiver and the time of your camera might differ (and usually they do, especially if you travel to a different time-zone and forget to update the time in one of your devices), Mappero Geotagger has some controls to allow you to smoothly adjust the time difference and provides you an immediate feedback as you'll see the images being laid out on the map along the GPS track. The video below should give you a better idea of how this works:</p>
<div style="text-align: center; margin: 0 auto;"><iframe width="560" height="315" src="http://www.youtube.com/embed/b1J84dISuNk?rel=0" frameborder="0" allowfullscreen></iframe><br><small>See Mappero Geotagger in action</small></div>
<p>I'm selling the application <a href="http://www.mardy.it/mappero-geotagger">from my website</a> for 15€, but if you hurry up and either <a href="http://twitter.com">tweet</a> or mention it in <a href="http://plus.google.com">Google+</a> you can have it for 5€ only — and <b>if you blog about it, you'll get it for free</b>. Detailed info on the promotion are <a href="http://www.mardy.it/mappero-geotagger#promotions">here</a></p>
<p>Incidentally, if you own a Nokia N9 or N900, the source code which you will get when purchasing Mappero Geotagger can also be compiled for these phones, into an application (still under heavy development, but already usable) which lets you record a GPX track usable with Mappero Geotagger.</p><div style="float: right;"><a href="http://www.mardy.it/archivos/imagines/mappero-geotagger.png"><img src="http://www.mardy.it/archivos/imagines/mappero-geotagger.png" width="400px"></a></div>
<p>A few days ago I published the first version of <a href="http://www.mardy.it/mappero-geotagger">Mappero Geotagger</a>, an open source geotagging application for Linux, Mac OS X and Windows.</p>
<p><em>Geotagging</em> a file means assigning a geographic location to it, and it's an action typically performed on picture files, so that the geotagged photo can be shown on a map at the location where it was taken. Many photo-sharing websites, like for instance <a href="http://flickr.com">flickr</a> and <a href="http://picasa.google.com/">picasa</a>, will show your pictures on a map, as you can see for example <a href="http://www.flickr.com/photos/mardytardi/2915024236/in/set-72157607758948089">in this picture</a> of mine. Some services also allow you to view all photos taken in a certain area; for instance, here are some nice pictures taken in <a href="http://www.flickr.com/map?&fLat=60.3834&fLon=25.6776&zl=13">Porvoo</a>, Finland.</p>
<p>Mappero Geotagger is a simple graphical tool to geotag your photos. You can manually move pictures on the map to set or change their location (removing the geotag is also possible) or, if you happened to record your way with a GPS while you took the pictures, the program can automatically correlate the time of the photos with the time of the GPS signal, and therefore establish with a certain precision where the pictures where taken. Since the time of the GPS receiver and the time of your camera might differ (and usually they do, especially if you travel to a different time-zone and forget to update the time in one of your devices), Mappero Geotagger has some controls to allow you to smoothly adjust the time difference and provides you an immediate feedback as you'll see the images being laid out on the map along the GPS track. The video below should give you a better idea of how this works:</p>
<div style="text-align: center; margin: 0 auto;"><iframe width="560" height="315" src="http://www.youtube.com/embed/b1J84dISuNk?rel=0" frameborder="0" allowfullscreen></iframe><br><small>See Mappero Geotagger in action</small></div>
<p>I'm selling the application <a href="http://www.mardy.it/mappero-geotagger">from my website</a> for 15€, but if you hurry up and either <a href="http://twitter.com">tweet</a> or mention it in <a href="http://plus.google.com">Google+</a> you can have it for 5€ only — and <b>if you blog about it, you'll get it for free</b>. Detailed info on the promotion are <a href="http://www.mardy.it/mappero-geotagger#promotions">here</a></p>
<p>Incidentally, if you own a Nokia N9 or N900, the source code which you will get when purchasing Mappero Geotagger can also be compiled for these phones, into an application (still under heavy development, but already usable) which lets you record a GPX track usable with Mappero Geotagger.</p>Nokia and Windows Phone: any light at the end of the tunnel?http://mardy.it/it/blog/2012/06/nokia-and-windows-phone-any-light-at.html2012-06-29T07:07:00+04:002012-06-29T07:07:00+04:00Alberto Mardegan<p>Just a quick note for all those who believe that the sorts of Nokia
depend on the success of Windows Phone 8: it mostly doesn't.
Provided that Nokia survives till the moment when Windows Phone 8
based phones are available, here's what I believe will happen then:</p>
<ul>
<li>Nokia regains some market share by selling smartphones based on WP8.
</li><li>Samsung, LG, HTC and other phone manufacturers join the WP8 party.
</li><li>Nokia is not able to differentiate enough, loses market share and is
forced to lower the selling prices, therefore shrinking the profit
margins.
</li><li>With the most generous prediction, Nokia market share will be of
10%, with minimal operating profit, compared to a market share of
about 40% it had before the Windows Phone madness started.
</li></ul>
<p>(this is all assuming that WP8 will be a success)</p>
<p>Good luck with Windows Phone, Nokia!<br>
Investors: better hope that WP8 will be a failure - then your stocks
will definitely grow in value!</p><p>Just a quick note for all those who believe that the sorts of Nokia
depend on the success of Windows Phone 8: it mostly doesn't.
Provided that Nokia survives till the moment when Windows Phone 8
based phones are available, here's what I believe will happen then:</p>
<ul>
<li>Nokia regains some market share by selling smartphones based on WP8.
</li><li>Samsung, LG, HTC and other phone manufacturers join the WP8 party.
</li><li>Nokia is not able to differentiate enough, loses market share and is
forced to lower the selling prices, therefore shrinking the profit
margins.
</li><li>With the most generous prediction, Nokia market share will be of
10%, with minimal operating profit, compared to a market share of
about 40% it had before the Windows Phone madness started.
</li></ul>
<p>(this is all assuming that WP8 will be a success)</p>
<p>Good luck with Windows Phone, Nokia!<br>
Investors: better hope that WP8 will be a failure - then your stocks
will definitely grow in value!</p>From G to Qhttp://mardy.it/it/blog/2012/05/from-g-to-q.html2012-05-18T17:33:00+04:002012-05-18T17:33:00+04:00Alberto Mardegan<p>I decided to blog about my experience of transitioning from being a GLib and GObject enthusiast to a Qt (and QML) fanboy. :-) I'm not writing this with any specific goals, other than sharing my own experience and hopefully making the life of those developers who are forced to learn and use Qt less painful and a bit more rosy; in particular, I'm not trying to be a Qt evangelist here and convince you, hardcore GObject developer, to switch to Qt: I'm indeed sure that if my current self tried to talk my 3 years younger self into Qt, it would be a useless and tiresome (and maybe violent ;-)) discussion.</p>
<p>Just a bit of background on myself: I've been developing on Linux and Unix for more than 10 years now, mostly using GObject based libraries, such as Gtk+. I had a short encounter with Qt in about 2004, just for a few weeks, which left me with a bad impression (mostly because of the <a href="http://qt-project.org/doc/uic.html">uic</a>). Other than that, I was simply not interested in Qt, mostly because I hate C++ and love C and anyway all my needs were perfectly met by GLib, GObject and Gtk+. I remember that the first time when I read about GObject, I was fascinated: the power of OO programming on top of my favorite language, all open source and hackable. In autumn 2006 I started a new job in Nokia, in the <a href="http://maemo.org">maemo</a> team, working on a middleware component in the <a href="http://telepathy.freedesktop.org/wiki/">Telepathy</a> VoIP framework; I enjoyed it a lot, and (if possible) grew even more fond of GObject and GLib. On early 2008, the big news: Nokia acquires Trolltech (the SW house developing Qt); for me, as for most of the people working in the <i>maemo</i> team, this came as a complete surprise, and not as a really good one. Indeed, we were afraid that we would have to abandon the C/Gtk+ work and switch to C++/Qt — perhaps not coincidentally, several GNOME developers working in Nokia even left the company around that time. Luckily though, nothing really changed for us for more than one year, and even later, when more people joined to work on Qt-related stuff and I moved to another project, I could still avoid touching Qt code and continue using only my beloved GObject. However, <em>like all good dreams, this also came to an end</em>: eventually, I had to refresh my C++ knowledge and change my most typed character from "g" to the hated "q".<br>
So, here my Q story begins.</p>
<h3>The first prolonged exposure to Qt</h3>
<p>It was painful. My first task was to create Qt-bindings for the GLib-based library I was developing. There was no UI involved, so on the tools front the experience was not as bad as I remembered; but on the pure programming side, I was horrified: I felt extremely limited, many programming paradigms I was used too couldn't be applied, or I was just told (by people more expert in Qt) that “you shouldn't do like that, it's not the Qt way!”. Urgh.</p>
<p>The biggest issues I had were the lack of reference counting in QObject (!!) and the veto on using C-style function callbacks for asynchronous operations (you <em>should</em> use Qt <i>slots</i>, and in order to have a slot you <em>must</em> have a receiving QObject). How could I take Qt seriously? Sure, there were also a few nice things about it, like the fact that QObject comes with child-parent lifetime handling out of the box (when a parent object dies, all of its children are automatically deleted), and that signal connections are automatically broken when either the emitter or the <em>receiver</em> object dies (yay, no more explicit signal disconnections — or random crashes!). But still, this could in no way compensate for the lack of the other low-level features I was used to.</p>
<p>I cannot really say that I enjoyed the first months of using Qt. I was still trying to work as much as possible on the GLib-based parts of the project, and twisting my head around to figure out what was “the Qt way” of doing all the things that I was used to do almost instinctively with GLib/GObject.</p>
<h3>From hate to love</h3>
<p>Now that I think back and try to find the moment of time when I finally started liking Qt (or just not dislike it too much), I cannot really point out a definite time. It was a very slow process, that surely wouldn't have completed if I hadn't been forced to use Qt because of my work. But indeed, the moment when I realized that Qt was not so bad after all is when I started writing new original code with it. In retrospection, I would say that my experience with Qt was so bad because I started with a completely wrong task: as an inexperienced Qt developer, creating binding for a GObject-based library couldn't possibly make me appreciate Qt; I was just bound to notice all the GObject features that were not present in Qt, and suffer their absence. And I wouldn't notice almost any of the niceties that Qt offers to application developers, because there is not much code you can write in a wrapper library other than some trivial glue code.<br>
So, my first suggestion for those GObject developers who start using Qt is: <b>do not write a Qt wrapper to your favorite GObject library!</b>, you are going to hate it. Leave it to someone who is more experienced than you in Qt; it can be a very pedagogic task, indeed, but chances are that it will be the last time you are going to use Qt. If you can, start with writing new code.</p>
<p>That said, there is a big difference between not disliking something and loving it. But again, I cannot tell when I started loving Qt. What I surely can tell is when I <em>realized</em> that I loved it: and that was when I started porting some GObject-based code to Qt (not as a line-by-line port, but more like a functional rewrite) and found out that the resulting code was not only more compact and easier to write, but — and especially — easier to <em>read</em>. And of course, when I realized that my enthusiasm was not the same as before, whenever I had to do some programming in C+GObject.</p>
<h3>What I find cute in Qt</h3>
<p>Let me begin with a couple of statements which could dispel some myths or anyway clarify some doubts that the Qt-virgin might hold:</p>
<ul>
<li><b>It's not C++</b>. This is a bold (and false) statement, but it's probably the most effective to convey the idea: if you — like me — hate C++, you won't necessarily hate Qt. Qt's C++ is a subset of C++: although you can use whatever C++ feature you might like, developing with Qt does not involve using exceptions, templates, RTTI and the STL. In a similar way to how GLib and GObject “extend” the C language, Qt uses a preprocessor (called <tt>moc</tt>) to add its own run-time type information (think of GType) and implement the signals/slots mechanism. In the end, you don't need to know all the details of C++ to develop Qt; instead, it's somehow similar to developing Vala code — it's like a programming language of its own.
</li><li><b>It's not just GUI</b>. As you might have noticed, this post is not about Qt vs. Gtk+, not at all. There are many other articles on the web where you can find comparisons and opinions of the two, but what I'm focusing on here is my experience with Qt programming and GNOME programming, and not just at the UI level. So, yes, the point is that you can develop whatever code with Qt (except maybe kernel drivers): I've personally written D-Bus services, command line tools and embedded software using just Qt.
</li><li><b>There <em>really</em> is a Qt way</b>. My disappointment about the lack of reference counting in QObject is now history: apart from the fact that indeed there is one class in Qt which lets you implement reference counting for QObjects, I cannot recall any case where reference counting would have been useful. I know, coming from GObject this might sound hard to believe (especially to my three years younger self, who used to mess up with cross references everywhere in the code), but it's a fact: after some initial struggle, I always managed to design the software with clear ownership of objects, so that the reference counting ended up to be totally superfluous. And in fact, my code is designed better now. The same can be said of any other feature that I initially missed: if it's not there, you can do without it: just restructure your code in a different way — the Qt way — and there's a good chance that while reworking your classes you'll clear up some mess. :-)
</li></ul>
<p>That said, here's a list of things that I came to like about Qt; I'm obviously not mentioning those things that are also in GLib/GObject, unless there are significant differences.</p>
<ul>
<li><b>QObject automatic destruction of children</b>. I already mentioned it before, but it's worth expanding a bit. Quite often I had to use reference counting in my GObject subclasses to keep track of the child-parent relationships; QObject already does that for you: whenever you create a QObject, you can specify one parent object which will “watch” its lifetime and destroy it in its destructor. This leads to a nice programming paradigm where you can create all the objects that your class needs and just use the <tt>this</tt> pointer as parent object: then you don't need to remember destroying them explicitly in your destructor.
</li><li><b>Automatic disconnection of signals when receiver object dies</b>. I also mentioned this before, but <i>repetita iuvant</i>: if you are an experienced C + GObject developer, you <em>must</em> have seen at least once in your programming career one crash due to a signal callback invoked when the objects it operated on had already been destroyed. Of course I know that it never happened to <em>you</em> personally, but you surely saw this in someone else's software. ;-) Well, in Qt this is very unlikely to happen, because (at least till Qt4) it's impossible to bind signals to C callbacks: you must bind them to a QObject method (called “slot”), and the QObject system takes care of disconnecting the signal for you when either the emitter or the receiver object are destroyed.
</li><li><b>QString</b>. I'm sometimes a bit maniacal with micro-optimizations, and one thing I was always trying to optimize in my early GLib days was avoiding string allocations. It really hurts me to write a g_strdup() in a library method's implementation when I could rather write "Please, don't destroy or change @string_param while this object is still alive" in the documentation string for the method. But that's not <em>the GLib way</em> (and indeed, not my way anymore when I write GLib code): you can never know what happens with the string, so it's way safer to incur the small penalty of a g_strdup() than run the risk of a crash which is likely to be very hard to debug. So, C/GLib code is often full with g_strdup() and g_free() (not to speak about valac-generated code!). Enter QString! QString is not only a class that provides a ton of useful string methods, it is an <em>implicitly shared</em> class. That means that the QString structure itself is very small (size of a pointer?), and that the string data is reference counted; then if/when you modify a string which has a reference count higher than 1, the string data is copied and your QString is now pointing at the modified copy. So you never have to worry about copying strings! How cool is that? :-)
</li><li><b>Awesome container classes</b>. Qt comes with a few container classes which you'll surely get to like: <tt>QMap</tt>, <tt>QList</tt> are those that you'll use the most, but then there's also <tt>QSet</tt>, <tt>QQueue</tt>, <tt>QHash</tt>, <tt>QVector</tt> and others. These are template classes, so you can write <tt>QMap<QString,QVariant></tt> and get the equivalent of a <tt>GHashtable</tt> whose keys are strings and values are <tt>GValue</tt>s. Inserting items is as easy as writing
<pre>
QMap<QString,QVariant> map;
map.insert("string", "string value");
map.insert("integer", 12);
</pre>
while to iterate the values you have the handy <tt>foreach</tt> macro, which lets you write
<pre>
foreach (const QVariant &value, map) {
QDebug() << "Value:" << value;
}
</pre>
And if you remember what I wrote above about QString: Qt container classes are implicitly shared too!
</li><li><b>Reduced usage of pointers</b>. This follows in part from the above: QString handles all string pointers for you, and the ease of implementing implicit sharing of container classes makes it so that you will be often passing them by value or by reference. Also, implementing implicit sharing for your own data structures is very easy, and you might prefer investing a little time doing that rather than using raw pointers.
</li><li><b>Class and API offering</b>. Even excluding the GUI classes, the functionality provided by the Qt classes will satisfy the most demanding developer: whether you want to deal with date/time, with network resources, with graphics/images, HTML (webkit), SQL databases, D-Bus, plugins, regular expressions, etc., it's all there, and everything works perfectly together. The APIs are intuitive and clean: you won't find duplicate classes offering the same functionality (unless one is deprecated), and the documentation is excellent.
</li><li><b>Compact and clean code</b>. Qt application code is likely to be much mode compact and clean than GObject code. Just like Vala, imagine removing all GObject casts and using class namespaces to shorten your method names and fit your code in a 80 chars wide editor. :-) Use <tt>const</tt> effectively to mark your class methods and finally be able to pass constant objects and structures around your code, minimizing the risk of incorrect usage.
</li><li><b>QML</b>. This would deserve a chapter on its own, but since there has been quite a lot of buzz around it on the internet I won't spend many words on describing it. Instead, I'll focus on how I came to like it so much. As it often happens with new things, my first impression was not so great; sure, all the QML demos you can find in the internet are extremely captivating, and it's impressive how much you can achieve with very little code — which doesn't even look like real code, but more like a static description. And this was indeed my first doubt: what is the limit of QML? It's a nice language for moving graphics items around, but does it let me do anything more than that? Or: if it really allows me to write complex UIs for big applications, won't the code become a horrible mess to maintain? Again, time and hands-on experience is what changed my mind. I'm porting one map application from Gtk+/Clutter to Qt and of course the map widget and its animations has been my first item in the list. <a href="http://www.clutter-project.org/">Clutter</a> is a fantastic toolkit for producing animated UIs in the GNOME world; the Qt equivalent is QGraphicsView, whose APIs luckily match very close the Clutter ones; so, the porting wasn't that difficult at all, and it didn't took long until I had my widget working. However, for implementing the animations (zoom, panning and rotation of the map) I didn't use the <a href="http://qt-project.org/doc/qt-4.8/animation-overview.html">Qt Animation Framework</a>, which would be the natural equivalent to Clutter animation classes, but instead went for QML: exposing the map properties to QML enables implementing animations in a much easier and enjoyable way. QML property bindings, together with property animation descriptions, empower your application to any kind of smooth animations with almost no effort on your side. You don't have to take care of starting/stopping animations, changing the direction of animations while they are running, or combining zooming/panning/rotation at overlapping moments: no matter how crazily the user plays with your UI, all animations happen as expected, without any need for you to special code them. I couldn't help falling in love with QML. :-)<br>
So, my answers to the above questions are that, first of all, QML is a language especially designed for developing UIs and UI logics. There's not much else that you can do beside that; in order to write algorithms and implement the rest of application (all what is non-UI) you have to resort to either Javascript or C++ (or Python, etc.); the only difference on how you use these languages is that it's possible to write the Javascript code in the <tt>.qml</tt> file itself, which is very convenient but also, in my humble opinion, something that you shouldn't do. So, while you could say that it is possible to write an entire application in QML, I heartily discourage you from doing so; if you really like Javascript (why would you, by the way?) and want to write your application with it and QML, it's much better to write the code of your application logic in a <tt>.js</tt> file and import that from QML. About QML code becoming a maze when writing complex applications, I disagree; of course, it's possible, but it's the same in all other languages (which I know of). If you split your code into smaller QML files (per UI component or groups of components) and avoid creating cross dependencies between components, everything will go smoothly — my golden rule when writing QML code is that <em>a <tt>.qml</tt> file should never refer to identifiers which are not defined in the file itself</em>. The reason why I'm getting so down in technicalities here is that, if you are a developer who has some experience with QML but finds it messy, you should go and check your code against this rule. :-) Indeed, QML is not a panacea which let everyone who is not a developer write über-complex applications; it's easier and more effective than all other languages (which I know of, again), but the rules of good software development still apply.
</li></ul>
<h3>How you can start liking Qt</h3>
<p>No way you will. ;-) Joke aside, there is some truth in that answer: first of all, you will never like Qt until you try it; and you won't try it unless you are forced to, or have some very good reasons to start looking into it. In my case, in fact, I was forced to, and — at that time — I had absolutely no reason to try Qt on my own: I already had some bad memories with it, I didn't like KDE, the skype Linux client and, most importantly, I was totally happy and satisfied with coding C and GObject.</p>
<p>However, I believe that nowadays there might be two reasons why even a hardcore GNOME developer could, in an unforgivable moment of weakness, decide to try programming with Qt: QML and application portability. QML is <i>the new cool stuff</i> (it was not there when I started with Qt), there are plenty of nice demos and examples out there, and they do pretty amazing things. Especially given that setting up the environment is an easy task (just install the Qt packages from your Linux distribution) and running the demos is in most cases just a matter of typing <tt>qmlviewer <file>.qml</tt>, and that you are a very curious geek, it's not so unlikely that you'll want to have a closer look to the demos; and since the source code consists in most cases of just a few lines of JSON-like text, it won't take long for you to understand it and maybe start playing with it. Especially because I <a href="http://mail.gnome.org/archives/desktop-devel-list/2011-April/msg00174.html">still</a> believe that GNOME developers deserve something as cool as QML. :-)<br>
The other reason why trying Qt nowadays is not so absurd as it might seem is portability. Yes, Qt has always made portability his flag, but who does really care about Windows and Mac? However, what you might care about is <b>Android</b>! What has changed here in the last couple of years is that <a href="http://www.youtube.com/watch?v=IzhFscWXs_w">Qt and QML run on Android</a>, with GL acceleration and multitouch support, enabling you to develop modern applications which can be run on millions of devices; you can also target <a href="http://swipe.nokia.com/">the best smartphone ever</a>, Symbian smartphones and whatever devices Nokia will come up with for <a href="http://www.developer.nokia.com/Community/Blogs/blog/nokia-developer-news/2011/06/21/future-of-qt-bringing-apps-to-next-billion">the next billion</a>.</p>
<p>I don't think there is much more I can write to stimulate you to try out Qt or, if you have already started using it, to support your efforts to master it. What I can tell you, with no fear of being contradicted, is that <em>eventually you will like it</em>; there is no way that this won't happen, if you continue learning it. At some point you will realize that going back to C (or even Vala) and GObject is not going to make your programming more productive, or even more enjoyable than how it has become with Qt. It's just a matter of enduring the difficulties and unpleasantness for a long enough time; which can be even several full months if you are, like me, one who takes technologies, programming languages and libraries next to your heart.</p><p>I decided to blog about my experience of transitioning from being a GLib and GObject enthusiast to a Qt (and QML) fanboy. :-) I'm not writing this with any specific goals, other than sharing my own experience and hopefully making the life of those developers who are forced to learn and use Qt less painful and a bit more rosy; in particular, I'm not trying to be a Qt evangelist here and convince you, hardcore GObject developer, to switch to Qt: I'm indeed sure that if my current self tried to talk my 3 years younger self into Qt, it would be a useless and tiresome (and maybe violent ;-)) discussion.</p>
<p>Just a bit of background on myself: I've been developing on Linux and Unix for more than 10 years now, mostly using GObject based libraries, such as Gtk+. I had a short encounter with Qt in about 2004, just for a few weeks, which left me with a bad impression (mostly because of the <a href="http://qt-project.org/doc/uic.html">uic</a>). Other than that, I was simply not interested in Qt, mostly because I hate C++ and love C and anyway all my needs were perfectly met by GLib, GObject and Gtk+. I remember that the first time when I read about GObject, I was fascinated: the power of OO programming on top of my favorite language, all open source and hackable. In autumn 2006 I started a new job in Nokia, in the <a href="http://maemo.org">maemo</a> team, working on a middleware component in the <a href="http://telepathy.freedesktop.org/wiki/">Telepathy</a> VoIP framework; I enjoyed it a lot, and (if possible) grew even more fond of GObject and GLib. On early 2008, the big news: Nokia acquires Trolltech (the SW house developing Qt); for me, as for most of the people working in the <i>maemo</i> team, this came as a complete surprise, and not as a really good one. Indeed, we were afraid that we would have to abandon the C/Gtk+ work and switch to C++/Qt — perhaps not coincidentally, several GNOME developers working in Nokia even left the company around that time. Luckily though, nothing really changed for us for more than one year, and even later, when more people joined to work on Qt-related stuff and I moved to another project, I could still avoid touching Qt code and continue using only my beloved GObject. However, <em>like all good dreams, this also came to an end</em>: eventually, I had to refresh my C++ knowledge and change my most typed character from "g" to the hated "q".<br>
So, here my Q story begins.</p>
<h3>The first prolonged exposure to Qt</h3>
<p>It was painful. My first task was to create Qt-bindings for the GLib-based library I was developing. There was no UI involved, so on the tools front the experience was not as bad as I remembered; but on the pure programming side, I was horrified: I felt extremely limited, many programming paradigms I was used too couldn't be applied, or I was just told (by people more expert in Qt) that “you shouldn't do like that, it's not the Qt way!”. Urgh.</p>
<p>The biggest issues I had were the lack of reference counting in QObject (!!) and the veto on using C-style function callbacks for asynchronous operations (you <em>should</em> use Qt <i>slots</i>, and in order to have a slot you <em>must</em> have a receiving QObject). How could I take Qt seriously? Sure, there were also a few nice things about it, like the fact that QObject comes with child-parent lifetime handling out of the box (when a parent object dies, all of its children are automatically deleted), and that signal connections are automatically broken when either the emitter or the <em>receiver</em> object dies (yay, no more explicit signal disconnections — or random crashes!). But still, this could in no way compensate for the lack of the other low-level features I was used to.</p>
<p>I cannot really say that I enjoyed the first months of using Qt. I was still trying to work as much as possible on the GLib-based parts of the project, and twisting my head around to figure out what was “the Qt way” of doing all the things that I was used to do almost instinctively with GLib/GObject.</p>
<h3>From hate to love</h3>
<p>Now that I think back and try to find the moment of time when I finally started liking Qt (or just not dislike it too much), I cannot really point out a definite time. It was a very slow process, that surely wouldn't have completed if I hadn't been forced to use Qt because of my work. But indeed, the moment when I realized that Qt was not so bad after all is when I started writing new original code with it. In retrospection, I would say that my experience with Qt was so bad because I started with a completely wrong task: as an inexperienced Qt developer, creating binding for a GObject-based library couldn't possibly make me appreciate Qt; I was just bound to notice all the GObject features that were not present in Qt, and suffer their absence. And I wouldn't notice almost any of the niceties that Qt offers to application developers, because there is not much code you can write in a wrapper library other than some trivial glue code.<br>
So, my first suggestion for those GObject developers who start using Qt is: <b>do not write a Qt wrapper to your favorite GObject library!</b>, you are going to hate it. Leave it to someone who is more experienced than you in Qt; it can be a very pedagogic task, indeed, but chances are that it will be the last time you are going to use Qt. If you can, start with writing new code.</p>
<p>That said, there is a big difference between not disliking something and loving it. But again, I cannot tell when I started loving Qt. What I surely can tell is when I <em>realized</em> that I loved it: and that was when I started porting some GObject-based code to Qt (not as a line-by-line port, but more like a functional rewrite) and found out that the resulting code was not only more compact and easier to write, but — and especially — easier to <em>read</em>. And of course, when I realized that my enthusiasm was not the same as before, whenever I had to do some programming in C+GObject.</p>
<h3>What I find cute in Qt</h3>
<p>Let me begin with a couple of statements which could dispel some myths or anyway clarify some doubts that the Qt-virgin might hold:</p>
<ul>
<li><b>It's not C++</b>. This is a bold (and false) statement, but it's probably the most effective to convey the idea: if you — like me — hate C++, you won't necessarily hate Qt. Qt's C++ is a subset of C++: although you can use whatever C++ feature you might like, developing with Qt does not involve using exceptions, templates, RTTI and the STL. In a similar way to how GLib and GObject “extend” the C language, Qt uses a preprocessor (called <tt>moc</tt>) to add its own run-time type information (think of GType) and implement the signals/slots mechanism. In the end, you don't need to know all the details of C++ to develop Qt; instead, it's somehow similar to developing Vala code — it's like a programming language of its own.
</li><li><b>It's not just GUI</b>. As you might have noticed, this post is not about Qt vs. Gtk+, not at all. There are many other articles on the web where you can find comparisons and opinions of the two, but what I'm focusing on here is my experience with Qt programming and GNOME programming, and not just at the UI level. So, yes, the point is that you can develop whatever code with Qt (except maybe kernel drivers): I've personally written D-Bus services, command line tools and embedded software using just Qt.
</li><li><b>There <em>really</em> is a Qt way</b>. My disappointment about the lack of reference counting in QObject is now history: apart from the fact that indeed there is one class in Qt which lets you implement reference counting for QObjects, I cannot recall any case where reference counting would have been useful. I know, coming from GObject this might sound hard to believe (especially to my three years younger self, who used to mess up with cross references everywhere in the code), but it's a fact: after some initial struggle, I always managed to design the software with clear ownership of objects, so that the reference counting ended up to be totally superfluous. And in fact, my code is designed better now. The same can be said of any other feature that I initially missed: if it's not there, you can do without it: just restructure your code in a different way — the Qt way — and there's a good chance that while reworking your classes you'll clear up some mess. :-)
</li></ul>
<p>That said, here's a list of things that I came to like about Qt; I'm obviously not mentioning those things that are also in GLib/GObject, unless there are significant differences.</p>
<ul>
<li><b>QObject automatic destruction of children</b>. I already mentioned it before, but it's worth expanding a bit. Quite often I had to use reference counting in my GObject subclasses to keep track of the child-parent relationships; QObject already does that for you: whenever you create a QObject, you can specify one parent object which will “watch” its lifetime and destroy it in its destructor. This leads to a nice programming paradigm where you can create all the objects that your class needs and just use the <tt>this</tt> pointer as parent object: then you don't need to remember destroying them explicitly in your destructor.
</li><li><b>Automatic disconnection of signals when receiver object dies</b>. I also mentioned this before, but <i>repetita iuvant</i>: if you are an experienced C + GObject developer, you <em>must</em> have seen at least once in your programming career one crash due to a signal callback invoked when the objects it operated on had already been destroyed. Of course I know that it never happened to <em>you</em> personally, but you surely saw this in someone else's software. ;-) Well, in Qt this is very unlikely to happen, because (at least till Qt4) it's impossible to bind signals to C callbacks: you must bind them to a QObject method (called “slot”), and the QObject system takes care of disconnecting the signal for you when either the emitter or the receiver object are destroyed.
</li><li><b>QString</b>. I'm sometimes a bit maniacal with micro-optimizations, and one thing I was always trying to optimize in my early GLib days was avoiding string allocations. It really hurts me to write a g_strdup() in a library method's implementation when I could rather write "Please, don't destroy or change @string_param while this object is still alive" in the documentation string for the method. But that's not <em>the GLib way</em> (and indeed, not my way anymore when I write GLib code): you can never know what happens with the string, so it's way safer to incur the small penalty of a g_strdup() than run the risk of a crash which is likely to be very hard to debug. So, C/GLib code is often full with g_strdup() and g_free() (not to speak about valac-generated code!). Enter QString! QString is not only a class that provides a ton of useful string methods, it is an <em>implicitly shared</em> class. That means that the QString structure itself is very small (size of a pointer?), and that the string data is reference counted; then if/when you modify a string which has a reference count higher than 1, the string data is copied and your QString is now pointing at the modified copy. So you never have to worry about copying strings! How cool is that? :-)
</li><li><b>Awesome container classes</b>. Qt comes with a few container classes which you'll surely get to like: <tt>QMap</tt>, <tt>QList</tt> are those that you'll use the most, but then there's also <tt>QSet</tt>, <tt>QQueue</tt>, <tt>QHash</tt>, <tt>QVector</tt> and others. These are template classes, so you can write <tt>QMap<QString,QVariant></tt> and get the equivalent of a <tt>GHashtable</tt> whose keys are strings and values are <tt>GValue</tt>s. Inserting items is as easy as writing
<pre>
QMap<QString,QVariant> map;
map.insert("string", "string value");
map.insert("integer", 12);
</pre>
while to iterate the values you have the handy <tt>foreach</tt> macro, which lets you write
<pre>
foreach (const QVariant &value, map) {
QDebug() << "Value:" << value;
}
</pre>
And if you remember what I wrote above about QString: Qt container classes are implicitly shared too!
</li><li><b>Reduced usage of pointers</b>. This follows in part from the above: QString handles all string pointers for you, and the ease of implementing implicit sharing of container classes makes it so that you will be often passing them by value or by reference. Also, implementing implicit sharing for your own data structures is very easy, and you might prefer investing a little time doing that rather than using raw pointers.
</li><li><b>Class and API offering</b>. Even excluding the GUI classes, the functionality provided by the Qt classes will satisfy the most demanding developer: whether you want to deal with date/time, with network resources, with graphics/images, HTML (webkit), SQL databases, D-Bus, plugins, regular expressions, etc., it's all there, and everything works perfectly together. The APIs are intuitive and clean: you won't find duplicate classes offering the same functionality (unless one is deprecated), and the documentation is excellent.
</li><li><b>Compact and clean code</b>. Qt application code is likely to be much mode compact and clean than GObject code. Just like Vala, imagine removing all GObject casts and using class namespaces to shorten your method names and fit your code in a 80 chars wide editor. :-) Use <tt>const</tt> effectively to mark your class methods and finally be able to pass constant objects and structures around your code, minimizing the risk of incorrect usage.
</li><li><b>QML</b>. This would deserve a chapter on its own, but since there has been quite a lot of buzz around it on the internet I won't spend many words on describing it. Instead, I'll focus on how I came to like it so much. As it often happens with new things, my first impression was not so great; sure, all the QML demos you can find in the internet are extremely captivating, and it's impressive how much you can achieve with very little code — which doesn't even look like real code, but more like a static description. And this was indeed my first doubt: what is the limit of QML? It's a nice language for moving graphics items around, but does it let me do anything more than that? Or: if it really allows me to write complex UIs for big applications, won't the code become a horrible mess to maintain? Again, time and hands-on experience is what changed my mind. I'm porting one map application from Gtk+/Clutter to Qt and of course the map widget and its animations has been my first item in the list. <a href="http://www.clutter-project.org/">Clutter</a> is a fantastic toolkit for producing animated UIs in the GNOME world; the Qt equivalent is QGraphicsView, whose APIs luckily match very close the Clutter ones; so, the porting wasn't that difficult at all, and it didn't took long until I had my widget working. However, for implementing the animations (zoom, panning and rotation of the map) I didn't use the <a href="http://qt-project.org/doc/qt-4.8/animation-overview.html">Qt Animation Framework</a>, which would be the natural equivalent to Clutter animation classes, but instead went for QML: exposing the map properties to QML enables implementing animations in a much easier and enjoyable way. QML property bindings, together with property animation descriptions, empower your application to any kind of smooth animations with almost no effort on your side. You don't have to take care of starting/stopping animations, changing the direction of animations while they are running, or combining zooming/panning/rotation at overlapping moments: no matter how crazily the user plays with your UI, all animations happen as expected, without any need for you to special code them. I couldn't help falling in love with QML. :-)<br>
So, my answers to the above questions are that, first of all, QML is a language especially designed for developing UIs and UI logics. There's not much else that you can do beside that; in order to write algorithms and implement the rest of application (all what is non-UI) you have to resort to either Javascript or C++ (or Python, etc.); the only difference on how you use these languages is that it's possible to write the Javascript code in the <tt>.qml</tt> file itself, which is very convenient but also, in my humble opinion, something that you shouldn't do. So, while you could say that it is possible to write an entire application in QML, I heartily discourage you from doing so; if you really like Javascript (why would you, by the way?) and want to write your application with it and QML, it's much better to write the code of your application logic in a <tt>.js</tt> file and import that from QML. About QML code becoming a maze when writing complex applications, I disagree; of course, it's possible, but it's the same in all other languages (which I know of). If you split your code into smaller QML files (per UI component or groups of components) and avoid creating cross dependencies between components, everything will go smoothly — my golden rule when writing QML code is that <em>a <tt>.qml</tt> file should never refer to identifiers which are not defined in the file itself</em>. The reason why I'm getting so down in technicalities here is that, if you are a developer who has some experience with QML but finds it messy, you should go and check your code against this rule. :-) Indeed, QML is not a panacea which let everyone who is not a developer write über-complex applications; it's easier and more effective than all other languages (which I know of, again), but the rules of good software development still apply.
</li></ul>
<h3>How you can start liking Qt</h3>
<p>No way you will. ;-) Joke aside, there is some truth in that answer: first of all, you will never like Qt until you try it; and you won't try it unless you are forced to, or have some very good reasons to start looking into it. In my case, in fact, I was forced to, and — at that time — I had absolutely no reason to try Qt on my own: I already had some bad memories with it, I didn't like KDE, the skype Linux client and, most importantly, I was totally happy and satisfied with coding C and GObject.</p>
<p>However, I believe that nowadays there might be two reasons why even a hardcore GNOME developer could, in an unforgivable moment of weakness, decide to try programming with Qt: QML and application portability. QML is <i>the new cool stuff</i> (it was not there when I started with Qt), there are plenty of nice demos and examples out there, and they do pretty amazing things. Especially given that setting up the environment is an easy task (just install the Qt packages from your Linux distribution) and running the demos is in most cases just a matter of typing <tt>qmlviewer <file>.qml</tt>, and that you are a very curious geek, it's not so unlikely that you'll want to have a closer look to the demos; and since the source code consists in most cases of just a few lines of JSON-like text, it won't take long for you to understand it and maybe start playing with it. Especially because I <a href="http://mail.gnome.org/archives/desktop-devel-list/2011-April/msg00174.html">still</a> believe that GNOME developers deserve something as cool as QML. :-)<br>
The other reason why trying Qt nowadays is not so absurd as it might seem is portability. Yes, Qt has always made portability his flag, but who does really care about Windows and Mac? However, what you might care about is <b>Android</b>! What has changed here in the last couple of years is that <a href="http://www.youtube.com/watch?v=IzhFscWXs_w">Qt and QML run on Android</a>, with GL acceleration and multitouch support, enabling you to develop modern applications which can be run on millions of devices; you can also target <a href="http://swipe.nokia.com/">the best smartphone ever</a>, Symbian smartphones and whatever devices Nokia will come up with for <a href="http://www.developer.nokia.com/Community/Blogs/blog/nokia-developer-news/2011/06/21/future-of-qt-bringing-apps-to-next-billion">the next billion</a>.</p>
<p>I don't think there is much more I can write to stimulate you to try out Qt or, if you have already started using it, to support your efforts to master it. What I can tell you, with no fear of being contradicted, is that <em>eventually you will like it</em>; there is no way that this won't happen, if you continue learning it. At some point you will realize that going back to C (or even Vala) and GObject is not going to make your programming more productive, or even more enjoyable than how it has become with Qt. It's just a matter of enduring the difficulties and unpleasantness for a long enough time; which can be even several full months if you are, like me, one who takes technologies, programming languages and libraries next to your heart.</p>The Meego Accounts & Single Sign On projecthttp://mardy.it/it/blog/2011/08/meego-accounts-single-sign-on-project.html2011-08-14T21:20:00+04:002011-08-14T21:20:00+04:00Alberto Mardegan<p>One of the new features of the upcoming <a href="http://swipe.nokia.com/">Nokia N9</a> is the unified accounts UI and the Single Sign On (SSO) framework. The developer website hosts a <a href="http://www.developer.nokia.com/swipe/ux/pages/Accounts.html">page describing this feature</a> in high level terms — a highly recommended reading — and offers a picture of the account creation flow (the orange circle representing the finger tapping is a bit off target in the pictures, bummer):</p>
<div style="margin: 0 auto; width: 626px;">
<img src="http://www.developer.nokia.com/swipe/ux/images/integrate_your_app/addaccount-thumb.png">
</div>
<p>The UX designers of the N9 decided to create a centralized place where all the user’s accounts would be managed: all the account providers will be listed in this application, and once the user chooses the provider and enters his credentials (only once), he’ll be prompted to select which services he intends to use on this account, in case the provider account gives access to more than one. Once this is done, all the applications interested in the selected services which have been enabled for the new account will start using it.</p>
<p>This design removes the need to implement account management in every application, because all the accounts and their settings are handled in the accounts UI application. Of course, applications can invoke the accounts UI when an account needs to be created, and they can directly embed the account configuration plugin when a specific account needs to be edited.<br>
The accounts UI provides most of its functionality through <b>account plugins</b>. There are <em>provider</em> plugins, whose task is to create the account and handle those settings that are shared through all the account’s services (such as a global option to enable or disable the account), and <em>service</em> plugins, which add support for a specific service within the account and provide a configuration for its settings (at the very least, a toggle switch to enable or disable the service). This plugin based way of operate on accounts brings the possibility to extend the support for new online services, with plugins possibly coming from different sources, from the OS platform vendor to a user’s community, as well as from a hardware vendor, third party software companies and application stores. And all the new services can be directly accessible from the same applications the user is already familiar with, instead of requiring the installation of one additional stand-alone application.</p>
<p>On the other hand, the <b>Single Sign On</b> framework is mostly transparent to the user (indeed, that’s the goal of any SSO implementation): once the password for one service has been entered, all applications operating on the same account should be able to login without bothering the user with password dialogs. And if the password turns out to be wrong, the SSO framework will ask for it <em>only once</em>, no matter how many applications are using the account.<br>
Security is also tightly bound to the MeeGo SSO implementation: at account creation time it’s possible to specify which applications are allowed to use a certain account (or, more technically, which resource tokens an application must possess in order to be granted access to a certain account’s credentials), and what authentication methods are allowed. For instance, for security reasons we might not want to allow an account to be used with any authentication method where the password is disclosed in plain text to the applications or sent over the network.<br>
Last but not least, the account passwords are stored on the device in encrypted form, and the encrypted storage can be dynamically activated/deactivated by providing/removing a master key, which could be configured to be the user password, or a fingerprint or other biometric checksum, some hardware key (such as a SIM card), or pretty much anything else. When the encrypted password storage is unavailable and some applications need to login to a service, the user will be prompted for the needed service password (again not more than once per account); all this being totally transparent to the application.</p>
<h4>Using the framework in other devices/platforms</h4>
<p>The UI design for the Accounts & SSO components described above is just one of the possible ways of integrating the MeeGo Accounts & SSO framework into a user device. The framework itself has been written to be flexible and support any UI workflow we could think of, without compromises to performance or security. The deployment of the Accounts & SSO framework in other devices and platforms has also been taken into consideration during the architecture and implementation development and several actions were taken towards this goal.</p>
<p>The core software driving the Accounts & SSO frameworks is all open source (LGPL), and can be found in <a href="https://gitorious.org/accounts-sso">gitorious.org</a>. The most interesting components are:
</p><ul>
<li><a href="http://gitorious.org/accounts-sso/accounts-glib">libaccounts-glib</a>: <a href="http://en.wikipedia.org/wiki/GLib">Glib</a>-based API for account management. Depends on <a href="http://www.sqlite.org/">SQLite</a> and <a href="http://www.freedesktop.org/wiki/Software/dbus">D-Bus</a>.</li>
<li><a href="http://gitorious.org/accounts-sso/accounts-qt">libaccounts-qt</a>: Qt API for account management. Thin wrapper of libaccounts-glib APIs.</li>
<li><a href="http://gitorious.org/accounts-sso/signon">signon</a>: the SSO daemon (written with Qt), which provides a D-Bus API. In the same source tree there’s also the libsignon-qt library, for Qt-based clients.</li>
<li href="http://gitorious.org/accounts-sso/signon-glib">libsignon-glib: Glib-based client API for SSO.</li>
</ul>
<p>Most of the other repositories in the project are probably not very useful outside of MeeGo, and they are not that interesting anyway. What might be more interesting to know, is the list of components that are missing from the gitorious project (because they are not open source), and that another platform/vendor would have to reimplement in order to provide all the functionalities described above. Luckily, there’s not much in this list. Apart from a couple of SSO authentication plugins for specific services, the rest is all about UI parts (because of Nokia’s general policy of not releasing the source code of its UI applications): we <i>don’t</i> have the account application and the account plugins, and the SSO UI daemon serving the password dialogs. This is not a big loss because in the UI would have had to be rewritten anyways to run in other platforms (and for MeeGo as well, as the MeeGoTouch UI library which is used in these Nokia UIs has been deprecated).</p>
<p>Having spent quite a considerable amount of (pleasant) time and energy on this project, I feel rather bound to it even though my employment in Nokia has ended. Therefore, I’m willing to continue to dedicate some of my free time (which, I have to say, is not much) to contribute to it and help its deployment in MeeGo and other Linux based platforms. Don’t hesitate to <a href="mailto:mardy@users.sourceforge.net">contact me</a> if you are interested in getting the Accounts & SSO powering the OS you love and would like to know more about it.</p><p>One of the new features of the upcoming <a href="http://swipe.nokia.com/">Nokia N9</a> is the unified accounts UI and the Single Sign On (SSO) framework. The developer website hosts a <a href="http://www.developer.nokia.com/swipe/ux/pages/Accounts.html">page describing this feature</a> in high level terms — a highly recommended reading — and offers a picture of the account creation flow (the orange circle representing the finger tapping is a bit off target in the pictures, bummer):</p>
<div style="margin: 0 auto; width: 626px;">
<img src="http://www.developer.nokia.com/swipe/ux/images/integrate_your_app/addaccount-thumb.png">
</div>
<p>The UX designers of the N9 decided to create a centralized place where all the user’s accounts would be managed: all the account providers will be listed in this application, and once the user chooses the provider and enters his credentials (only once), he’ll be prompted to select which services he intends to use on this account, in case the provider account gives access to more than one. Once this is done, all the applications interested in the selected services which have been enabled for the new account will start using it.</p>
<p>This design removes the need to implement account management in every application, because all the accounts and their settings are handled in the accounts UI application. Of course, applications can invoke the accounts UI when an account needs to be created, and they can directly embed the account configuration plugin when a specific account needs to be edited.<br>
The accounts UI provides most of its functionality through <b>account plugins</b>. There are <em>provider</em> plugins, whose task is to create the account and handle those settings that are shared through all the account’s services (such as a global option to enable or disable the account), and <em>service</em> plugins, which add support for a specific service within the account and provide a configuration for its settings (at the very least, a toggle switch to enable or disable the service). This plugin based way of operate on accounts brings the possibility to extend the support for new online services, with plugins possibly coming from different sources, from the OS platform vendor to a user’s community, as well as from a hardware vendor, third party software companies and application stores. And all the new services can be directly accessible from the same applications the user is already familiar with, instead of requiring the installation of one additional stand-alone application.</p>
<p>On the other hand, the <b>Single Sign On</b> framework is mostly transparent to the user (indeed, that’s the goal of any SSO implementation): once the password for one service has been entered, all applications operating on the same account should be able to login without bothering the user with password dialogs. And if the password turns out to be wrong, the SSO framework will ask for it <em>only once</em>, no matter how many applications are using the account.<br>
Security is also tightly bound to the MeeGo SSO implementation: at account creation time it’s possible to specify which applications are allowed to use a certain account (or, more technically, which resource tokens an application must possess in order to be granted access to a certain account’s credentials), and what authentication methods are allowed. For instance, for security reasons we might not want to allow an account to be used with any authentication method where the password is disclosed in plain text to the applications or sent over the network.<br>
Last but not least, the account passwords are stored on the device in encrypted form, and the encrypted storage can be dynamically activated/deactivated by providing/removing a master key, which could be configured to be the user password, or a fingerprint or other biometric checksum, some hardware key (such as a SIM card), or pretty much anything else. When the encrypted password storage is unavailable and some applications need to login to a service, the user will be prompted for the needed service password (again not more than once per account); all this being totally transparent to the application.</p>
<h4>Using the framework in other devices/platforms</h4>
<p>The UI design for the Accounts & SSO components described above is just one of the possible ways of integrating the MeeGo Accounts & SSO framework into a user device. The framework itself has been written to be flexible and support any UI workflow we could think of, without compromises to performance or security. The deployment of the Accounts & SSO framework in other devices and platforms has also been taken into consideration during the architecture and implementation development and several actions were taken towards this goal.</p>
<p>The core software driving the Accounts & SSO frameworks is all open source (LGPL), and can be found in <a href="https://gitorious.org/accounts-sso">gitorious.org</a>. The most interesting components are:
</p><ul>
<li><a href="http://gitorious.org/accounts-sso/accounts-glib">libaccounts-glib</a>: <a href="http://en.wikipedia.org/wiki/GLib">Glib</a>-based API for account management. Depends on <a href="http://www.sqlite.org/">SQLite</a> and <a href="http://www.freedesktop.org/wiki/Software/dbus">D-Bus</a>.</li>
<li><a href="http://gitorious.org/accounts-sso/accounts-qt">libaccounts-qt</a>: Qt API for account management. Thin wrapper of libaccounts-glib APIs.</li>
<li><a href="http://gitorious.org/accounts-sso/signon">signon</a>: the SSO daemon (written with Qt), which provides a D-Bus API. In the same source tree there’s also the libsignon-qt library, for Qt-based clients.</li>
<li href="http://gitorious.org/accounts-sso/signon-glib">libsignon-glib: Glib-based client API for SSO.</li>
</ul>
<p>Most of the other repositories in the project are probably not very useful outside of MeeGo, and they are not that interesting anyway. What might be more interesting to know, is the list of components that are missing from the gitorious project (because they are not open source), and that another platform/vendor would have to reimplement in order to provide all the functionalities described above. Luckily, there’s not much in this list. Apart from a couple of SSO authentication plugins for specific services, the rest is all about UI parts (because of Nokia’s general policy of not releasing the source code of its UI applications): we <i>don’t</i> have the account application and the account plugins, and the SSO UI daemon serving the password dialogs. This is not a big loss because in the UI would have had to be rewritten anyways to run in other platforms (and for MeeGo as well, as the MeeGoTouch UI library which is used in these Nokia UIs has been deprecated).</p>
<p>Having spent quite a considerable amount of (pleasant) time and energy on this project, I feel rather bound to it even though my employment in Nokia has ended. Therefore, I’m willing to continue to dedicate some of my free time (which, I have to say, is not much) to contribute to it and help its deployment in MeeGo and other Linux based platforms. Don’t hesitate to <a href="mailto:mardy@users.sourceforge.net">contact me</a> if you are interested in getting the Accounts & SSO powering the OS you love and would like to know more about it.</p>Oculo: dynamic web content to your N900 home screenhttp://mardy.it/it/blog/2011/05/oculo-dynamic-web-content-to-your-n900.html2011-05-01T11:17:00+04:002011-05-01T11:17:00+04:00Alberto Mardegan<p>Latest news, sport results, stock market quotes, currency conversions, web comics, picture of the day... The internet is filled with dynamic content that you might want to bring into your phone homescreen, but often you don't have a widget that supports the site you are interested in. But now, cry no more! <a href="http://maemo.org/packages/view/oculo/">Oculo</a> is a homescreen widget for the <a href="http://maemo.nokia.com/n900">Nokia N900</a> which can take any web site and render its contents into your homescreen. Not only it can render a complete web-page, you can also choose which specific parts of a web page you are interested in!</p>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.mardy.it/archivos/imagines/oculo.png" imageanchor="1" style="margin-left:1em; margin-right:1em"><img border="0" width="400" src="http://www.mardy.it/archivos/imagines/oculo.png"></a><br>
The mandatory screenshot. Three instances of Oculo: Flickr! explore, Google local news, Yahoo! finance.</div>
<p>As I'm writing this, Oculo 0.7 is in the <a href="http://wiki.maemo.org/Extras-testing">Maemo extras-testing repository</a>; I'm using it without problems in my N900, but it's still rather buggy, so if you try and find some problems, don't hesitate to report them. Unfortunately, it is already known that <b>Oculo will not be visible if you are running the <a href="http://wiki.maemo.org/Community_SSU">community SSU</a></b>; this is apparently a <a href="http://talk.maemo.org/showthread.php?p=998003">problem with the CSSU and Qt home widgets</a> which I'm investigating. Also, since the configuration procedure might not be as intuitive as it could be, I've created a video which shows how to configure it:</p>
<center><iframe width="560" height="349" src="http://www.youtube.com/embed/g-ShrSkq0r8?rel=0" frameborder="0" allowfullscreen></iframe></center>
<h4>History and technical aspects</h4>
<p>The idea of developing Oculo (which means “eye” in <a href="http://www.interlingua.com/">interlingua</a>) came to me a few months ago, when I noticed that Radek, a colleague of mine, was checking the daily menu of our canteen in the intranet pages. I ironically suggested him that he should write a maemo home widget showing the daily menu, so he could have it always visible on his phone. The fact that I considered “silly” the idea of writing a homescreen widget just for that goal suddenly brought up the idea of Oculo: giving the user the possibility to put in his homescreen whatever web content he desires.</p>
<p>Using Qt and QWebKit to render the web page contents into an image was unbelievably simple, and boosted my motivation in developing the widget. In a couple of days I already got something that was usable to me; but as <a href="http://www.mardy.it/mappero">Mappero</a> users know, my usability standards are quite low :-), and this time I realized that I couldn't just publish Oculo in that state. So I went on developing the configuration dialog, tried hard to improve the graphical appearance of the widget (which still looks bad, but you haven't seen how it was before :-p) and solve some performance issues. The biggest of which was the <i>memory consumption</i> of the widget due to keeping QWebKit loaded in memory; this has now been solved by moving the configuration phase and the web content retrieval/rendering into a separate process, which is running only when needed. The homescreen widget itself is just a container for the image.
</p><h4>Future developments</h4>
<p>A quick roadmap of what should be coming for Oculo:</p>
<ul>
<li>Minimum interval between updates will be configurable (this is trivial and will be coming very soon)</li>
<li>Speed improvements: try not to load external content which will not be rendered</li>
<li>Share configurations between users; let users upload/download their configuration to a central server — this will make the configuration much easier</li>
<li>Port Oculo to MeeGo (to be investigated)</li>
<li>Port Oculo to Linux desktops</li>
<li>If <a href="http://labs.qt.nokia.com/2011/02/28/necessitas/">Qt on Android</a> can be used to develop home screen widget, an Android port might also be possible.</li>
</ul>
<p>That's all for now! Go and try Oculo out, and let me know your impressions. :-)</p><p>Latest news, sport results, stock market quotes, currency conversions, web comics, picture of the day... The internet is filled with dynamic content that you might want to bring into your phone homescreen, but often you don't have a widget that supports the site you are interested in. But now, cry no more! <a href="http://maemo.org/packages/view/oculo/">Oculo</a> is a homescreen widget for the <a href="http://maemo.nokia.com/n900">Nokia N900</a> which can take any web site and render its contents into your homescreen. Not only it can render a complete web-page, you can also choose which specific parts of a web page you are interested in!</p>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.mardy.it/archivos/imagines/oculo.png" imageanchor="1" style="margin-left:1em; margin-right:1em"><img border="0" width="400" src="http://www.mardy.it/archivos/imagines/oculo.png"></a><br>
The mandatory screenshot. Three instances of Oculo: Flickr! explore, Google local news, Yahoo! finance.</div>
<p>As I'm writing this, Oculo 0.7 is in the <a href="http://wiki.maemo.org/Extras-testing">Maemo extras-testing repository</a>; I'm using it without problems in my N900, but it's still rather buggy, so if you try and find some problems, don't hesitate to report them. Unfortunately, it is already known that <b>Oculo will not be visible if you are running the <a href="http://wiki.maemo.org/Community_SSU">community SSU</a></b>; this is apparently a <a href="http://talk.maemo.org/showthread.php?p=998003">problem with the CSSU and Qt home widgets</a> which I'm investigating. Also, since the configuration procedure might not be as intuitive as it could be, I've created a video which shows how to configure it:</p>
<center><iframe width="560" height="349" src="http://www.youtube.com/embed/g-ShrSkq0r8?rel=0" frameborder="0" allowfullscreen></iframe></center>
<h4>History and technical aspects</h4>
<p>The idea of developing Oculo (which means “eye” in <a href="http://www.interlingua.com/">interlingua</a>) came to me a few months ago, when I noticed that Radek, a colleague of mine, was checking the daily menu of our canteen in the intranet pages. I ironically suggested him that he should write a maemo home widget showing the daily menu, so he could have it always visible on his phone. The fact that I considered “silly” the idea of writing a homescreen widget just for that goal suddenly brought up the idea of Oculo: giving the user the possibility to put in his homescreen whatever web content he desires.</p>
<p>Using Qt and QWebKit to render the web page contents into an image was unbelievably simple, and boosted my motivation in developing the widget. In a couple of days I already got something that was usable to me; but as <a href="http://www.mardy.it/mappero">Mappero</a> users know, my usability standards are quite low :-), and this time I realized that I couldn't just publish Oculo in that state. So I went on developing the configuration dialog, tried hard to improve the graphical appearance of the widget (which still looks bad, but you haven't seen how it was before :-p) and solve some performance issues. The biggest of which was the <i>memory consumption</i> of the widget due to keeping QWebKit loaded in memory; this has now been solved by moving the configuration phase and the web content retrieval/rendering into a separate process, which is running only when needed. The homescreen widget itself is just a container for the image.
</p><h4>Future developments</h4>
<p>A quick roadmap of what should be coming for Oculo:</p>
<ul>
<li>Minimum interval between updates will be configurable (this is trivial and will be coming very soon)</li>
<li>Speed improvements: try not to load external content which will not be rendered</li>
<li>Share configurations between users; let users upload/download their configuration to a central server — this will make the configuration much easier</li>
<li>Port Oculo to MeeGo (to be investigated)</li>
<li>Port Oculo to Linux desktops</li>
<li>If <a href="http://labs.qt.nokia.com/2011/02/28/necessitas/">Qt on Android</a> can be used to develop home screen widget, an Android port might also be possible.</li>
</ul>
<p>That's all for now! Go and try Oculo out, and let me know your impressions. :-)</p>Committed to Linuxhttp://mardy.it/it/blog/2011/02/committed-to-linux.html2011-02-12T13:02:00+03:002011-02-12T13:02:00+03:00Alberto Mardegan<p>
As a Nokia employee working on MeeGo, I feel that my career is going to be deeply affected by the recently announced <a href="http://www.nokia.com/press/press-releases/showpressrelease?newsid=1488004">Nokia strategy</a>. I'm not going to comment on the value of the business decisions; of course I have my opinions about that too, but what I feel more important now is the future of MeeGo, and Linux-based platforms in general, inside Nokia.<br>
The announcement mentions MeeGo only marginally, as a <em>“longer-term market exploration”</em>, and ends the paragraph with <em>“Nokia <b>still</b> plans to ship a MeeGo-related product later this year”</em>. This sounds to me like: we won't market any MeeGo devices in parallel with Windows Phone ones, not to hinder the latter's success, but we'll release the MeeGo product we're currently working on before downscaling MeeGo back into the R&D division.</p>
<p>No matter how wrong my interpretation might be, let's try to collect a few facts:
</p><ul>
<li><b>MeeGo is ready, it's not an R&D project</b>: a MeeGo phone <em>will</em> be released
</li><li>Nokia's primary platform for the middle/long term is Windows Mobile</li>
<li>Meego will become, within Nokia, an R&D project at best
</li></ul>
<p>I feel confused and fooled. Business logics are floating several metres above my head, and I cannot understand what's the point of saying that MeeGo will be an R&D project when it's not. To me, it's like taking a teenager and trying to squeeze him into a baby's cradle. Either you kill him more or less explicitly, or you take him out, let him grow and give him a chance to be a hero. We are going to have the best phone in the market this year. It might not be perfect, as the N900 clearly wasn't, but all the premises for a brilliant future are there. And people will love it, as they loved the N900 despite it being far away from the quality standards we aspired to achieve and despite a zero-digits investment on marketing. Maemo won, against all odds.</p>
<p>
One thing is clear: Nokia is not committed to Linux and the platform for the future Nokia devices is not going to be Linux-based, at least in the middle term. Because if it were, I can't see a reason why it couldn't be MeeGo.</p>
<p>
If I try to imagine my future career in Nokia, I see myself either working on applications or R&D projects on top of Windows Mobile, or trying to squeeze the teenager into the cradle, and maybe put him into the refrigerator and periodically check that he doesn't die, because hey, he's our far future hope.<br>
So, what do I have against Windows Mobile? Simple: it's closed source software. And it doesn't matter if the software I develop is open-source; on the contrary, <b>if I had to choose between developing open-source software on top of a closed platform and developing closed-source software on top of an open-source platform, I'd much rather go for the second option</b>: because with the first one I'd still be using and promoting a closed platform, and unless you are developing a cross-platform application or framework, you'd be doing very little good to the open source world.</p>
<p>
Summing up. I really wish that Nokia took one step back and revised their plan. Not because I ask it of course, but because the loyal customers, the developers and the investors are asking it. And give a clear statement on what is the future of MeeGo, Linux and open-source within Nokia. Meanwhile, <b><a href="http://www.mardy.it/archivos/AlbertoMardeganCVe.pdf">my CV has been updated</a></b> and has appeared on this blog's navigation menu for anyone to read. Companies committed to Linux are welcome to <a href="mailto:mardy.tardi@gmail.com">contact me</a> for proposing a job or even a shorter term collaboration. It would be wonderful if I was given a chance to continue working on MeeGo, <a href="http://old.nabble.com/%22DBus-Embedded%22---a-clean-break-tt30716929.html#a30810229">work on some cool ideas</a>, work to introduce the Accounts & SingleSignOn framework to more Linux distributions and open-source OSes. Or actually, anything where I would be given a chance to develop on top of open-source software.<br>
Proposals from Nokia are welcome as well.</p>
<p style="padding-top: 1em"><i>Note: in this blog post I'm talking only about MeeGo because it's what's affecting me most, and I wanted to keep the post to the point. It doesn't mean that I don't care about Symbian's future and Qt deployment.</i></p><p>
As a Nokia employee working on MeeGo, I feel that my career is going to be deeply affected by the recently announced <a href="http://www.nokia.com/press/press-releases/showpressrelease?newsid=1488004">Nokia strategy</a>. I'm not going to comment on the value of the business decisions; of course I have my opinions about that too, but what I feel more important now is the future of MeeGo, and Linux-based platforms in general, inside Nokia.<br>
The announcement mentions MeeGo only marginally, as a <em>“longer-term market exploration”</em>, and ends the paragraph with <em>“Nokia <b>still</b> plans to ship a MeeGo-related product later this year”</em>. This sounds to me like: we won't market any MeeGo devices in parallel with Windows Phone ones, not to hinder the latter's success, but we'll release the MeeGo product we're currently working on before downscaling MeeGo back into the R&D division.</p>
<p>No matter how wrong my interpretation might be, let's try to collect a few facts:
</p><ul>
<li><b>MeeGo is ready, it's not an R&D project</b>: a MeeGo phone <em>will</em> be released
</li><li>Nokia's primary platform for the middle/long term is Windows Mobile</li>
<li>Meego will become, within Nokia, an R&D project at best
</li></ul>
<p>I feel confused and fooled. Business logics are floating several metres above my head, and I cannot understand what's the point of saying that MeeGo will be an R&D project when it's not. To me, it's like taking a teenager and trying to squeeze him into a baby's cradle. Either you kill him more or less explicitly, or you take him out, let him grow and give him a chance to be a hero. We are going to have the best phone in the market this year. It might not be perfect, as the N900 clearly wasn't, but all the premises for a brilliant future are there. And people will love it, as they loved the N900 despite it being far away from the quality standards we aspired to achieve and despite a zero-digits investment on marketing. Maemo won, against all odds.</p>
<p>
One thing is clear: Nokia is not committed to Linux and the platform for the future Nokia devices is not going to be Linux-based, at least in the middle term. Because if it were, I can't see a reason why it couldn't be MeeGo.</p>
<p>
If I try to imagine my future career in Nokia, I see myself either working on applications or R&D projects on top of Windows Mobile, or trying to squeeze the teenager into the cradle, and maybe put him into the refrigerator and periodically check that he doesn't die, because hey, he's our far future hope.<br>
So, what do I have against Windows Mobile? Simple: it's closed source software. And it doesn't matter if the software I develop is open-source; on the contrary, <b>if I had to choose between developing open-source software on top of a closed platform and developing closed-source software on top of an open-source platform, I'd much rather go for the second option</b>: because with the first one I'd still be using and promoting a closed platform, and unless you are developing a cross-platform application or framework, you'd be doing very little good to the open source world.</p>
<p>
Summing up. I really wish that Nokia took one step back and revised their plan. Not because I ask it of course, but because the loyal customers, the developers and the investors are asking it. And give a clear statement on what is the future of MeeGo, Linux and open-source within Nokia. Meanwhile, <b><a href="http://www.mardy.it/archivos/AlbertoMardeganCVe.pdf">my CV has been updated</a></b> and has appeared on this blog's navigation menu for anyone to read. Companies committed to Linux are welcome to <a href="mailto:mardy.tardi@gmail.com">contact me</a> for proposing a job or even a shorter term collaboration. It would be wonderful if I was given a chance to continue working on MeeGo, <a href="http://old.nabble.com/%22DBus-Embedded%22---a-clean-break-tt30716929.html#a30810229">work on some cool ideas</a>, work to introduce the Accounts & SingleSignOn framework to more Linux distributions and open-source OSes. Or actually, anything where I would be given a chance to develop on top of open-source software.<br>
Proposals from Nokia are welcome as well.</p>
<p style="padding-top: 1em"><i>Note: in this blog post I'm talking only about MeeGo because it's what's affecting me most, and I wanted to keep the post to the point. It doesn't mean that I don't care about Symbian's future and Qt deployment.</i></p>Actualisation de maemo Mapperhttp://mardy.it/it/blog/2010/03/actualisation-de-maemo-mapper.html2010-03-13T11:12:00+03:002010-03-13T11:12:00+03:00Alberto Mardegan<div style="text-align: left; padding: 3px;"><a href="http://www.flickr.com/photos/mardytardi/4428448391/" title="photo sharing"><img src="http://farm5.static.flickr.com/4014/4428448391_896d46bfd6.jpg" style="border: solid 2px #000000;" alt=""></a><br><span style="font-size: 0.8em; margin-top: 0px;"><a href="http://www.flickr.com/photos/mardytardi/4428448391/">Maemo Mapper</a>, originally uploaded by <a href="http://www.flickr.com/people/mardytardi/">mardy78</a>.</span></div><p>In le passate septimana io continuava a laborar super Mapper e implementava un pannello (in alto a dextera) con informationes super le strata percurse (in rubie) e le strata a percurrer (in verde).<br>Le informationes super le strata percurse monstra le distantia e le tempore total (in horas:minutas). A latere del parve bandera verde il ha le longor total del route, e le informationes a latere del puncto verde monstra le distantia verso le proxime puncto del route e le description de iste puncto.<br><br>Iste matino io lo experimentava, in un breve cursa con mi amicos. Post pauc plus que duo kilometros io debeva stoppar me, perque mi respiro non plus esseva sufficiente pro currer. Isto pote esser causate per le aere frigide (il esseva circa 0 grados), ma plus probabilemente le ration es que io non es ben trainate, e forsan le rhythmo esseva troppo rapide pro mi condition. Alora, io continuava, alternante cammino e cursa lente. Vos pote vider le analyse del percurso in <a href="http://www.runsaturday.com/act/236482/subView/Player">runsaturday.com</a>.</p><div style="text-align: left; padding: 3px;"><a href="http://www.flickr.com/photos/mardytardi/4428448391/" title="photo sharing"><img src="http://farm5.static.flickr.com/4014/4428448391_896d46bfd6.jpg" style="border: solid 2px #000000;" alt=""></a><br><span style="font-size: 0.8em; margin-top: 0px;"><a href="http://www.flickr.com/photos/mardytardi/4428448391/">Maemo Mapper</a>, originally uploaded by <a href="http://www.flickr.com/people/mardytardi/">mardy78</a>.</span></div><p>In le passate septimana io continuava a laborar super Mapper e implementava un pannello (in alto a dextera) con informationes super le strata percurse (in rubie) e le strata a percurrer (in verde).<br>Le informationes super le strata percurse monstra le distantia e le tempore total (in horas:minutas). A latere del parve bandera verde il ha le longor total del route, e le informationes a latere del puncto verde monstra le distantia verso le proxime puncto del route e le description de iste puncto.<br><br>Iste matino io lo experimentava, in un breve cursa con mi amicos. Post pauc plus que duo kilometros io debeva stoppar me, perque mi respiro non plus esseva sufficiente pro currer. Isto pote esser causate per le aere frigide (il esseva circa 0 grados), ma plus probabilemente le ration es que io non es ben trainate, e forsan le rhythmo esseva troppo rapide pro mi condition. Alora, io continuava, alternante cammino e cursa lente. Vos pote vider le analyse del percurso in <a href="http://www.runsaturday.com/act/236482/subView/Player">runsaturday.com</a>.</p>Le placer de zoomar le mappa in MaemoMapperhttp://mardy.it/it/blog/2010/01/le-placer-de-zoomar-le-mappa-in.html2010-01-16T15:13:00+03:002010-01-16T15:13:00+03:00Alberto Mardegan<p>Desde le initio del nove anno, io non ha habite multe tempore pro laborar super <a href="https://garage.maemo.org/projects/maemo-mapper/">maemo-mapper</a>; ma finalmente, hodie le cosas cambiava e io poteva dedicar me al <em>programmation extreme</em>!<br>
Le resultato es que ora le <i>zoom</i> in maemo-mapper es animate:</p>
<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/gqDsdqgjdRY&hl=en&fs=1"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="http://www.youtube.com/v/gqDsdqgjdRY&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>
<p>Le centro del zoom es le citate <a href="http://ia.wikipedia.org/wiki/Kalmar">Kalmar</a> (clicca sur le nomine pro leger plus e vider alicun photos), in Svedia, ubi iste estate il habera le <a href="http://www.interlingua.com/novas/2009-11-07-incontronordic">incontro nordic de interlingua</a>, al qual totes es invitate a participar.</p>
<p>In conclusion, isto esseva un articulo duplemente propagandistic. :-)</p>
<p></p>
<p>Nota: le centro del zoom es fixate in Kalmar solmente in le video. Benque io considerava le idea de centrar le mappa in maemo-mapper sempre in Kalmar pro propagandar le incontro nordic, io decideva de non facer lo perque io es, pro mi mal sorte, troppo bon.</p><p>Desde le initio del nove anno, io non ha habite multe tempore pro laborar super <a href="https://garage.maemo.org/projects/maemo-mapper/">maemo-mapper</a>; ma finalmente, hodie le cosas cambiava e io poteva dedicar me al <em>programmation extreme</em>!<br>
Le resultato es que ora le <i>zoom</i> in maemo-mapper es animate:</p>
<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/gqDsdqgjdRY&hl=en&fs=1"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="http://www.youtube.com/v/gqDsdqgjdRY&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>
<p>Le centro del zoom es le citate <a href="http://ia.wikipedia.org/wiki/Kalmar">Kalmar</a> (clicca sur le nomine pro leger plus e vider alicun photos), in Svedia, ubi iste estate il habera le <a href="http://www.interlingua.com/novas/2009-11-07-incontronordic">incontro nordic de interlingua</a>, al qual totes es invitate a participar.</p>
<p>In conclusion, isto esseva un articulo duplemente propagandistic. :-)</p>
<p></p>
<p>Nota: le centro del zoom es fixate in Kalmar solmente in le video. Benque io considerava le idea de centrar le mappa in maemo-mapper sempre in Kalmar pro propagandar le incontro nordic, io decideva de non facer lo perque io es, pro mi mal sorte, troppo bon.</p>Le N900 arriva. Anque in vostre manos?http://mardy.it/it/blog/2009/11/le-n900-arriva-anque-in-vostre-manos.html2009-11-17T19:57:00+03:002009-11-17T19:57:00+03:00Alberto Mardegan<div style="margin: 0 auto;width:512px;padding:1em;"><img src="http://www.mardy.it/archivos/imagines/n900contacto.jpg"><p><i>Mi N900. Un observator acute poterea vider que io pote communicar con le contacto selectionate (a proposito, qui es ille?) non solmente per telephono, ma anque per Google-talk, Jabber e Skype.</i></p></div>
<p>Un septimana retro Olli-Pekka Kallasvuo (le administrator executive de Nokia) annunciava al pressa que le distribution del <a href="http://maemo.nokia.com/N900">N900</a> habeva finalmente initiate. Post un septimana, il pare que ancora nulle persona ha succedite in trovar le <em>telephono</em> in un boteca, ma on pote dicer que il es solmente question de horas. Intertanto, on pote discoperir quanto grande es le expectation simplemente per facer un recerca de <a href="http://twitter.com/search?q=N900">N900 in twitter</a> e contar quante messages il ha! Infortunatemente non tote illes qui commenta vadera al botecas a comprar lo, alteremente io esserea millionario.</p>
<p>Del resto, io ha nihil special a dicer; io soltanto debeva scriber alicun cosa, perque vos non pensa que io ha disparite completemente. :-)</p><div style="margin: 0 auto;width:512px;padding:1em;"><img src="http://www.mardy.it/archivos/imagines/n900contacto.jpg"><p><i>Mi N900. Un observator acute poterea vider que io pote communicar con le contacto selectionate (a proposito, qui es ille?) non solmente per telephono, ma anque per Google-talk, Jabber e Skype.</i></p></div>
<p>Un septimana retro Olli-Pekka Kallasvuo (le administrator executive de Nokia) annunciava al pressa que le distribution del <a href="http://maemo.nokia.com/N900">N900</a> habeva finalmente initiate. Post un septimana, il pare que ancora nulle persona ha succedite in trovar le <em>telephono</em> in un boteca, ma on pote dicer que il es solmente question de horas. Intertanto, on pote discoperir quanto grande es le expectation simplemente per facer un recerca de <a href="http://twitter.com/search?q=N900">N900 in twitter</a> e contar quante messages il ha! Infortunatemente non tote illes qui commenta vadera al botecas a comprar lo, alteremente io esserea millionario.</p>
<p>Del resto, io ha nihil special a dicer; io soltanto debeva scriber alicun cosa, perque vos non pensa que io ha disparite completemente. :-)</p>Party pro N900http://mardy.it/it/blog/2009/08/party-pro-n900.html2009-08-27T17:32:00+04:002009-08-27T17:32:00+04:00Alberto Mardegan<div style="panning:3px">
<img src="http://www.mardy.it/archivos/imagines/amsterdamN900.jpg" width="400px">
</div>
<p>Que nos celebra le annuncio public del N900, le nove "smartphone" de Nokia que es construite super <a href="http://maemo.org">maemo</a>, que in torno es basate super Linux.<br><br>Vide le sito official: <a href="http://maemo.nokia.com">maemo.nokia.com</a>.</p><div style="panning:3px">
<img src="http://www.mardy.it/archivos/imagines/amsterdamN900.jpg" width="400px">
</div>
<p>Que nos celebra le annuncio public del N900, le nove "smartphone" de Nokia que es construite super <a href="http://maemo.org">maemo</a>, que in torno es basate super Linux.<br><br>Vide le sito official: <a href="http://maemo.nokia.com">maemo.nokia.com</a>.</p>