Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 

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.

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 

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.

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 

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 .

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 

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.

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).

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..)

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 

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

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 

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.

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 

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.

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 

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

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 

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"?

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 

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