Saturday, July 9, 2011

Qt Components - The story of the ugly QWidgetling

Disclaimer: these are my own, personal thoughts, not necessarily matching those of my employer, neighbor, goldfish or innocent bystanders.

Paradigm shifts are always difficult, especially when linked to technology changes. Qt Components are here and seeing that there and at least three component sets (MeeGo Harmattan, Symbian, MeeGo UX) and counting, it is hard to see how components will help solve the cross-platform problem that has been plaguing mobile developers. Hard to see, if you think about Components as a QWidgetling, that is. In the vein of the story of the ugly duckling, I will try to explain how you can utilize Components and avoid the feeling of being given a square peg when you are looking at a round hole. To repeat, this is about figuring about just what QML with Components is, how it's supposed to be used. Disclaimer #2: Those who think QWidgets should have been the long term technology of choice, or hate QML with a passion, please skip this article. You're not going to like it, and I'm usually delete-button-happy, so save the angst and skip it. Sorry and thanks.

QWidgets

If I was trolling, I would say they were (mobile-wise) the cross-platform solution that never existed - it certainly *sounded* good that I, as a developer, work against an API and the UI framework works out everything, resolution, input method, hardware be damned. This, however, is a bit like listening to politicians - just vote for me and I will solve all problems. Well, not quite. As many have outlined, the paradigm shift from the "I wrap everything to native controls which
 kinda look/work the same" characteristic for the desktop spelt doom for the classic widget based approach. I have gotten nasty looks IRL for saying this, but Maemo5 did not prove QWidgets is the solution - it proved that it is NOT (yes, I be trollin', but only to make a point :). It was a great effort, and while the looks were certainly on par, your supposedly cross-platform code was a mess, full of #ifdefs, modules and classes specific to Maemo5. As I sometimes say, well, with enough ifdefs, you could switch between GTK and Qt, right ? At the same time, development was not made any easier - there were no specific UI tools for creating Maemo interfaces.

QML, and the long road to Components


Enter QML, a radically different approach. As people soon realized, QML is a base technology, it does not provide you with buttons or much higher level functionality you previously had with QWidgets. Also, at the same time, it was said Qt Components will solve this. All was well, it was just a little wait and we will have our new incarnation of QWidgets, right ? Well, not quite...
 
QtComponents have hatched...


... and it turns out they harbor a pretty ugly QWidgets replacement. People trying to make QML that runs equally well on Harmattan using the Harmattan components, Symbian using Symbian components already felt this is not good. Recently I got a contribution for QtInfo in the form of a cool Symbian components UI. I tried to kick it around a bit to make it work on Harmattan, with bleak results, with projects diverging already at the HelloWorld. Something was wrong. This duckling was really ugly. After a few days, however, it dawned on me...

A chainsaw cuts trees faster than an axe only if it's on

The reason I was suffering and losing time was because for years I have been taught to think (much in the vein of QWidgets) almost axiomatically that I want a single codebase and with enough tweaking (ifdefs) it would run equally well on platforms. That is no longer necessarily true (if you think I'm losing my mind, that's understandable, but read on). In terms of the title of this paragraph, I had Components (the chainsaw) and I was hitting the tree with it like I would with an axe, and it really is a horrible experience. However, there is a paradigm shift on the horizon. Turns out, Components solves the cross-platform challenge NOT by providing a singular API. It attacks the problem by making is super-easy to write throwaway code. WHAT ? (if you think I *completely* lost my mind, that's understandable, too, but read on).

Live fast, die young

One of the key appeals of the old widget approach was their enduring nature. If you wrote a desktop application 10 years ago with it, it would likely work okay today. However, this age of UI tranquility, taken for granted for so long, is in it's final days. As we've seen, today even the most conservative desktop OSs are undergoing UI paradigm shifts. Mobile is even faster, 4 years in mobile is an eternity. Writing an UI as if it was there to stay for decades is losing appeal quickly - the life expectancy of mobile UIs is dramatically shorter, which coincidentally also lowers the long-term maintenance burden, traditionally so important to developers.

Use the Force. Let go, Luke.

As Ben Kenobi said. And even though it seemed weird to the people in the rebel base for Luke Skywalker to use the Force instead of the targeting computer, it shows us what's happening here. Let go of the idea of monolithic, single UI codebases. Let. Go. Like the huge armor of European medieval knights on appearance of the guns - the armor no longer provided real protection, but made you slow and unmaneuverable. So, what should I do, I hear you asking ? EMBRACE DIVERSITY. Use the weapon/components best suited for the platform. Don't be afraid to improvise or include your own Elements, or borrow (barring license limitations) from Components of other platforms. Keep your UI (QML) layer as thin and nimble as possible, keep the logic on the C++ side, it will help you both in terms of portability and speed. Spawn as many UIs as you wish. Think about the UI as a throwaway component. Is it Harmattan ? Okay, I'll just drop in the QML from the examples, who cares if it runs on Symbian. Different resolution ? I'll just include a different QML optimized for that. I can see the disbelief in your eyes. How can this work ? The point is that spawning UIs with QML is *fast*. Really fast. Actually way, way, way faster than tweaking for a certain subset/common API or resolution independence. You will write (and maintain !) 5 different UIs *faster* than you would write a monolithic QWidgets UI that would work truly cross-platform. It is a radically different setup. Returning to my QtInfo porting example - it took me nearly a day to create a port from the Symbian-only version to a version that ran on both Harmattan and Symbian, but it meant a lot of compromises and visual artifacts, rotation and integration issues. However, when I realized the new paradigm I outlined above, I had a sexy Harmattan fully integrated native UI up and running in 30 minutes, just appended the QML to the package and now the application is cool on Symbian, Maemo, Harmattan, the Desktop, and I could add a tablet MeeGo UX in another 30 minutes.

There you go, with all the acknowledgement that this might be hard to swallow for many of you, trusty old QWidget veterans, hopefully I now explained just what kind of square peg Qt Components I see and you will hopefully stop trying to shove it in that round hole :) Now go and make Qt Components shine and create beautiful swans of Harmattan, Symbian, MeeGo, or whichever platform the Qt winds might blow on.

Sunday, April 10, 2011

Is Open a dirty word now ?

Open technologies gained a lot of momentum in the past couple of years, but what became of the term Open ? Does it still hold and mean the same values it did previously ? Were the purists speaking about differences between Open and Free right ?

If you're reading this blog you're probably aware that I'm fairly fond of FOSS, both as a concept and a business model. Undoubtedly, open technologies made huge inroads in various industries - servers in the IT industry, various OSes in the telecoms industry, etc. However, there is a disturbing tendency going on in the world of Open. Meaning that Open implies Free less and less. You might be surprised at this point - what ? How can you be Open and not Free ? Well, if you look at the 'classic' FOSS definition on Wikipedia, you'll see Open Source is defined as "An open source license is a copyright license for computer software that makes the source code available for everyone to use." - this is the type of open we all cherish and love. But let's take a look at who sports the Open sticker nowadays ? The 500lbs gorilla is of course the Open Handset Alliance, and the Android Open Source project. Despite the lot of "Open" in the names, in the open is not where development happens, and lately even the source availability became selective. Another infamous example is the Open Screen Project run by Adobe intended to bring Flash related technologies for everybody - but in fact being nothing more than another industry alliance to try and grab market share from competitors, Open Source and values not accounting for much. There are other organizations that also ride the Open moniker - let's take for example the Open Design Alliance - a nonprofit organization that focuses on development of CAD-related libraries... However, open here means pay for the binaries, and pay (a lot - 25K$) to see the sources, unless a board of members deems you worthy. Not the type of open libraries you were expecting, right ? That's where the problem lies - Open is more and more a sinonym for the "For Sale" sticker, and the term "Alliance" is becoming a marketing lingo equivalent of "Cartel". This problem was recognized fairly early on by OSI and hence the term OSI approved Open Source license, but if the term Open becomes diluted enough, will it even mean anything except for marketing purposes and a counter-term for "exclusive technology" ? Will the O in FOSS become meaningless ? To be honest, the term Open was used long before Free, before the software industry, and it meant "public", mostly in the context of standards. However, now even that, decades old meaning is losing it's value. Today's Open is far too open unrelated to Free or even Public.

What's the takeaway, you might ask ? Be careful of how you yourself use the term, and be vary of supporting any project or (especially big business) initiative just because it uses the word "open". Support the values, and projects that promote those values, not the names.

Saturday, April 2, 2011

The age of pointless mobile benchmarks

Mobile devices are ever-more like their counterparts and we're starting to see benchmarks popping up on popular gadget sites. Sadly, most of these sites have not yet gone through the analytical phase of what most PC review sites did many many years ago and if effect turn into simple marketing vehicles. Let's see the common pitfalls !

To be clear I'm not talking about bad journalism, that result in articles like this (note how they manage to leave out from the title the ONE thing - GPU performance - that the article is about) even if the source a very reasonable article. I'll try to describe the differences why the methods and criteria established in the PC field that are starting to be applied to the mobile arena (like the Anand article above) make a lot less sense than they did for the original personal computers.

Pitfall no. 1: Level of integration - hardware

Mobile devices are nowadays mostly built around what is known as a SoC (System-on-Chip), which means that most components that would be separate chips or even replaceable units even on a notebook computer, are all rolled into one, which makes it very difficult to benchmark *single* components as they are inseparable from the rest of the system. How much is a NVidia vs ATI benchmark worth if you're comparing a Dell Inspiron 13" notebook with a NVidia card against a HP desktop one with an ATI and a 22" display ? To make it worse, some of the devices include additional video processing units (which again might be good only for some formats and bitrates) so the original chipset-style comparison is even more difficult to make.

Pitfall no. 2: Architectural differences


X86 CPUs is incremental - hardware backwards compatibility is pretty much a given, the only difference in capabilities is the in reality only in the timeframe when vendors add in extensions (like the different iterations of SSE). Mobile devices have to be a lot more transistor-count an usually binary compatibility is the first one to go. For example the relatively new Tegra2 chose to forego the NEON multimedia instructions that were common in Snapdragon and OMAP chips. OpenGL ES 2.0 is not backwards compatible with OpenGL ES 1.1, etc. Depending on what you use and how your software works, this makes things a lot murkier as the fact that device X works better with Quake 123 means nothing in terms whether what you want to run works better.

Pitfall no. 3: Form factor difference

A variation of the previous point - the resolutions are vastly different, but this does not only touch on the graphical performance, but also on our usage patterns and perception of performance. Nominally a device can have a better framerate, but because of screen size and distance-to-eye differences you might actually subjectively prefer the one with the marginally lower framerate.

Pitfall no. 4: Multicore is a sword with two edges

Any multicore design is only as good as the software that runs it. This was true on the desktop, but multicore is a whole different beast on mobile devices, as the quality of software determines whether that dual-core monster is better or, actually, worse than a well executed singlecore one, both in terms of performance and battery usage.

Pitfall no. 5: Software platform diversity

In the desktop and notebook world, just by taking Windows, Mac (and Linux of course ! :) you cover 99%+ of users. On the other hand, in mobile you literally have a jungle of OSes (there are almost a dozen OSes that are above the million mark) which are optimized for very different hardware and very different use-cases. This is not an issue in the X86 world because the application-level performance is comparable with at best a few percent difference, but on mobiles, due to drivers and being optimized for various modes of operation, the same HW can behave vastly differently with different OSes, so those extra FPS in a benchmark can again be very misleading.

Plenty more pitfalls, but let's not overdo it, so for the conclusion - since the complexity of these devices now rivals personal computers, it's only normal that people want to compare them the way they did with personal computers. The trouble is, these are not NEARLY as uniform as their bigger brethren so new ways of benchmarking will have to come up that will be less hardware or device oriented even if that means we'll have to give up FPS measures as such.

Wednesday, September 22, 2010

The Maemo Community Council elections - Why you should care


The maemo.org community is something of a rare bird in the mobile environment - a self-organizing community centered around Nokia's tablet line, with a very strong infrastructure and unique spot where users, developers and hackers come together resulting in a lot of synergy and powerful base compared to the niche aspect of Maemo. One of the most peculiar aspects of it is the Community Council, a representative body that deals with all things Maemo. What it can do, why should you care and, most importantly, why should you vote *TODAY* if you are a community member with enough karma ? Read on to find out ! I also hope this to shed a little light and be a short introduction of the inner workings of maemo.org to people NOT familiar with the intricate community workings of maemo.org

The Community Council was formed two years ago as a representative body, with a role to "represent the Maemo community's best interests to Nokia, and to act as a community conduit for Nokia-generated information." This role has recently been expanded, as Nokia has transferred control of maemo.org to the community (=the Council as a representative body). This gives it a fairly complete control over all things that happen in maemo.org, a lot of which many users are not even aware of:


  • the rules that define criteria for software in extras and related repositories
  • determining forum policies
  • overseeing collection of documentation/wikis/howtos
  • ability to issue tasks to maemo.org staff (you DO care if the forums or Extras breaks down or is difficult to use, right ?)
  • disseminate important information through the Council blog
  • help coordinate community events (Summits/Conferences/meetups)
  • help with grassroots efforts (competitions, hackfests, anything Maemo)
  • formalize concerns and issues and pass them to Nokia
  • define goals/strategies for the future of maemo.org
  • really, anything maemo.org related
  • in fact, anything community related goes - it it's cool, support it !

So yes - if you would like more of the things above, or you have a peeve you'd like changed - the Council is the body whose attention you need. Generally - if you have an idea relating to Maemo, and you don't know who to turn to, the council is the address (with a notable exception - the Council is not Nokia Care, Nokia has proper customer care channels, the Council focuses on community aspects).

Even with fairly complete control over the maemo.org realm, I cannot emphasize enough the facilitation character of the Council when it comes to Nokia. Nokia does not obey the Council - but certainly does listen to it as it represents the most vibrant and passionate base of it's users.

I've listed a short (far from complete !) list of what the Council can do - but there are things, often sources for confusion, of what it CANNOT do. Can the Council guarantee that a particular firmware will be made available to your device ? No - it's not a community call. Can the Council force Nokia to include/exclude components from firmwares ? No - it's not a community call. 

Some of you Maemo device owners will stop (or already stopped with tldr ;) ) reading as they don't really care about this maemo.org stuff (something I doubt, as Extras, a central part of it, is the main source of applications).

However, if even if all this community-talk jibberish means nothing to you and and you define the bottom line as Apps Apps and Apps (with Flash), you should pay attention. The Community Council is in the unique position to make a strategy for the future of the community. It *does* direct the work of maemo.org people and will be pivotal in determining for example what software will be available from MeeGo repositories, or just how difficult it will be for MeeGo/Harmattan developers to support the Extras repository. They can (and IMO should !) also be the voice of the Maemo community inside MeeGo - MeeGo doesn't have a council, and if you have an itch, it won't get resolved unless you or your representatives do it.

All this brings us to the bottom line - in my opinion, the Council matters, but only to the extent of the abilities of people in there. In a worst case scenario, the people you elect to it do nothing - that's the same as if it didn't exist. However, YOU, the community member have the power to elect people who ARE capable of affecting the future of maemo.org and all the people and device it touches on, be that apps, events or other. Today is the last day of the community elections for the next term, so if you care the tinyest bit about Maemo, MeeGo, maemo.org or your Maemo device - use that voting token and make a difference.

Saturday, August 28, 2010

Java mobile apps today - a technology/weapon misunderstood

When you look at the present landscape of available mobile technologies to develop apps with, you'll see an abundant offering. Depending on what platform you're developing for, you'll see a mix of native applications, web technologies and similar. These are all cool and powerful, but what is not often talked about is the scope of the applications written and how choice of these technologies is linked with business models. What am I talking about here ? People working with J2ME will be eager to point out that there are several hundred million phones capable of running such apps and that phones that have that as the primary application platform are still going strong (for example Nokia's S40 phones). Others will say that means nothing  as owners of such phones are unlikely to pay for apps and that their hardware is so limited that you couldn't make something impressive anyway. Both are right in a way, but the story doesn't end here. What is often overlooked that shiny, flashy apps, sold as a product are not the only business model here even though originally most of the J2ME offering were just that - games. Think about SMS for a moment here. It is a super simple service, basically a specialized application, that earns huge amounts of money. But is the money in selling this 'SMS application' as it would be in selling 'Angry Birds' ? No, it's in the services it supports. It's somewhat similar to the problem that some people first encountering Open Source business models have - if you give your app away, how do you make money ? And this is why Java mobile app programming of today is misunderstood - it should not be viewed as a competitor to the write-app-sell-app-...-profit business models of iOS, Android or Symbian, but as a gateway that allows addressing a huge user base otherwise currently unreachable with other technologies. You don't need super-high technologies and sophisticated devices to check for a public transport schedule, arrange reservations, inventory/availability checks, etc. In that light, it's far from dead and/or useless. It's just about realizing that you have a business that CAN benefit from such a userbase.

Monday, August 2, 2010

Flash versioning gone wrong, or, should the abusers be abused ?

A painful fact is that Flash 10.1 is not currently available for the Nokia N900 (well, at least painful for N900 owners). If we look at the bigger picture, applications (like my version-forging TweakFlashVer) uncover a few non-N900 specific problems with the way things are done in Flash land.

TweakFlashVer is an awful hack - it just makes the Flash plugin report a faked version string (much like browsers in the old times forged their agent strings). Seasoned Flash developers are naturally very displeased with such an approach, as the plugin itself does not gain any additional functionality or acceleration, it's still the same Flash it was prior to the intervention. I can hear you ask - well, what good is it, then ?

And here is the problem - cludgy as it is, it DOES work, as seen on the N900, Facebook videos work again and many sites came back to life. How is that possible ? Sadly, often the real requirements of the content presented by Flash do NOT match the requested version in the loader/web page. But why do people declare wrong versions and make lives of their own users miserable ? Because Flash is doing it wrong in the first place, and then it gets abused by webmasters and flash devs further (making TweakFlashVer an abuse of an abuse). What are the reasons for this abuse in the first place ?

  • Using version detection as an upgrade mechanism. The assumption is that if someone does not have the latest version, it is simply because they simply have never been nudged into upgrading it. The developers doing this think they are making users a favor since they will be upgrading to a version which is faster, safe, but are forgetting that different platforms have different upgrade cycles, and that latest version might not be available just yet.
  • Using the wrong loader. This can be caused by copy-pasting flash loader code from other projects or on-line tutorials, without matching the version requirements in the loader with the actual content. In other words - plain sloppiness.
Both of these, however, only go to show that Flash is doing it wrong in the first place, for the following reasons

  • The queries should be for *features*, not versions. This important as we will be seeing Flash players with different preferred feature sets. For example, a platform with hardware video acceleration might prefer a different codec to a platform that has no such thing (currently this role is done - again, in a wrong way - by checking for Flash Lite). Not to mention the pipe dream that one day Flash becomes a real Open industry standard with multiple content player plugins, which would obviously have different, partially overlapping feature sets.
  • The version requirement should not be a statically coded thing in HTML that is unrelated to the actual content. If there is (any) Flash version available,  the versioning requirement/handshake should be done *inside* Flash.
  • If possible, the server should present multiple versions. Sure, Flash 10 has new features, but there is no fallback, meaning there is no systematic way of saying 'hey, give me a Flash 9 version of that content'. As it is now, the server acts as a bouncer, asks 'whatcha got' and the client says 'errr.. 9.0.260 ?' and then the server just says "you're too old for this" and slams the door.

The question in the end thus remains. There is no doubt TweakFlashVer is a super-hacky solution to frankenstein Flash in order to allow users to access the content they want, but the Flash powers that be will have to come up with two solutions before this approach becomes widespread and turns from a hack into a modus operandi of abandoned Flash platforms, like Maemo 5 and 64-bit Linux:

  • A system that can address the sloppiness of it's users and their (mis)use of HTML loaders
  • Change the upgrade-upgrade-upgrade mantra. Sooner or later the range of devices that will (try to) run Flash will get so wide that a version number will not guarantee anything, and the Open Screen Project changed nothing in that aspect - users of particular platform are still at the mercy of Adobe and/or their vendor if they will get Flash player in a firmware without any guarantee that a sloppy coder won't render their device obsolete in a couple of months.

Friday, July 30, 2010

Where are those mobile Qt apps ? (Part 3, Resolution)

After a short historical overview and a short list of growing pains, in this, third installment of the mobile Qt app story, I will focus on what boulders remain in the path of widespread adoption of Qt among app mobile developers. Most of the technical groundwork has been laid down, but to reach a final resolution, it needs to include a bit more than just a healthy base.


Decouple Qt releases from firmware releases

