Thread: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
View Single Post
svdwal is offline svdwal
2009-11-20 , 10:02
Posts: 19 | Thanked: 56 times | Joined on Nov 2009 @ The Netherlands
#47
Originally Posted by tomasj View Post
Hi everyone, my name is Tomas Junnonen and I'm the guilty party who gave the introductory talk to the Maemo 6 UI Framework at the summit. Quim kindly pointed me to this thread so that I could address the concerns raised.

First of all, the headline is definitely not true

Qt remains a cross-platform toolkit and is definitely source compatible across the desktops as well as Maemo and Symbian. Qt-only applications in Maemo 6 are first-class citizens, we're putting a lot of effort into making sure they integrate well, look nice and that things like kinetic panning "just works" as one would expect simply by compiling for Maemo.

[knip]


I hope this clarifies things a bit

I'll just take this opportunity to address some specific questions raised in the thread:

- DuiApplication vs QApplication. Like KDE and others, we do extend the base application class. Qt, being platform agnostic, cannot really do any initialization that being part of a specific platform typically entails. For example, it has no way of knowing where the translation catalogs for the application is located on the system. DuiApplication checks what is the active language (from the platform configuration system), loads the correct translation catalog, checks and initializes the active UI theme, connects the application to the system message bus and so on. It's tedious work, but someone has to do it
Of course, somebody has to do it, but it is an implementation issue. Windows has different requirements from MacOSX, and those differences are hidden inside the multi-platform library. That's the whole point of a multi-platform library, clients do not have to be bothered with that kind of stuff. Not even by having to rename the class.

I am not familiar with gtk+ and linux, but on Symbian there were three variants of their main application classes and none of these variants changed the API. Result: three different sets of UI level application code instead of one, three times as much maintenaince, and in no time the platforms were diverging as well. This has been one of the major criticisms developers were having with Symbian OS, as it made developing for the platform three times more expensive. Here we are a few years down the road, and what happens: same mistake, introducing new names, no functional differences for the application itself, opening up the potential for API divergion.

The way I see this design, QtGraphicsWidget will be the native widget class for both Maemo 6 and Symbian^4. Excellent. So this also means that if there is some boolean checkbox widget, this widget will have exactly the same API for both platforms. Then, QtWidget for Maemo 6 will be implemented in terms of QtGraphicsWidget, because there is no historical widget class for maemo 6. On Symbian ^4, QtWidget can be implemented in terms of a QtGraphicsWidget too, or as some Avkon control, whatever they think is best.

I can now choose: a QtWidget with the advantage of it being highly portable, and automatic inclusion of host platform goodies that fit the QtWidget interface. Or I can choose a QtGraphicsWidget if I need its extra graphics capabilities. So the choice of portability versus max device utilization is mine. And, it will only be made for the places where it matters, not in boilerplate code.

The boilerplate code, QtApplication, QtWindow and whatnot stays the same for all apps. this means I will have zero porting costs when one of the other platforms becomes multitouch and supergraphical. There is no need to rename things, there is no need to branch or merge, nothing. Compile with the library, done.
Exactly what one expects and therefore demands from a multi-platform library.

You see, the other option that I have it to start implementing my own system-indendent library on top of either Qt or Dui, using the bridge pattern That's not hard, but it will be daft.
 

The Following User Says Thank You to svdwal For This Useful Post: