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

[Note: this is a copy of a message I posted at Forum Nokia, about compatibility between the Maemo6 UI and the and Symbian ^4 UI, this being my main concern. But because Maemo 6 is also breaking source compatibility with Qt in general, I am posting here as well, as Qt's single source/multiple deployoment is being used to attract developers to Maemo too]

I would like to know Nokia's official position on source code compatibility between Maemo 6/Qt and Symbian^4/Qt.

As far as I know, Qt enables single source/multi-platform programming, and that ability was the main reason Nokia has bought Trolltech. I have seen live demo's of a single source Qt app compiling to both Windows XP and S60 5th ed.

Also, Qt is currently being advertised by Nokia in both the Symbian Developer community and to other (mobile) developers as enabling them to a single source app and deploy it on multiple platforms, including some mobile ones (not the one we need, but anyway).

If one looks at such a source I see some kind of archetypical app looking like (from the Qt 4.6.0 beta release)

#include <QApplication>
#include "mainwindow.h"

int main(int argc, char *argv[])
{
QApplication app(argc, argv);
MainWindow window;
window.showMaximized();
return app.exec();
}

So, I would expect code for Maemo 6/Qt to look exactly like this.

However, on this site [http://zchydem.enume.net/?p=128], which is linked to from maemo.org, and also in the Harmattan source repository (http://qt.gitorious.org/maemo-6-ui-f...hnical-preview), the example code looks like this

#include <DuiApplication>
#include <DuiApplicationWindow>
#include <DuiApplicationPage>
#include <DuiButton>

int main(int argc, char *argv[]){
DuiApplication application(argc, argv);
DuiApplicationWindow window;
window.show();
DuiApplicationPage page;
new DuiButton("Hello", page.centralWidget());
page.appear();
return a.exec();
}

Apart from a certain API similarity I would not say this is Qt code. And even if it is Qt code, with DuiApplication being a subclass of QtApplication, it is immediately clear that there is no source compatibility here.

On developer.symbian.org there is talk (http://developer.symbian.org/wiki/in...Prop/Direct_UI) about a Qt based Direct UI, which abbreviated looks just like Dui. But in the paperwork I've seen there are no API's by name, so it is not possible for me to verify whether Dui on maemo 6 and Direct UI on Symbian^4 are the same.

So, some questions

1) Are Maemo 6 and Symbian^4 both going to use this Dui/Direct UI library? If not, why not?

2) Why is Nokia departing from Qt single source/multiple deployment promise for this particular case. I can imagine one might need new widgets for new controls, but I fail to see the technical reason to create a new application class.

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

Just googleing Qt Direct UI turned up a ton of stuff about this. Direct UI is nokias "finger friendly" UI add on to Qt which will be used on both Maemo and Symbian (and maybe not just Maemo 6 and Symbian^4, it may well be on 5 and ^3 too).

One article here http://mobileduo.blogspot.com/2009/0...-orbit-qt.html

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

heres some info about symbian^4 from symbian foundation blog

Symbian^4

Planning for Symbian^4 is at an earlier stage. It follows Symbian^3 by around six months.

The following technology contributions are expected to be fully integrated for Symbian^4:

* Qt optimised for the Symbian platform – Qt is a well-liked application and UI framework;
* A new “Orbit” extension library for Qt, which contains more than 50 widgets tailored for mobile user experience, and which will provide a replacement for the existing “Avkon” widget set;
* A new “Direct UI” interaction and navigation logic, combined with finger-optimised layouts offering excellent touch and hybrid-device user experience;
* The application suite re-factored and re-written to take advantage of Qt APIs, Orbit widgets, and Direct UI.

Elements of this combined offering will of course be available for experimentation ahead of their full integration in Symbian^4.

http://blog.symbian.org/2009/04/30/r...-release-plan/

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

@svdval: As I understand it, it's not *instead* but *on top* of Qt 4.6 (i.e. Qt4.6 != Maemo 6 UI framework). So your original example would still work, but probably with some visual/input limitations (a bit like GTK and Hildon, but the Dui stuff is much broader). People more into Dui stuff, feel free to correct me :)

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

Plain Qt 4.6 applications will run in Maemo 6.

The Maemo 6 UI Framework will offer additional / optimized features for projects interested in Maemo specific integration. Such optimizations are being proposed to the Qt team to be integrated in future Qt releases, either in the "generic" Qt or the Qt Mobility libraries.

The Maemo team (or the Symbian team) can have the "luxury" of productizing such additions / optimizations faster since the Qt team is developing a common toolkit for several platforms, and this requires a lot of extra work on development (sometimes rewritting entirely a library) and testing.

There will be enough time of Harmattan pre-releases for developers to figure out how well their plain Qt projects run and feel in Maemo 6, how interesting are the Maemo optimizations offered, how much extra effort is needed and if it's worth... And also plenty of time for providing feeedback to the Maemo and Qt teams, file bugs, etc.

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

I think it's this conversation behind the link that makes svdwal anxious about the compatibility between Maemo6 and Symbian^4. From what I gather, there is no official stance from Nokia on this.

http://developer.symbian.org/forum/s...ead.php?t=3363

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

There is a lot of stuff, but none of it on an official Nokia website, such as Forum Nokia. Blogs have their advantages, but them clearly being an official company policy repository isn't one of them.

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

Any reason for two different UIs on Maemo and Symbian, both sitting on top of Qt? I could understand that there is no specific layer on top of Qt for, say, Linux or Windows, but since both Maemo and Symbian will be ran on touch based devices, I don't see the point of two different UIs.

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

I don't believe it is a good idea to push Direct UI all the way to the application level. The whole point of Qt is it being a library that hides as much as possible of the host platform. So if you introduce a DuiApplication class and assorted other Dui classes will result in 2 things

1) porting existing Qt apps will become harder and more expensive.

