maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   MeeGo / Harmattan (https://talk.maemo.org/forumdisplay.php?f=45)
-   -   Maemo 6 loosing source compatibility with plain Qt, and Symbian^4 (https://talk.maemo.org/showthread.php?t=34686)

daperl 2009-11-19 18:24

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

Originally Posted by tomasj (Post 382077)
- 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 2009-11-19 20:55

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.

cristids 2009-11-19 21:22

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

Originally Posted by qgil (Post 382750)
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 2009-11-19 22:07

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

Originally Posted by qgil (Post 382750)
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.

Quote:

Originally Posted by qgil (Post 382750)
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).

Quote:

Originally Posted by qgil (Post 382750)
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..)

gecebekcisi 2009-11-19 22:42

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

Originally Posted by jsa (Post 382875)
(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 2009-11-19 23:19

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
1 Attachment(s)
Quote:

Originally Posted by qgil (Post 381273)
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.

svdwal 2009-11-20 10:02

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

Originally Posted by tomasj (Post 382077)
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 :p

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.

NvyUs 2009-11-20 10:23

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

sjaensch 2009-11-21 11:23

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

puelocesar 2009-12-01 14:53

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

w00t 2009-12-01 14:57

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

Originally Posted by puelocesar (Post 402844)
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?

The problem you need to get is that this abstraction layer pretty much throws the "code less create more deploy anywhere" mantra out the window.

You end up going from writing one set of UI code that will work on any OS on any platform (naturally, with scaling down for mobile devices, i.e. showing less information and so on) to writing two totally separate UIs.

bbns 2009-12-01 15:03

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
please do not forget QML. If you do not know QML, please search a bit, it can help you fast construct different UI layouts under the same backend.

devices fragmentation is inevitable, but QML can help you reduce the pain alot easier. It's running on N900 by the way.

w00t 2009-12-01 15:06

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

Originally Posted by bbns (Post 402865)
please do not forget QML. If you do not know QML, please search a bit, it can help you fast construct different UI layouts under the same backend.

Who was that directed at?

bbns 2009-12-01 15:10

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
sorry I didn't get your question. QML supposes to help you running same apps under different 'skin'.

puelocesar 2009-12-01 15:17

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

Originally Posted by w00t (Post 402855)
The problem you need to get is that this abstraction layer pretty much throws the "code less create more deploy anywhere" mantra out the window.

You end up going from writing one set of UI code that will work on any OS on any platform (naturally, with scaling down for mobile devices, i.e. showing less information and so on) to writing two totally separate UIs.

Why the hell I want my finger, small resolution optimized UI running on desktop with high resolution and mouse? That just doesn't make sense.

Different type of use, different UI. You guys must learn user centered design. The user needs on a phone/tablet/mobile are very different from the user needs on a desktop.

w00t 2009-12-01 15:25

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

Originally Posted by puelocesar (Post 402889)
Why the hell I want my finger, small resolution optimized UI running on desktop with high resolution and mouse? That just doesn't make sense.

I'm not talking about word processors here. I'm talking about applications (typically) oriented towards phone usage. Smaller games like (to pick a simple example), Solitaire.

Likewise, it goes against everything that Qt developers have been working with for the past X years. This is why you see things like KDE running on the n900.

By the way, why is it so hard to allow finger optimisation & usage of the existing widgets without the need for yet another layer of crap? It's not. Take a look at QML and things like the animation API. Take a look at other posts in this topic.

Simple maths, if I can make a product with Qt and sell it on Symbian, Windows Mobile, and desktop platforms (less important, but hey - there is some market for small time-killing games) and Maemo (with Qt but bastardised with DUI), then I'm going to target Symbian only, because that has the bigger marketshare by far. It's their funeral.

Quote:

Originally Posted by puelocesar (Post 402889)
Different type of use, different UI. You guys must learn user centered design. The user needs on a phone/tablet/mobile are very different from the user needs on a desktop.

Focusing on the user doesn't entail throwing out years worth of API design, tools, and knowledge, just because someone has a case of "NIH Syndrome".

w00t 2009-12-01 15:31

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
Let me just make a clarifying statement here.

I'm not saying that means should be dictated by a lowest common denominator, and that there is absolutely no need for DUI simply because it doesn't exist - but as far as I can tell from what I've read up on it, there isn't any need for it because QtAnimation and QML and other similar technologies are already working towards the goals it seems to want to achieve, in a more agnostic, abstract fashion.

I'm all for new toys going into Qt as a result of Qt working with the Maemo and Symbian teams, I just really hope that it's going to happen in a rigorously controlled fashion so that Qt as a product doesn't disintegrate into a ball of horrible mess instead of the (fairly sane) controlled offering it has been in the past.

puelocesar 2009-12-01 15:33

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

Originally Posted by w00t (Post 402908)
Focusing on the user doesn't entail throwing out years worth of API design, tools, and knowledge, just because someone has a case of "NIH Syndrome".

Hoho, now I'm reading a big piece of BS. Sorry but now I just can't take you seriously anymore.

I just can't take for serious a developer that doesn't cares about the user.

w00t 2009-12-01 15:35

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

Originally Posted by puelocesar (Post 402924)
Hoho, now I'm reading a big piece of BS. Sorry but now I just can't take you seriously anymore.

I just can't take for serious a developer that doesn't cares about the user.

Thanks. I'll take your dose of ad hominem and raise you a straw man.

If you're seriously saying that things like DUI, which duplicates existing work, doesn't make you worry about platform fragmentation then I'd have to wonder how on earth I can take you seriously as a developer, regardless of how much you proclaim to care for the user.

puelocesar 2009-12-01 15:53

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

Originally Posted by w00t (Post 402927)
Thanks. I'll take your dose of ad hominem and raise you a straw man.

If you're seriously saying that things like DUI, which duplicates existing work, doesn't make you worry about platform fragmentation then I'd have to wonder how on earth I can take you seriously as a developer, regardless of how much you proclaim to care for the user.

You can think whatever you want. In my opinion, and you can find several examples illustrating that, a software that doesn't attend the user needs is irrelevant, no matter how well engineered it is.

Of course I'm not saying things shouldn't be bad engineered, don't misuse my words, and again, I still doesn't see how an abstraction layer can be so harmful. KDE uses one the same way and there's no one pointing fingers at them.

w00t 2009-12-01 15:56

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

Originally Posted by puelocesar (Post 402964)
You can think whatever you want. In my opinion, and you can find several examples illustrating that, a software that doesn't attend the user needs is irrelevant, no matter how well engineered it is.

And where am I saying that they shouldn't attend to user needs, pray tell? *ALL* my post says is that *IF* DUI (or anything else) is needed, it shouldn't duplicate existing work (like QML+QtAnimation), and it should be properly designed. So far, from what I've seen, and from reading the notes of a few other people who have looked into DUI, it doesn't look all that fantastic, as well as looking remarkably foreign compared to the *rest* of Qt.

Quote:

Originally Posted by puelocesar (Post 402964)
Of course I'm not saying things shouldn't be bad engineered, don't misuse my words, and again, I still doesn't see how an abstraction layer can be so harmful. KDE uses one the same way and there's no one pointing fingers at them.

DING DING DING! So we agree then?

Let me repeat myself:

Quote:

Originally Posted by w00t
I'm not saying that means should be dictated by a lowest common denominator, and that there is absolutely no need for DUI simply because it doesn't exist - but as far as I can tell from what I've read up on it, there isn't any need for it because QtAnimation and QML and other similar technologies are already working towards the goals it seems to want to achieve, in a more agnostic, abstract fashion.


sjaensch 2009-12-02 11:45

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

Originally Posted by puelocesar (Post 402964)
Of course I'm not saying things shouldn't be bad engineered, don't misuse my words, and again, I still doesn't see how an abstraction layer can be so harmful. KDE uses one the same way and there's no one pointing fingers at them.

And you don't see the problem with that statement? The goal of Qt is easy cross-platform development. The reason for Qt on Symbian, Maemo and WinMo is to be able to easily develop across these (different, but similar) mobile platforms.

The difference between KApplication and QApplication is that QApplication runs on any Qt-supported platform, while KApplication requires KDE (libraries). If I wanted to restrict myself to developing just for Maemo (6), why would I need Qt anyway? Just because it is a nice library?

The cost savings that Qt offers for developing across these mobile platforms are purposefully thrown overboard here. I have yet to see an example of something that needs to be done on Maemo 6 that can't be done by QApplication etc. directly.

If I develop for iPhone, I'm developing one application. It runs on all iPhones and all iPod touchs. Same with Android. Obviously I need to take care of different screen sizes and so on, but that is doable. What I would like to know is how a sample Maemo 6 application source looks like in Nokia's view. How do I get to compile/run it on Maemo and Symbian. Obviously I want to be the best citizen I can be on each platform. So do I have to #ifdef my way around which classes I inherit from / use? What kind of a mess is that? Or am I expected to develop a library with the core functionality and then write 3 UIs on top of that, one for each mobile platform? I just don't get it.

w00t 2009-12-02 11:49

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

Originally Posted by sjaensch (Post 404538)
So do I have to #ifdef my way around which classes I inherit from / use? What kind of a mess is that? Or am I expected to develop a library with the core functionality and then write 3 UIs on top of that, one for each mobile platform? I just don't get it.

This was exactly my point, but you expressed it much more succinctly here.

Thanks.

HangLoose 2009-12-02 11:58

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
So, in a nutshell...

If I start developing with Qt 4.6, will the same program run in different devices just with minimal adjustments? Or is just a promise?

Same goes for platforms, if I write on Linux can it run on Win?

conny 2009-12-02 13:07

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

Originally Posted by HangLoose (Post 404553)
So, in a nutshell...

If I start developing with Qt 4.6, will the same program run in different devices just with minimal adjustments? Or is just a promise?

Same goes for platforms, if I write on Linux can it run on Win?

The answer given to that earlier was: If you stick to plain Qt, then yes. If you use Maemo specific Qt extensions (DUI), then no.

The question is, what features will you miss if you stick to plain Qt and is it possible to use DUI only in small areas of your app (e.g. for 2 special buttons) without basing your whole UI on DUI?

cristids 2009-12-02 13:16

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
Well the infection seems to be spreading. I think Qt lost it . In this article http://labs.trolltech.com/blogs/2009...ext-iteration/ they are saying new classes got in the QT special for maemo.

Quote:

Several new Maemo 5 specific classes were added:

* QMaemo5ValueButton: Implements a “Picker Button”, basically a button with an extra value
* QMaemo5KineticScroller: Implements the Maemo 5 kinetic scrolling algorithm
* QMaemo5AbstractPickSelector: An abstract interface to implement Maemo 5 “pickers”, plus a picker implementation for time picking
* QMaemo5InformationBox: Support for Maemo 5 Banners and Notes
* QMaemo5EditBar: Support for Maemo 5 Edit toolbar


I think no cross developer can afford to use them so they are plain wrong. I mean in the end we wil have some symbian classes and some maemo classes and maybe some wm7 classes. What am I suppose to use? #ifdef don't sound so good.

And they are maemo 5 specific? What about maemo 6 ? Wil they have their own set? Nice.

w00t 2009-12-02 13:25

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
Yeah. I came across this this morning, and immediately started dying inside. This is such a *terrible* idea, and I can't imagine who on earth signed off on it...

I imagine this is happening because it would take too long to work up the existing tech (QtAnimation & co) or to properly shoehorn Maemo concepts into the existing Qt API - and I can understand that - but stupid decisions like this can *only* harm uptake of Maemo development in the future. Save a few months now, ****** development uptake of your platform for a few years in the future.

QMaemo5KineticScroller scares me the most out of those I think. Who the **** came up with that monstrosity of an idea? I mean, I can almost understand some UI elements and widgets might require a more platform specific implementation, if at least temporarily, but kinetic scrolling is *not* something limited to one platform! Or does Symbian not exist at all now?

sjaensch 2009-12-02 15:50

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
Yes. I already have the first two #ifdefs in my application just to get kinetic scrolling. And here is the best part: as far as I can gather, that's not even platform-specific code (works for all of Maemo), but just a hack for Maemo 5! In Maemo 6, it will be done differently (i.e. there will be no QMaemo5KineticScroller)!

So either stick to vanilla Qt (which means your app compiles and runs also on Symbian, Windows and Mac) or be prepared to target *just* Maemo 5, then later *just* Maemo 6.

qole 2009-12-02 18:12

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
How about some naive optimism!

Maybe the Maemo 5 hacks are just that -- temporary "bridge" hacks to make the most of a bad situation, since Maemo 5 is out the door already and they can't fix that situation.

Maybe Maemo 6 will use standardized "mobile" widgets that will work in Symbian too!

Wouldn't that be a lovely world?

vvaz 2009-12-02 19:09

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
Judging from whole history of Qt I think qole is right - those are just temporary hacks to push round Qt4.6 block through square Hildon hole.
If they wanted to make it permanent names would be more like QMaemoKineticScroller etc.
Note also it is "Technical Preview" version of 4.6 for Maemo - not super-final-stable version. They may vanish as soon as official build of 4.6 will be released. Or more probably will be properly integrated into main sources with 4.6.1 release or something similar.

w00t 2009-12-02 22:39

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
I'd love to be optimistic about all of this, and I'm trying very hard - Qt has an impressive track record for avoiding flops (things like Phonon aside.. *ahem*) - but the fact that this stuff exists in the way it does now doesn't fill me with optimism. Unless they push hard to shoot for the skies, people will always always going to put up with stuff that "works".

Even if we do leave aside the QMaemo5 stuff that will cause nightmares both in terms of moving to harmattan, and in terms of other platforms (I won't beat that drum again), that still leaves Dui* existing in a rather odd not-in-mainline-not-in-any-other-platform-than-maemo type void, without a clearly defined purpose for existing in the first place. And it doesn't just subclass QApplication, it seems to subclass just about everything.

And @vvaz: yes, it's a technical preview, for which I am very grateful. Qt 4.6 has demonstrated fairly well that developing out in the open is a wonderfully productive methodology to use. I just hope that the feedback in this thread isn't going into /dev/null, and they're actually going to address the concerns people are raising.

qgil 2009-12-03 08:10

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

Originally Posted by w00t (Post 406125)
I just hope that the feedback in this thread isn't going into /dev/null, and they're actually going to address the concerns people are raising.

Do you mind joining the official Qt for Maemo developer mailing list where you have Thiago and the rest of Qt champions answering questions quite promptly?

About people "not seeing" what Maemo 6 brngs on top of Qt, the discussion is indeed more than abstract before the release of a first Harmattan SDK.

w00t 2009-12-03 09:57

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

Originally Posted by qgil (Post 406833)
Do you mind joining the official Qt for Maemo developer mailing list where you have Thiago and the rest of Qt champions answering questions quite promptly?

Sure :). Is that qt-maemo-feedback@trolltech.com?

sjaensch 2009-12-03 10:12

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

Originally Posted by w00t (Post 407031)

I asked him the same by email. But I guess qgil is on his way to Barcelona now. :) Anyway, I think that is the mailing list he meant.

w00t 2009-12-03 10:47

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

Originally Posted by sjaensch (Post 407077)
I asked him the same by email. But I guess qgil is on his way to Barcelona now. :) Anyway, I think that is the mailing list he meant.

*nod*. I'm subbed, and working on a summary of this thread now.

I'll send it by tonight, how quickly depending on workload etc.

vvaz 2009-12-03 11:46

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

If you have any conclusion from discussion there it would be good to make summary here.

ColonelKilkenny 2009-12-03 14:09

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
Where did you guys get the idea that DUI-stuff is Maemo only? Symbian people have been talking about Direct UI for at least a year (IIRC), so I've thought that Direct UI is the DUI we're talking here. Which would mean that they're pushing it to both Maemo and Symbian.

And personally I wouldn't worry about that QMaemo5 -stuff. As others have already pointed out, it's very much work in progress and Thiago (or someone else with the knowledge) already made a comment about the situation in Qt blog and I'm pretty sure they'll know what they're doing.

daperl 2009-12-03 15:40

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

Originally Posted by ColonelKilkenny (Post 407534)
Where did you guys get the idea that DUI-stuff is Maemo only?

Who said anything about "Maemo only?" We were talking about Qt in general. The onus is on you to explain why in 2009 I would need more than one API for all of my applications. Desktop or otherwise. Or don't you believe in write once, run everywhere? Rergardless, some of us do. Hopefully w00t is going to get to the bottom of this.

TA-t3 2009-12-03 16:12

Re: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4
 
Exactly. When I code I code on the desktop, or the laptop, or anywhere, and not necessarily where I have a scratchbox w/emulator available. I want to be able to do that with the generic QT API on e.g. a Debian box (taking into account only the screen size of the application), and simply rebuild for Maemo when I approach the testing phase. In this age of objects it shouldn't be necessary to sprinkle #ifdefs into the code just to accomodate a different set of boilerplate code.

The burden should be on the library versions for the different platforms to do the right thing behind the curtain, not for the QT library user to #ifdef around different APIs. That's what we had to contend with on GTK for Hildon, and IMO that severly limited the range of good applications we got in the end.

ColonelKilkenny 2009-12-03 16:53

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

Originally Posted by daperl (Post 407762)
Who said anything about "Maemo only?" We were talking about Qt in general.

w00t? And I'm pretty sure that quote below is not the first time this "DUI is in Maemo only" appears in this thread...

Quote:

Originally Posted by w00t (Post 406125)
... that still leaves Dui* existing in a rather odd not-in-mainline-not-in-any-other-platform-than-maemo type void ...

Quote:

Originally Posted by daperl (Post 407762)
The onus is on you to explain why in 2009 I would need more than one API for all of my applications. Desktop or otherwise. Or don't you believe in write once, run everywhere? Rergardless, some of us do. Hopefully w00t is going to get to the bottom of this.

I don't need to explain anything and you don't need to use more than one API (Qt API) for all your applications.

And btw. I'm pretty sure that my first post to this thread made it pretty clear what I think about the situation.
However, I'm capable to understand the fact that Nokia (& former Trolltech) devs know a thing or two more about the situation than I (probably ever) do and they may actually have a reason for doing all this :eek:


All times are GMT. The time now is 06:13.

vBulletin® Version 3.8.8