You can use plain Qt QGraphicsWidgets and QGraphicsItems in DUI containers.

http://doc.trolltech.com/4.6/graphicsview.html

A quote I picked up on twitter the other day which I really liked and seems very appropriate here:

-Mary Poppendieck

I was going to point out, again, that it's perfectly possible for two very different looking platforms, even with different interaction models to have a common core API. The reason being because you're not innovating so radically in UX that we no longer have basic concepts like lists and buttons - even if Harmattan does make a giant leap forward. However, it seems plenty of others are on the same page and have beaten me to it.

Considering Hildon's first incarnation as yet another UI framework for Symbian (Series 90) that no-one wanted to write apps specifically for, you'd have thought Nokia might have learned this lesson by now.

I know that the Qt folks are going to do everything they can to make things look good. However, if you're using fundamentally different building blocks the end result isn't going to be satisfactory - yes that's a prediction but it's one I'm fairly confident about.

No, this is an important distinction, we are discussing UI framework APIs here, nothing to do with how the things will actually look and everything to do with how much effort is involved in targetting multiple platforms.

We have one example here clearly spelled out in this thread. Qt 4.6 is missing any standard QGraphicsWidgets. If we want to build animated UIs we need some. If we want to build cross-platform animated UIs we need a common interface to them across platforms.

Developers can of course build their own QGraphicsWidget set in pure Qt. It's a lot of work. However, if their apps want to integrate well into Maemo and Symbian then they may well want to integrate with the theme engine - which is presumably separate again on each platform (I'd love someone to come and tell me otherwise, since we are surely in the realms of pure Qt here). Suddenly it's becoming a massive amount of work.

Being able to use custom QGraphicsItems and QGraphicsWidgets in the Maemo containers doesn't help at all (well you could possibly port Symbian ones to Maemo or vice versa - but that's not going to give the platform look and feel).

Of course it's all built with Qt, so it does mean you can have a lot more code reuse than you got historically, but we're still a very long way short of the cross-platform promise.

Mark

For those who are worried about compatibility of the QWidget based widgets in Dui, you might be interested in about the itemview-ng project in Qt Software.

Their goals is to make all the Q*Widgets to run natively on QGraphicsView. I guess this would solve most of the problems discussed here related on code compatibility. I don't want comment anything about having to different platforms here because I couldn't care less about symbian stuff

See Thiago's comment on Qt labs discussion:

": to have all of the widgets available “natively” in Graphics View, to have them accessible from QML and to have native styling.

As for CSS, we’re probably just going to ditch that in favour of QML."

They will also introduce similiar kind of MVC model than DUI does. You can checkout the source code from git and check the examples.

More information:
http://labs.trolltech.com/blogs/2009...-have-liftoff/
http://qt.gitorious.org/qt-labs/itemviews-ng

For me this sounds quite good. What do you think? I'm not sure if this "feature" will be available for Maemo 6...

Addition:One thing came to my mind that there will be two different MVC mechanism when both Dui and Qt releases their systems. Instead of having two almost identical systems, could they put effort to develop only one, but make it really good?

Hi zchydem,

This is the pretty much the same argument I'm making about the duplication with the Symbian framework.

You may not care about Symbian and that's fine, but every Maemo fan should care about UI framework compatibility for Maemo and Symbian because it'll mean more apps that run on Maemo (OK so a lot of them probably won't be open source, and you may still not care).

Yes, the next generation widget set from Qt is a great thing! Possibly the solution to the current mess is that the community gets behind the Qt widget effort and there's proper platform styling for Maemo & Symbian - then everyone writes pure Qt and we can all ignore Dui and Orbit. Maybe, just maybe - this is exactly the troll plan. They should have this ready by the time the devices ship and they obsolete the stuff the product platforms have done as far as 3rd party developers are concerned.

Mark

I'd like to point out (as many probably already are aware of) that Qt code will be source compatible as long as its running on a supported platform.

I wouldn't put my money on itemview-ng. It's a great research project but not much more. Not to mention that it will take years until it become part of QT. I would suggest to all angry people download Harmattan UI Framework, review code, suggest new apis and ideas and help us make it a mainstream framework (for instance many comments from zchydum are already in master). There is a lot of things to do for everyone. However I agree it's fun to blame developers which secure their jobs for fragmenting frameworks. Haha. There are only 2 guys in libdui who still work since the beginning of project.

Hi dubik,

Thanks very much for coming to get involved in the conversation.

Really? Years? It seems stuff in Qt-labs typically gets to the mainline a version or two later - maybe Qt 4.8?

Excellent! As soon as the Symbian folks have released their UI framework code I'll start comparing and contrasting and seeing where we can get the quickest wins.

It's never developers that make the decisions at this level - typically someone somewhere in the upper reaches of middle management who hasn't touched code for 5+ years. There's also a big difference between what people fear will happen in a re-org and what actually happens afterwards.

What about one of the comments on this thread, is DuiApplication really needed, or can things be pushed back into the private implementation of QApplication? I realise the libdui guys can't do that on their own, but in theory?

please...

Having two differing widgets/application based on the same codebase is only a minor inconvenience, easily handled with #ifdefs and differing ui forms, if even needed. Heck, you can even load the ui forms at runtime, offering the ability to change the gui without recompiling. Not to mention Qt Kinetic.
The same differences have existed between Qt, Qtopia, and KDE for a decade, and I have personally been there, and done that for the last decade (think Sharp Zaurus 5000D). It's not that difficult, really.

I don't think it's a big of a deal as you make it out to be. I wrote an app - Gutenbrowser, that can be run on Qtopia, Qt desktop, Qt embedded, KDE, or whatever. (Although the Qtopia code has been abandoned for obvious reasons). It wouldn't be all that difficult to bring back the QtopiaApplication, if the need arises.

Don't make mountains out of mole hills.

Here we go again. Nokia never learns from its past mistakes.

I really like the direction that the itemview-ng project is heading for. And definitely qml is the greatest addition to Qt stack since webkit. Qml finally allows separation of UI and business logic in a way that makes sense (which is that there is also scripting for the UI so that almost all user interaction can reside in the script portion of the application). With qml and especially the itemview ng, there is true portability of at least the UI level.