2) by the time all systems are multi touch, one would expect Dui to be changed back to Qt. So all apps will have to be ported again.

That's two times work for nothing, with no value being added.

Worse, you cannot advertise to developers that Maemo is a proper Qt platform. It would be if your existing Qt code would compile straight away, and that it would "magically" incorporate multitouch as far as that is possible without application adaption. The only thing I would expect to add code for is those bits of multi-touch that the system cannot abstract away from user code. But that is fine.

Let me give an example. On a multitouch system one can imagine setting a row of checkboxes (representing a set of booleans) by touching two buttons at the same time. All buttons in between will then be turned on. On a single touch system you have to touch them all yourself. At the API level I will see a bitset with some bits on and some bits of. I don't care whether they were set individually or all at the same time. Only if the widget notifies observers of state changes might there be some programming needed, for instance, if the code assumes only a single bit can be turned of or on, I would have to change that (in such a way that the code handles both single bit changes and multiple bit changes in a single state changed event).

AFAICS, existing widgets do not have to be renamed to get them multi-touch enabled. For instance, if I want the default widget that returns a boolean, I don't care if it looks like a slider that's to the left or right, a checkbox that's on or off or a choicelist that's yes or no (this is for those people who remember Series 80). I want the systems standard boolean widget. I don't want to worry at the API level what it looks like, that's the concern of the UI builder.

Only the widgets that make sense only in a multi-touch environment can have a different name, but even then, at some point in the near future multitouch is as common as single touch is today, so having them named differently will be thought of as a bad idea then, so it is a bad idea now.

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

Qt for Nokia is an asset as long as code written for Qt can be deployed on lots of platforms. That is after all why Nokia bought it in the first place. So, with Qt in place, Nokia has a very good value proposition to (commercial) developers, which is the size of the Qt user base. Qt is capable of hiding the differences between Symbian^4 and Maemo 6 for a lot of apps, and that means that Maemo 6 and Symbian ^4 devices can be counted together as a single platform.

But, as soon as there are differences between Maemo 6 and Symbian^4, there won't be a single platform anymore, and the value proposition Nokia is making to (commercial) developers drops hugely in value.

Nokia should know this because they had at some point three different UI's. S60, S80 and S90. And even though S90 and S80 were almost identical, the differences were big enough so that only the most trivial apps did not need porting. S60 and S80 were so different that all UI parts of apps had to be rewritten. A bit later, Nokia killed S80 with the excuse that two UI's were too expensive to maintain.

And here we are, 5 years down the road, and Nokia is making exactly the same mistake again. I believe that "flabbergasted" is a better description of my emotional state than 'anxious" ;)

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.

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

Er... before going deeper into panic mode, would you mind giving some time to the Qt specialists to have a say? I'll ask tomorrow.

Maemo and Symbian have to concentrate in different use cases and different priorities for different form factors. Both are equally interested in keeping a common ground for plain Qt applications.

Remember that the post-trolls are behind and in the middle of the Qt strategy for Nokia. They know a bit about Qt today and tomorrow, in Nokia platforms and beyond.

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? Do you really thing these guys have poor knowledge and no good reasons to do what they are doing?

Another intersting contact is Ville Lavonius, product manager of the Maemo development platform. He also had a presentation in the Maemo Summit about Qt application development on Harmattan.

Actually I decided to start with the Miniature pet project having plain Qt 4.6 as a main requirement precisely to check "in real time" that Nokia's Qt cross-platform promise is real and attractive. So far looks good and we have already binaries for Maemo 5 and Ubuntu compiled from the same source.

I invite you to do the same: come up with plain Qt 4.6 applications running on Maemo 5 or Symbian, try to run them in different platforms (e.g. Harmattan as soon as we have an SDK out) and then complain if you are unhappy about the results.

About the Maemo 6 UI Framework (or the future Symbian UI framework based on Qt for that matter) do just do the same: have a look, see if they provide something interesting for you, try to extend your plain Qt 4.6 apps using them, see how much work that brings and whether it's worth the effort and then we can talk properly.

Still, I'll try to get some feedback from the Harmattan guys tomorrow. Keep discussing, all the better if you are familiar with Qt and have got a look to the Maemo 6 UI framework code before.

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

No, he's Attila the Hun!

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

The most worrying thing in that thread is the one from markw that says:

Having been very disappointed by what Maemo did to the GTK+ toolkit in Maemo 5 (breaking lots of standard widgets and putting the "fixes" into custom widgets), I desperately hope that they do it right for Qt.

Really, it's great if you add some mobile-specific stuff to a Maemo-specific custom widget set, but please, don't break the generic widgets. You shouldn't have to use the Maemo stuff to make your app look OK, although it's fine if you need to use Maemo stuff to make your app look awesome.

qgil's post is reassuring; if their "generic" QT app continues to look "right" in Maemo and Ubuntu, I'll relax completely.

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

One consolation is that Nokia should be able to control the Qt codebase. [SDRF*]Not like when GTK+ 2.12 eradicated Maemo from the face of the Earth[/SDRF]. But don't worry, I only counted a little less than 540 "#ifdef MAEMO_CHANGES" in the 2.14 resurrection.

*Slightly Distorted Reality Field

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

If you want to maximize cross-platform take, use "standard" widgets. Hopefully, those will work fine and in style with overall system. Of course, certain features would be not possible to implement without going beyond standard widgets -- it is exact reason why QGraphicsView was created by Qt people in 2006, used in KDE for Plasma project and by many others.

If you would re-read what I was saying, my observations were on pointing exactly this fact: Qt has for long time been working on ways to innovate in UI beyond standard widgets for those developers who want it. There probably wasn't enough need and energy in every single Qt-based project to use those enablers but case with KDE4's Plasma shows they are still there. Multiple cases on Windows with commercial applications based on Qt or any other non-standard UI toolkit are also contributing to this view, as standard "Desktop" widgets are relatively rare in use in many Windows applications.

Who will provide "Qt standard widgets" on top of QGraphicsView by default as Qt API, whether this will really happen anytime soon (in next several years), will it be in use by someone on cross-platform market, still remains to be seen. However, I do not see any sort of panic mode activated.

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

I am not talking about S60 but about Symbian ^4/Qt. I want source compatibility between Symbian ^4/Qt and Maemo 6/Qt.

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

I am concerned, not panicking ;-) And I certainly would like to hear the Qt specialists on this matter.

Compared to the differences between a desktop PC and a smartphone, the differences between Maemo and Symbian ^4 are minute. Small enough to be abstracted away.

Besides, last monday Nokia announced that their Nseries devices will start using Maemo 6/Qt beginning in 2012. Currently Nseries devices are smartphones, and if they stay with the Nseries brand these devices will still be seen as the same device category, but with greatly enhanced software capabilities.

Is this good or bad? What's a post troll?

I am talking about policy here, not about engineering. Engineering comes after policy, not before. What I am seeing as a commercial developer is that Nokia is publicly stating one policy, which is single source/multiple deployment. In practice however Nokia has a completely different policy which is different sources for different platforms. At the StackOverflow devday in Amsterdam two weeks ago Nokia was giving a presentation about how easy it was with Qt to have a single source (and one #ifdef) and build live binaries for both WinXP and Symbian/Qt.

At the Maemo conference I voiced my concerns about Maemo 6/Qt and Symbian^4/Qt not having the same UI toolkit after I found out that there was going to be a difference. At that time I was still under the impression that the bulk of an app was still plain Qt, but with extra widgets.
But after examining the Maemo 6 examples and looking at the source, I saw that everything was changed. Oops, that's not what Nokia is publicly stating what their policy is.

[QUOTE]
Another intersting contact is Ville Lavonius, product manager of the Maemo development platform. He also had a presentation in the Maemo Summit about Qt application development on Harmattan.

Actually I decided to start with the Miniature pet project having plain Qt 4.6 as a main requirement precisely to check "in real time" that Nokia's Qt cross-platform promise is real and attractive. So far looks good and we have already binaries for Maemo 5 and Ubuntu compiled from the same source.

I invite you to do the same: come up with plain Qt 4.6 applications running on Maemo 5 or Symbian, try to run them in different platforms (e.g. Harmattan as soon as we have an SDK out) and then complain if you are unhappy about the results.
[QUOTE]

Sigh. How much spare time do I have, you think? Besides, seeing that a framework, that is supposed to be abstracting away system differences, and that is know to be capable of this feat, is going to be subclassed for the main application objects is enough to raise all kinds of alarm bells. Been there, seen that. Symbian had at some point four slightly different app frameworks, and Nokia itself has publicly stated that S80 was to be discontinued because it was too expensive for Nokia to maintain two frameworks (S90 was dead already at that time). And what do i see now: Nokia again having multiple frameworks that are (slightly) different. And that was too expensive?

I am sorry, but your priorities are wrong. I am here to be convinced by Nokia that developing for their single Qt platform is a good value proposition for commercial developers. But after coming here I find they have two platforms, three if you count plain Qt as a different platform, which is not what they are telling to developers. I am not going to invest time and money in producing code until that matter is cleared.

Excellent, I'll await their comments.

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

[QUOTE=abbra;381424]If you want to maximize cross-platform take, use "standard" widgets. Hopefully, those will work fine and in style with overall system. Of course, certain features would be not possible to implement without going beyond standard widgets -- it is exact reason why QGraphicsView was created by Qt people in 2006, used in KDE for Plasma project and by many others.
[QUOTE]

First things first.

Qt apps start with constructing a QtApplication, Direct UI apps start with constructing a DuiApplication. Two different classes, it is then reasonable to assume that DuiApplication does something that QtApplication does not, and that something is important for multi-touch devices. Now, what are my changes that a Qt application is going to run good enough on a maemo (and symbian ^4 for that matter)? I don't know, unless I compile my plain Qt app, run and test it, and then port it to Dui, and run and test it again.

yes, for a good test I must be able to compare the differences between the plain Qt and the Direct UI versions of the app. Today's commercial mobile software environment is very competitive and having an app that is not top-notch means that your changes are not good.

I can reduce work and increase my changes by not bothering to do the plain Qt build and test, but go straight to porting. And then, I have two (sleightly) different versions of my app, and my maintainence costs are now twice as big, or were, unless I add in even more work to refactor the common stuff out.

This is all under the assumption that DuiApplication is actually doing useful work, and that work cannot be done in QtApplication.

But for the life of me I have no idea what it is that DuiApplication is doing what cannot be done inside QtApplication. So all I am seeing now is more time to spend on things that do not make money, because somebody thought having a Dui instead of a Qt is cute. No, it is not.

Next class, QtWindow versus DuiWindow, same exercise.


You will find that on mobile devices there is not a big need for lots of screen widgets. Symbian never had many, iPhone doesn't have many either, even less than Symbian. Having a few standard widgets is enough for the bulk of apps. Mobile means simple and intuitive.

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

Interesting post:) I may not have read every post in this thread with care, but here's my opinion.

Nothing prevents you to run "Plain Qt" applications on top of Maemo 6 UI Framework AFAIK. In that case you dont' use DuIApplication and other DuiStuff. Instead you use QApplication and other QWidgets. It will probably work as it works on Hildon Qt. Antonio ported Qt to Hildon environment so that it handles e.g. all the QActions in a toolbar, meaning that you don't see the regular "file", "edit" menus on toolbar. Instead you see them when pressing the view menu on the Hildon toolbar. I hope that they will provide a Maemo specific Qt style which makes regular QWidget based widgets such as buttons to look more like maemo buttons.

All this means that you are forced to use Qt version that is ported on the device, but that's all.

What comes to the Dui side. I guess Nokia wants to provide a certain set of widgets built on top of QGraphicsView so that it would be easier to build an application on the Harmattan based device. So AFAIK nothing prevents you to run plain Qt application on Harmattan device.

I don't know anything about Qt on Symbian, so I have no opinion on that, but according the Qt ideology, code once, use everywhere should work there also. But this conserns only applications that are based Qt API directly, not the API of Maemo 6 UI Framework... I believe.

FYI:
In Qt developer days Qt guys informed that some times in the future the all QWidget based widgets are planned to move on top of QGraphicsView. This is so big change that I guess we need to wait this quite long, but you never know.

NOTE:
These are just my personal opinions, assumptions and hopes:)

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

No, probably no one will force us, like today no one is forcing us to use Hildon in addition to Gtk. The only problem is that pure Gtk applications look like crap on Fremantle. So the question is whether Qt will handle this situation better or not.

I´m currently planning to do a complete rewrite of my code using Qt, so I´m observing this situation closely. I want Qt, because I´m hoping to support more platforms without using #ifdefs everywhere. But if those applications will look like 2nd class applications on Maemo I´m not sure I want this.

</end panic mode> ;)

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

Rumors, Nokia hasn't announced anything.

Just a guess: people who used to work for Trolltech were called Trolls, so "post troll" is probably someone working for Qt Development Frameworks at Nokia (or whatever the official name for Trolltech is nowadays).

Likewise. I'll hope this DuiApplication stuff / source code incompatibility is some sort of mistake. I mean Qt is bringing declarative UI (btw. that's also "DUI") at some point (is it already in 4.6?). Wouldn't that help at least partially to fix this problem (presuming we really have a problem)?

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

The Qt 4.6 port for Maemo 5 is alpha-ish and the applications using it don't like like crap. Actually in most cases there is probably no way to distinguish them from a Hildon app. So the starting point is already better then the plain GTK+ situation.

Something that helps is that the Qt maintainers have Maemo well positioned in their priorities and they are delivering an official Maemo port. This was never the case of GTK+. Unfair and dubious comparison, I know, but let's not forget that it's the Qt team itself who is delivering this Maemo 5 official port.

They are the first ones not willing to see plain Qt apps looking crappy in any platform. And they have a long experience avoiding that.

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

I know that pure Qt applications are now looking good on Fremantle, but we´re talking about Harmattan here. Plain Gtk applications were looking ok-ish on Diablo but awful on Fremantle.

I´m just worried that history will repeat itself and we´ll end up in a situation like the current Hildon/Gtk situation. Once burnt twice shy - as they say... But yea, I´ll try to stop worrying and I´ll continue to learn about Qt. I´ll also watch this thread hoping that some Qt-Wizards shed some light on the issue.

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

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.

