(tl;dr: Nokia should provide updated Qt packages as official SSU for Maemo 5.) Before I start, here are some facts (correct me if I'm wrong):
- The N900 runs the Maemo 5 operating system
- Maemo 5 received some updates (the latest one being PR1.3)
- We don't really expect PR1.4 to come out any time soon, if at all
- The MeeGo Handset images from meego.com are inferior to Maemo 5 and not a replacement (and never will be)
- The MeeGo operating system on the first Nokia MeeGo handset will have a proprietary UX and proprietary apps, and won't be available for the N900
In summary, it means: We are stuck with Maemo 5 on the N900. And that is a good thing! Lots of useful apps, a helpful community (if you subtract the trolls) and a polished OS. Sure, there's room for improvement, and lots of open bugs that should be fixed, but that's another issue (which will ideally be solved by open sourcing closed components with bugs that Nokia isn't interested in fixing anymore and by the Community SSU). This one is about Qt.
Two days ago, an e-mail was sent to maemo-community, proposing a "community service pack", which basically is a big pile of workarounds. Read my response for some initial thoughts.
When Qt arrived on Maemo 5, the promise was two-fold:
- Write your apps in Qt and you're ready for MeeGo (apps written now will run on the platform released in the future)
- Maemo 5 gets Qt support, so MeeGo apps will run on the N900 (apps written in the future will run on the platform released now)
It turns out that the first one will probably hold true (surely with QML, maybe even with QWidget), while the second one is doubtful, as Maemo 5 has only got Qt 4.7.0 through the official channels (PR1.3), with no real official update in sight. If you use QML, use QtQuickCompat as workaround ("Qt Qml plugin that reregisters all “Qt 4.7” types in the “QtQuick 1.0” namespace … useful if you’re forced to stay with 4.7.0 (e.g. on N900), but still want to use the new namespace.").
There is also a real bug (yes, a bug!) in Qt 4.7.0 on the N900, and the fix isn't released as update - it's a new package: libqt4-bearer-hotfix ("This is a hotfix for the broken ICD package in Qt 4.7.0. It can be removed once Qt mobility 1.1 is released."). Now, the proposed "Community service pack" would combine all these fixes into a single dependendable metapackage (yes, a new one). It becomes the "Unbreak my Qt" feature that every app developer has to depend on and specify in the packaging.
This is wrong! No developer targetting MeeGo who has not heard about Maemo 5 will go through all those ugly workarounds and spend a week fixing things up for Maemo 5 just so that the app works. Now imagine what would happen if the first MeeGo device also introduces such kludges once it falls out of its support life cycle. Or what if the problems on Symbian are similar, and developers have to special-case things there. Not only for Symbian^3, but also for S60v5? Fragmentation.
How to avoid fragmentation? Simple: Provide Qt as a "feature" with a quicker release cycle that can be updated every month if need be. Provide Qt updates also for operating systems that don't get updates for the OS anymore. Here's my proposal:
- Provide SSU updates for Maemo 5 for Qt (and Qt Mobility) through official channels (that's the important part here!)
- A new Qt (and Qt Mobility) release should be available on all platforms (Maemo 5, S60v5, Symbian^3, MeeGo) at the same time through official (end-user approved) channels
- Apps targetting stores and repositories (Maemo Extras, Ovi Store, MeeGo Apps/Downloads) should be able to depend on the latest Qt (and Qt Mobility) version
Without that, you'll get fragmentation similar to Android: The 1.5, 1.6, 2.1 versions are similar to Qt 4.6, Qt 4.7.0 and Qt 4.7.1 (for example). Again, you don't need to update the OS, just update the framework - through official channels!
6 Kommentare:
The problem i think will not be to release this new qt version. But what happen with closed source app made by Manufacturer (here Nokia) which depends on Qt.
They ll probably need to test them again the new Qt Version. And if there is a break in the API, they should probably re release a new version. But this will probably be a problem if they don't want to maintain the plateform.
Khertan: In that case, have two builds of Qt installed: The one that is used by the built-in, closed-source apps (this one can be as old as they want) and another one for third party apps. It's better to "waste" some space on the internal memory than to have a broken/fragmented development platform.
And this is a non-issue for Maemo 5 where no built-in app depends on Qt (AFAICT).
Indeed, i agree !
The downside of multiple Qt versions is that you also multiplying the memory footprint, disk usage is not really the question here. I agree that since Qt is the platform, it should be always upgradeable, but unfortunately it was moving so fast in the last year or so (arguably even now) that compatibility promises were really-really hard to make, and the make-pretend maemo5 widget wrapper thingy is not making it any easier.
Attila: I forgot about runtime memory footprint - thanks for the input :)
There are even more versioning problems when you start introducing wide, cross-platform promises to developers: "Your app will run on all of these Qt platforms!"
What if a commercial app needs to perform a workaround for a bug in a particular version of Qt, and then the whole Qt platform gets upgraded? Oops, that app is broken! And oh no, they're not in business anymore! Oh no, twelve thousand people are running that app (and depending on it!) on Symbian, Maemo, MeeGo, etc! What do those people do? Not upgrade Qt when the official-channel update comes? Add yet another parallel version to their device?
Kommentar veröffentlichen