Maemo 6 loosing source compatibility with plain Qt, and Symbian^4 - Page 5 - maemo.org

daperl | # 41 | 2009-11-19, 18:24 | Report

Originally Posted by tomasj View Post

- 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

I read the linked article from your other post and neither you or that article convinces me you need a new layer on top of the already-top layer. There is no reason to subclass here. You should have just extended the already-top layer. Why can't the base application class have a platform API? It seems you arbitrarily made the decision that you can't abstract the concept of a platform at the already-top level. I would argue the opposite; that's exactly where you would want to do that. That way, I could truly write once and run everywhere; call this new platform API, Theming++. Then, a Theming++ developer could determine how "stuff" should work, look, ..., whatever for a particular platform.

Sorry, I'm not buying it; it seems like hype to me. Where would the subclassing of these enhancement layers end? You don't need a catchy new name to distinguish your UI enhancements. Besides, people will laugh at you if something called DUI crashes too often.

qgil | # 42 | 2009-11-19, 20:55 | Report

About these comments saying that Maemo and Symbian must accomplish more or less the same. If that would be true then the question would not be why to have two different UI frameworks on top of Qt but why having two different platforms to start with.

Maemo is meant for high end touchscreen devices with WVGA displays. Mobile computers, that is. Even if Symbian can reach this category of devices as well, the platform needs to champion in other form factors and hardware specs as well, including successful types of devices like e.g. the E7* series or others more basic.

Therefore the strategy of deploying a Qt based framework and the priorities obviously differ. If each platform should make compromises to half satisfy the other we will end up having two not good enough platforms. The ultimate point of covergence is Qt, a framework that is getting a big load of testing and innovation from two teams having champion products in the pipeline.

The Following 3 Users Say Thank You to qgil For This Useful Post:
jjx, ragnar, VDVsx

cristids | # 43 | 2009-11-19, 21:22 | Report

Originally Posted by qgil View Post

About these comments saying that Maemo and Symbian must accomplish more or less the same. If that would be true then the question would not be why to have two different UI frameworks on top of Qt but why having two different platforms to start with.
.

I am not saying that they should. I am saying that they already do. Look at them: both work on mobile devices, both capable of touch screens and probably both multitouch aware in the near future. I am not questioning why Nokia is keeping them both, mind you there is also windows mobile in the game. I only question why QT is not fullfiling its most powerfull objective/role: one coding targeting multiple platforms .

jsa | # 44 | 2009-11-19, 22:07 | Report

Originally Posted by qgil View Post

About these comments saying that Maemo and Symbian must accomplish more or less the same. If that would be true then the question would not be why to have two different UI frameworks on top of Qt but why having two different platforms to start with.

I understand that at the moment both Symbian and Maemo have their advantages and both are needed. For third party developers however the multiplatform strategy is far from ideal which is why a single UI framework to work with would be very welcome.

Originally Posted by qgil View Post

Maemo is meant for high end touchscreen devices with WVGA displays. Mobile computers, that is. Even if Symbian can reach this category of devices as well, the platform needs to champion in other form factors and hardware specs as well, including successful types of devices like e.g. the E7* series or others more basic.

You obviously have much more information about the plans than I do. I'm just saying that publicly the DirectUI and Orbit widgets that are to debut with Symbian^4 are _only_ for touch & touch+kb devices with hardware graphics acceleration. Sounds more Maemo devices to me than E7* series. With this in mind I think it's reasonable to be asking about the compatibility between M6 & S^4(not just plain Qt).

Originally Posted by qgil View Post

Therefore the strategy of deploying a Qt based framework and the priorities obviously differ. If each platform should make compromises to half satisfy the other we will end up having two not good enough platforms. The ultimate point of covergence is Qt, a framework that is getting a big load of testing and innovation from two teams having champion products in the pipeline.

As an end-user I have to agree, I don't want compromises. It's also in my best interest that both commercial and open/free software developers are happy. I hope it works out!

(Just thinking out loud here:

Maybe the Maemo 6 UI framework and the Symbian^4 DirectUI/Orbit are more or less the same thing and the "breaks" are indeed between device types(touch&accelerated vs non-touch) rather than platforms(Symbian vs Maemo) like gecebekcisi mentioned..)

Last edited by jsa; 2009-11-19 at 22:32. Reason: More speculation

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

gecebekcisi | # 45 | 2009-11-19, 22:42 | Report

Originally Posted by jsa View Post

(Just thinking out loud here:

Maybe the Maemo 6 UI framework and the Symbian^4 DirectUI/Orbit are more or less the same thing and the "breaks" are indeed between device types(touch&accelerated vs non-touch) rather than platforms(Symbian vs Maemo) like gecebekcisi mentioned..)

Thank God someone finally noticed my comment and the different (UI) needs of different (input) styles...

attila77 | # 46 | 2009-11-19, 23:19 | Report

Originally Posted by qgil View Post

There were 4 key people (at least) in the Maemo Summit with relevant roles relating to this subject: Tomas Junonen, Alex Luddy, Sergiy Dubovik and Ian Monroe. Did you go to their sessions? Did you talk to them?

It would also be helpful if slides or audio material from all the Harmattan presentations were available for us who are interested, maybe even were in Amsterdam but did not quite manage to get to the sessions in question

Let's be realistic, there is no complaining about things of this magnitude, especially at the stage of an alpha SDK. If it turns out good, wohoo, if it's (the unlikely) total breakage with regard to plain 4.6 compatibility, the best we can do is rant.

Attached Images

The Following 5 Users Say Thank You to attila77 For This Useful Post:
lma, Netweaver, pillar, qole, Stskeeps

svdwal | # 47 | 2009-11-20, 10:02 | Report

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:
pillar

NvyUs | # 48 | 2009-11-20, 10:23 | Report

symbian^4 is for touch and hybrid devices there will be no non-touch devices running symbian^4, symbian foundation made this clear months ago in there road map

sjaensch | # 49 | 2009-11-21, 11:23 | Report

Completely agree with the criticism. Obviously things need to be done differently depending on the platform. That's why I'm using a cross-platform library - to take care of those things for me. Why again do I need DuiApplication? Why can't QApplication on Maemo "automagically" do that for me? We do not have MacWidget and WinWidget, we have QWidget that takes care of the platform differences for me. That's what I want. If that is not possible, then what is the point of "Qt everywhere"?

Last edited by sjaensch; 2009-11-21 at 11:29.

The Following 3 Users Say Thank You to sjaensch For This Useful Post:
jsuggs, pillar, TA-t3

puelocesar | # 50 | 2009-12-01, 14:53 | Report

I just can't "get" the problem at all. They just made an abstraction layer to be easier to develop finger friendly applications. What's the problem with that?

If you don't like it, don't use the abstraction, just use plain Qt and be happy