So what's with all the DuiApplication etc. stuff? This is something we're adding on top of Qt that we think will take the UI to the next level. Those of you who have been following the developer blogs of Qt will no doubt have seen a lot of exciting new features emerging just this year, such as the animation and state frameworks, multitouch, Qt/3D and of course everything related to GraphicsView. For those not familiar with the concept, the Qt Graphics View framework removes the limitations of traditional Qt or Gtk-like UIs (such as widgets being restricted to small rectangular areas, no real overlapping widgets etc.) and just gives you this great big canvas on which you can arbitrarily draw, animate, scale and rotate items to your hearts content.

So you've already got all these great new capabilities in (or soon to be in) Qt itself. But by themselves these are just the individual building blocks. When you instantiate a GraphicsView it literally looks like a piece of white paper. In order to take that and create a useful application out of it, it's going to take a lot of code. You're going to need widgets, layouts, transitions & animations, probably theming so things look consistent if you're ever going to have more than one application etc. That's what the Maemo 6 UI framework gives you. There's actually very little overlap or duplication with Qt itself (linear graphics-layout comes to mind, ours is implicitly animated), because while Qt for example defines what a widget on the graphics scene is, it doesn't come with any. In the upcoming Qt 4.6 you will see the first usable in-scene widget, QGraphicsWebView, which you will be able to drop into your Maemo 6 framework using application. One day Qt may grow to include everything, although that too would have its downsides, but we are not yet there today.

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

- Modifying Qt. Unlike Gtk+ which we patched quite heavily over time, except for some build configuration infrastructure we don't really add anything to our Qt packaging. If we (Maemo) need some change we will work with Qt together to upstream it, or better yet work together already during the initial feature development.

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

The Qt declarative UI, which like the Maemo 6 UI framework is built to work together with the Qt Graphics View framework, is a tool that can be used in many ways. Taken by itself every single application is still left to reinvent event the simplest of widgets again and again from the primitives. In order to achieve platform consistency, wouldn't it be nice if there was a library with common reusable components available? That could be used together with the declarative UI format? ;)

We're digging the declarative UI in Maemo. In fact, we like it so much we think the visual QML designer that integrates into Qt Creator should be the way to rapidly create your Maemo application UI as well.

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

Thanks Thomas for replying here! I guess then I'll start using plain Qt 4.6 and later (if needed) add some Maemo 6 specific stuff once I've actually seen the benefits it brings.
It's good to know that you want to support normal Qt applications as first class citizens :)

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

Thanks a lot tomasj!

Let me add that Tomas has been in the Maemo team for a loooong tine and he (like others now driving the Maemo 6 UI framework) knows the patched GTK+ phase very well. I'd say they have even a personal interest in not going that way again, now with a Qt toolkit. :)

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

So if I understood correctly the above, in practice an application developer has two choices:

1) use the vanilla Qt. The apps will look just fine on Maemo 6, and should work ok on Maemo 5 too and other platforms. Good cross-platform experience.

2) If you want to make your app as shiny as the Maemo 6 default apps will be, then vanilla Qt is will not get you all the way as the Maemo 6 UI Framework is an extension (superset) of Qt. And by the way all those widgets, layouts, transitions & animations functions in this start with DUI, not Q.

So unless I'm totally misunderstanding something... If just crossplatform is not enough for you, but you want to take the best out of each platform, then you will have to code Maemo 6 specific UI for the Qt app. (and consequently separate UIs for the other platforms).

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

Thank you tomasj!

It would be nice to receive confirmation that the DUI APIs are designed to gracefully degrade on any platform that does not fully-support them. It's important to make cross-platform development as painless as possible, even if the final testing must be done on the fully-supported platform.

Regards,
Roger

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

I still have a misunderstanding. In the past QT was able to create a framework that worked and looked as it should on the host OS
Here we have three entities : QT, Symbian and Maemo, all three under the same umbrella. At this point Symbian and Maemo are developing two different frameworks both on top of QT, each meant to do almost the same thing.
Why doesn't this crystallize in a QT official extension supported on all systems QT compiles on? In this way we would know that using DUI we get the best look on both systems. I mean it should be easy giving in the end they are all under Nokia's umbrella.