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

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

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.

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.

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

Who was that directed at?

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

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

DING DING DING! So we agree then?

Let me repeat myself:

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

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.

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

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

Thanks.

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?

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

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?

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.

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.

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?

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.

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?

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.

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.

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

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.

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

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

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

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.

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

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

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.

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.

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

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.

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.

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

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

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: