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

why do they have to maintain two in future? s60 no longer as to be maintained by nokia as its dead and all code is/will be contributed to symbian foundation for the new unified symbian platform, where it will not be there sole responsibility to maintain.
btw you forgot about s40 from what I've read in the future sometime symbian will replace it on low to mid priced devices so they will have gained 1 platform and lost 1 1/2

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

I am not familiar with Qt, but it looks to me like svdwal has a good point. From what I can figure out Qt appears to go down the road of the Hildon add-on to Gtk+, where in many places the original Gtk call was simply replaced with an equivalent Hildon call. The right thing would have been to leave as much as possible in place, and just provide library versions where the standard Gtk calls were modified to do the Hildon thing.

Instead, to create a multi-system (desktop+Hildon) application you had to sprinkle the code with #ifdef and the like. Obviously the application itself will always have to be small-display compatible, but in addition to that the Hildon version of Gtk+ added (in my opinion) unnecessary replacement functions for standard stuff.

So, instead of the special-for-Maemo-6 Qt functions, wouldn't it be possible to massage the underlying objects/functions, to minimise the boiler plate code changes?

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

Why ? It's a framework based framework build on top of a framework which is a part of that first mentioned framework. What's not clear and understandable here ? :D

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

If you look at Maemo 6 UI framework technical preview, you can notice that widgets in this framework are built on top of Qt's QGraphicsView technology. If you look at Qt Labs blogs, QGraphicsView has biggest amount of blog articles published among all categories (http://labs.trolltech.com/blogs/cate...graphics_view/). Note that QGraphicsView is rather old -- it first came as Qt API in 2006, way before Nokia has considered anything regarding Qt.

QGraphicsView is used as basis for KDE4 Plasma. This is currently major user of QGraphicsView API among released software. And common trend in Qt circles is to move interfaces to something QGraphicsView based.

So if you look through this perspective, Maemo 6 UI based on QGraphicsView is not really something radically departing from what "mainstream" Qt development is geared towards. Of course, it has its own quirks and design decisions but that is something you would need to look at with real facts and circumstances considered.

Interestingly enough, there is no widget set in Qt API based on QGraphicsView itself. So If you are going to use QGraphicsView, you are building widget set yourself.

I know almost nothing about Symbian^4 design decisions but to me it looks like they are going a similar direction with QGraphicsView being a basis for their widgets.

Now, this is interesting: what are differences in operating systems *behind* UI that can influence UI to be substantially different? You may hide certain portable things behind a common facade, however, is there anything that is really so different in Symbian/Unix designs that is hard to unify/represent in the same way?

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

I am total newbie but I guess Direct UI could be used for touch based desktop systems in the near future too, so the source compatibility break would be caused by developers' target UI (touch&nontouch) decision, instead of target platform decision.

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

I think this is indeed a very bad news. I was under impression nothing could break the Qt cross platform as up until now you were able to create an application and run it in Linux and Windows and it always looked proper on the host os. Hack I even took a windows small app and run it on wm 6.1 and it looked as it should. Just like a native application.
I really cannot understand why when qt gets compiled to maemo the UI doesn't bind to an underline maemo library of widgets, same goes for symbian or linux or something else and look the same from a coding perspective the same. And use in addition styles to skin as desired.
If multi touching doesn't work on that platform then simply it will be disabled. If touch screen is not available than disable that too.

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

Wow, if the OP is correct, what an epic fail. Again, if true, the person who made this command decision should be sent to the mail room.

I'll try to make this simple: Branching is the "goto" of software design. If you don't know how to extend functionality at this high of a level without breaking things, get out of the way. You're most likely not qualified to design software. You might be an excellent coder, hacker, ..., whatever, but you're lacking some high level abstraction skills. Or maybe just ask someone for help, but seeing what I see above is heresy. I think I'm gonna be sick.

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

I would recommend reading Plasma documentation on why traditional widgets are not enough for "contemporary" UI development. http://techbase.kde.org/Projects/Pla...aysOfThePlasma is a good start. Don't know what was behind Maemo 6 UI but to me Plasma's arguments look quite close.

I have seen many commercial applications for Windows done with and without Qt. Trend there is certainly going outside of capabilities of traditional widgets provided by "standard" UI toolkits.

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

Are you Humphrey Appleby? ;)

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

What I would be interested to know is that if QGraphicsView is the way to go, which means not using standard (let's call them e.g. "Desktop") Qt widgets...

Then what exactly is the strongly emphasized cross-platform story of Qt on the UI level (not just Nokia's Maemo and Symbian, but other Qt platforms)?

To maximize cross-platformity, one extreme possibility would be for each and every application to code their own QGraphicsView-based widgets themselves from scratch, but I fail to see the cost-efficiency and UI consistency in such approach.