As seen from the infamous PR1.2 delay, a coupled-with-the-firmware release cycle is detrimental to the platform. If multiple devices are on the market, it would mean instant-fragmentation as developers would have to code for the Qt released with the last firmware. This is eating Android alive, too, as various handsets have different upgrade cycles. A separate distribution mechanism HAS to be employed. It will be tricky as with MeeGo and Symbian^4 Qt is part of the OS and many teams will be reluctant to bet firmware functionality on the backward compatibility of Qt. But that is not the only thing that can cause fragmentation if it isn't true that...

One mobile widget framework is enough


I harp about this regularly (and will continue to do so until I get good news from an official source :), the option to have separate widget frameworks for Symbian (Orbit/uiemo) and MeeGo (DirectUI/MeeGo Touch Framework) is something that is completely against what Qt is trying to accomplish by bridging the two OS-es. 

All you bases are belong to us

Qt is almost a country of it's own, addressing (or having a development version that addresses) various aspects of software development, both mobile and desktop. However, there is one thing where it is sorely lacking - the wizz-bang games department. Yes, QGraphicsView and 3D enablers are cool and all, but that is not enough (even with QML and UI scripting). It would certainly be an overkill and unnecessary delay to implement a complete game engine in Qt, but there are alternatives - make a Unity3D port, or, better yet, in the spirit of open source, sponsor Ogre binding (and GLES) development for Qt, with the necessary physics libs.

Build it and they will come - Ovi and devices

Professional mobile developers can and will materialize only after the market for the Qt apps materializes. The prerequisite for this is that Qt gets a first-class treatment in the Ovi store, and the QA process is not a hit-and-miss, something that developers are guessing about. Once the Ovi store really starts accepting Qt apps en masse, the question turns into how many devices can be targeted via Qt. I can hear you say "well that's like almost all Symbian handsets in the last 2-3 years". Yeah, but... 


Market share is not necessarily mindshare

Devices that can be retrofitted with Qt already exist in the (tens of) millions range. However, these devices are mostly low to midrange devices as there were no runaway Symbian successes in the high-end segment for a while now. It will be hard to convince people to target a market, no matter how objectively big if they believe/see it as a relic, which means... 

You've got to be cool

The vehicles for the Qt platform need to be cool and carriers of high tech. This is the wave Android is riding in 2010. Now, the best way to do this is having iconic devices (iPhone killers if you wish), but this is not ONLY about devices, it's about how you handle your technology in general, your devs, your community, blogs and everything related to it. Qt has to be perceived cool, a must-have even by non-tech people, not just a sticker on the corner of a box and something geeks nod over on irc. It IS the differentiating factor. Take for example the happenings of last week in the Nokia N900 land. A triple-release is done - preview of the Qt Web Runtime, a new version of Qt Mobility and the super-cool fcamera project. This triplet just oozes with tech-cool demo potential, but it just isn't leveraged, hardly getting even a blog post. Instead there is a campaign and an 'exciting news' about Ovi doing a comic (I'm sure it will be good, but... ). This points to comms issues, but also lack of

Communication/Community Focus

While I don't know how many different communities and aspects of Qt should there addressed separately, I'm pretty sure we are already overloaded, even before the hordes of the new Qt developer generations emerge. There is the Qt Developer Network, then we have Forum Nokia (home of the Nokia Qt SDK), followed by a more specific MeeGo community that is vested (well, at least the handset variant) in Qt, and the same will be true for Symbian. OTOH If you want to publish/talk about Qt development on currently available devices, you should go to maemo.org. While in community waters, we should also mention Qt Centre. Quite a handful of forums, mailing lists and irc channels to follow, and I have not even talked about communities focused squarely at end-users ! Speaking of end-users, some people who even knew about those Qt/fcam releases I mentioned above were quite discontent, because there is/was no concept of...

Control and drive expectations

The 'other' platforms and ecosystem have built up and trained users to expect certain things in a certain way, and if they are not educated, they will not understand what is going on and will easily dismiss even good news when it is not is a form they expect it in. See the above - new releases of QtMobility, WRT, etc were not treated by many as real news or support by Nokia for the N900, even though they were done by official Nokia teams. The concept of the 'holy firmware release' is still strong, because people don't understand the concept of libraries and components (as that is not how most other platforms operate).


Those would be my major points, and while they might sound a bit grim (some not even related to Qt itself), I don't think they are insurmountable at all, it just takes a little effort (some already underway) and presto, the arid Qt mobile app landscape can bloom like a savanna after a rain.