Oh dear! Qt incompatibility on the horizon

I’ve read through a lengthy thread in the official Meamo forum (it’s so long, I even forgot how I even got there *g*).

Basically it says: The Symbian Foundation and Nokia with Maemo (now MeeGo) are building two widget sets on top of QGraphicsView – while both are called Direct UI, they are entirely different (I’ll refer to them as SDUI and MDUI from now on).

Symbian Foundation employee Mark Wilcox is the one who seems to see the seriousness the most that it’s totally braindead to have incompatibe widget sets. Ironically MDUI seems to be the portable one. Hopefully the Foundation understands the problem now and throws away SDUI and adopts the MDUI library for Symbian.

Too bad neither project adopted the already shipping QGraphicsView widget set KDE Plasma, but since Plasma was never written with Symbian compatibility in mind, it may be not ideal anyway. If I didn’t miss anything, MDUI already runs natively on desktop Linux (because it’s mostly developed on it) and uses the DE’s theme. If true that’s good news. Even if not source compatible with the Plasma API, MDUI apps could work nicely under the KDE’s workspaces (notably Plasma Mobile).

Powered by Blogilo


28 thoughts on “Oh dear! Qt incompatibility on the horizon”

  1. Better wording:
    Witness the destructive power of turf wars in large organizations. 🙂

    Anyway, it’s a sad situation. I am reasonably sure that everybody involved knows that something is wrong, yet there is no visible effort to do something about it.
    DuiApplication and the reasons why it is “needed” are just WRONG. QApplication can be as platform-specific as required. And certainly nobody needs different widget sets on S60 and Maemo. It looks like Nokia is dutifully repeating all previous mistakes, only on top of a better framework.
    Oh well. I guess I’m still more interested in desktop development anyway… and if the mobile UI mess turns out to be as bad as it looks now, it’s going to stay that way for sure.

  2. Please note that no official announcements about either have been made, so what you are seeing in the internet is either speculation or nda violation ;-).

    What has been made available recently, OTOH, is the source code for both DUI snd Orbit (uiemo). They are on gitorious.

    Both are cross platform and already run on N900.

  3. Seems the fragmentation of Qt starts.
    In the long Qt will die. Too sad.
    Time to learn Objective-C.

    1. Or just Symbian will die and its Qt addon with it.
      In the long run MeeGo is the better platform anyway.

  4. Children, please. Qt is not going to die because someone makes a layer on top of Qt.

  5. “Seems the fragmentation of Qt starts. In the long Qt will die. Too sad. Time to learn Objective-C.”

    I dropped my spoon this morning. Soon the apocalypse will come. A shame. Time to stock up on guns and beans.

    1. KDE hosts its own copy of Qt for convenience reasons. So far there is absolutely no need to fork Qt, because Qt itself is not going away. That thread is about two different Qt addons for mobile development. But this affects us, too because MDUI applications can work on KDE Platform, while SDUI cannot (because it’s Symbian-only).

      Maybe in the future we can use MDUI apps as Plasma applets at at very least use them side by side with KDE apps on Plasma Mobile.

  6. I can’t believe how slow Nokia is.
    Until there are ‘Apps’ for Nokia phones Apple have their 10th interation.

    1. Hopefully not … that would mean that I still have no phone to buy in the next decade.

  7. I’ve had this information quite some time ago, and wasn’t really pleased to read that either.

    Anyway, as far as I know (and read in some statements by Nokia employees), it will not completely break compatibility. They will have their own interfaces to integrate with the platforms UI, yes. This will, and does not mean, that normal Qt applications will not run on those phones. They may not integrate smoothly in the UI of the platform though.

    I don’t know what the way of QML is, or what problems it addresses, but it seems to point in a very same direction (different UIs for different platforms, integration with different platforms). Maybe that’s the way to go, develop one application (logics), but have different UIs designed for the specific platform. I’m not sure about this though, due to the missing technical background I’m probably completely wrong there.

    1. Read the comments by Mark Wilcox. He used to work at Trolltech, later Nokia, and is now employed by the Symbian Foundation. He has more experience with Qt than most Nokia employees. His comments are is the last third of the whole thread.

      But as I wrote: Nokia’s implementation (MDUI) is more portable than Symbian Foundation’s. While both parties didn’t cooperate until now and that’s both parties’ fault, in this case it’s the turn of the Symbian Foundation acknowledge their mistake and now use MDUI.

      1. Again, this is not true. there is no such as Symbian DUI developed by Symbian Foundation, such thing does not exist at all. Both Maemo’s DirectUI and Symbian’s DirectUi (UIEMO) is developed by Nokia. And about portability, UIEMO is already running on Symbian and on Maemo (Nokia N900). And as I said in my other message. UIEMO is much more advanced than Maemo’s DirectUI. I would not be surprised at all if MeeGo has UIEMO as a official UI framework.

  8. I found this blog really confusing even though I wrote one on the same topic a few weeks ago:

    Why did you make up these new terms MDUI and SDUI? Totally confusing. Where did you get the idea Symbian’s UI is called DirectUI? All of the Symbian UI classes are prefixed with “Hb” so I’m guessing its ‘true’ name is related to that.

    The terms the world uses are DUI and Orbit, or Harmattan UI and UIEMO. Just look at the frontpage of qt.gitorious.org.

    And why do you already prefer Harmattan UI? That doesn’t make any sense to me. Neither toolkit has proven itself to be the superior choice. You could probably make a good argument that it would be nice to have one QGV-based toolkit instead of two, and it doesn’t matter which. But I think that boat sailed…

    We are headed toward some competing QGV-toolkits and it might take a couple of years to settle out. Your best bet is to use QtGui for now and keep good core/ui separation. (QML is another choice, it was officially announced as part of Nokia’s software plan and will probably be part of the main Qt package installed everywhere.) But competing Qt-based libraries is hardly the same thing as “Qt-incompatibility”!

    1. Dude, if you are too lazy to read the whole thread, that’s OK. But if you don’t read it, don’t be an ass and pretend to know everything better.
      I just summarized the thread, especially Mark Wilcox’ posts. And if you don’t work for the Symbian Foundation and Trolltech before then, I suggest you keep you fingers off the keyboard.

      Mark Wilcox (12-14-2009, 10:56 AM):
      “Mameo DUI and Symbian DUI are not the same thing (as I understand it, the Symbian side of things accidentally stole the term from Maemo).”

      1. To be honest, Ian’s view is pretty much spot on.
        I’ve been involved with KDE since more than 10 years now and I’ve been involved with both projects for quite some time (Orbit as well as Maemo). And the summary you’re giving with your blog falls short on what’s actually happening and has several things that are plain wrong as Ian pointed out.

        Harmattan UI as well as UIEMO are modelled after certain specific requirements.
        They also take a pretty different approach on how to create QGV based widgets.
        Which of these solutions is technically better is something that needs to be proven by the success of each.
        So far in KDE development the “good” stuff has always “trickled” into Qt at some point. The same is happening and going to happen with these two toolkits as well: the “good parts” will (and do) find their way into Qt the “bad parts” will stay out. I find that idea much more appealing than pushing all unproven ideas into Qt: That would have actually decreased Qt’s quality quite a bit so I’m pretty happy that “more experimental” concepts get tried and tested in KDE, UIEMO, and Harmattan UI before they find their way into Qt at some later point of time.

        Personally I see it as a good thing that we have an increased amount of interest, projects and developers working on different high level competing toolkits and competing applications based on Qt. Of course fragmentation is always something that needs to be considered and watched carefully. Then again a situation where there’s only a single solution for everything has got its problems, too.
        KDE tries to be a solution that — like a swiss army knife — tries to work for all cases. That is something that can work very well in many cases (and being a KDE guy I hope that it is the most successful solution). But that doesn’t mean that KDE is the right solution for every single problem.

        Anyways if you worry about the decline of Qt’s quality then I’d rather watch those additions to Qt carefully that have found their way into Qt recently and will find their way into Qt in the future. And to be honest I’m pretty happy with what has happened to Qt so far (2 years ago I could have imagined it a lot worse with a big company pushing Qt development). Not only with regard to added features but also with regard to bugfixes, performance speedups. etc.

      2. @Torsten:
        The main problem in this case is that Nokia and the Symbian Foundation are working on totally different solutions for the exact same problem: Provide widgets on top of QGraphicsView for touchscreen handhelds.
        In this specific case Mark is 100% correct that it doesn’t make any sense at all to have different solutions.
        It’s not about how the homescreen will look in the end or if MeeGo devices will have slightly higher resolution screens than Symbian devices.. That has nothing to do with this case.

        Mark isn’t pointing fingers. He made it clear in one post that the Symbian side (the side he’s working for) fucked up even more, because SDUI is 100% Symbian-specific while MDUI is portable and works different platforms already (that MDUI is portable wasn’t initially known to Mark, but as he called for a cross-platform solution, MDUI seems to be the better solution in the end).
        Symbian Foundation and Nokia obviously have interest to make the handheld Qt ecosystem as broad as possible with little effort as possible for developers to create applications for both Symbian and MeeGo.

        It’s not all down the drain, yet. Symbian^4 and MeeGo (aka Maemo 6) won’t be out till autumn or even winter. As long as both parties acknowledge that there was a communication problem and work to solve it, there’s enough time to get things straight.

        As KDE we have to be cautious, too. iPhone showed us that “as long as devs learn Qt, it’s all OK” won’t work if many aspects are still incompatible.
        iPhone didn’t brought more developers to the Mac platform, because much of the GUI coding stuff is very different from Mac OS X to iPhone OS X.
        Our interest as KDE should be that giving the development of Plamsa-Mobile, MeeGo and Symbian^4 apps should at least work and at least look somewhat integrated.

      3. @Markus I really find it hard to believe that UIEMO wouldn’t be hard to made portable, given that its a QGV toolkit. QGV is portable, UIEMO already runs on the N900 so we know its portable and I’m not sure how you could make it unportable if you tried. True Symbian being a different OS has some different APIs, and there’s plenty of #ifdef’s for Symbian in the little bit of UIEMO code that I’ve looked at. But really the point of Qt is that it abstracts all that, and UIEMO and Harmattan UI are both very much built on Qt.

        …and I think Torsten laid out pretty well what the future might look like. I completely agree with you Marcus that it would’ve been nicer if Symbian and Maemo had worked together and perhaps forked off a little bit to implement their specific requirements. It’s going to suck that some Symbian app can’t just be recompiled for Harmattan. But I’m not too pessimistic about the future even with both UIEMO and Harmattan UI running in consumer devices. These are competing toolkits developed by the same company, so someone in Nokia management will eventually be able to declare the winner with a stroke of a pen. The next few years were already going to be a bit chaotic in Qt Mobile as the various (also very important) Qt Mobility APIs get hashed out.

        Basically software engineering is really hard. 😀

  9. A link straight to that post would’ve served this blog well. That was informative. Instead it just linked to the beginning of the blog, which I had read through a few months ago… (obviously it kept going since then.)

    I was mainly frustrated by your blog since I had to read it 4 times to figure out what you meant since you made up your own terms, and the blog’s title is just yellow journalism.

  10. > Provide widgets on top of QGraphicsView for touchscreen handhelds.

    That wasn’t the only requirement for each of those frameworks.

    > fucked up even more, because SDUI is 100% Symbian-specific

    It’s not 100% Symbian specific. Last time I compiled example applications on Orbit it was possible to compile it on Symbian, Windows and Linux (and Mac, although not officially supported). What plattform do you think developers are supposed to develop on?

    > while MDUI is portable and works different platforms already
    > (that MDUI is portable wasn’t initially known to Mark,

    Looking at the thread I get the impression that he doesn’t know about lots of things. You also need to keep in mind that the thread happened on a maemo website with no or little
    involvement from UIEMO people. So what you read there is far from balanced and far from objective. I’d rather suggest that you look into both frameworks yourself and then try to draw your conclusions.

    > there’s enough time to get things straight.

    Right, getting things “straight” with regard to two codebases which have more than half a million code lines each – with different concepts and different requirements. And all that in about 4 months … could you check your claims before you make them? 😉

    1. Torsten is quite right, UIEMO is not Symbian specific at all, it runs on Windows, Mac, Linux, Symbian and Maemo. It has been written to be multi-platform from the get-go.

  11. 1) Both Symbian’s and MeeGo’s (ex Maemo) Qt based UI framework is actually developed by Nokia. None of those is developed by Symbian Foundation. Symbian Foundation is only co-ordinating the Symbian development, all developmnt is done by community members like Nokia.

    2) Symbian’s UIEMO (UI extensions for mobile) is MUCH more advanced, clean and complete framework than Maemo’s DirectUI. Maemo’s DUI is not even close to UIEMO. I personally would like to have UIEMO as a official framework on both Symbian and MeeGo,

    3) You said that of those two it’s the Maemo’s DUI which is portable. Actually that is not true. Symbian’s UIEMO already compiles and runs on Maemo.

    I actually am quite sure that Nokia will eventually completely drop the Maemo’s DUI and use UIEMO on both Symbian and MeeGo.

    1. And UIEMO compiles and runs on Linux, Windows and Mac too. So UIEMO is not Symbian specific at all.

      1. If things changed until today, that’s great. As I already wrote: My post is just a summary of what Mark Wilcox wrote.
        IMO the first priority is that both MeeGo any Symbian^4 share the same QGraphicsView widget framework. Which of the two will make it, is of less interest to me. As long as it’s a unified solution, it’s better than two different ones.

Comments are closed.