PDA

View Full Version : Maemo 6 loosing source compatibility with plain Qt, and Symbian^4


svdwal
2009-11-18, 12:43
[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-framework/framework-technical-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/index.php/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.

dtrouton
2009-11-18, 13:10
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/09/direct-ui-orbit-qt.html

NvyUs
2009-11-18, 13:27
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/reviewing-the-release-plan/

attila77
2009-11-18, 13:37
@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 :)

qgil
2009-11-18, 14:00
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.

jsa
2009-11-18, 14:26
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/showthread.php?t=3363

svdwal
2009-11-18, 15:00
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/09/direct-ui-orbit-qt.html

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.

nowave7
2009-11-18, 15:16
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.

svdwal
2009-11-18, 15:48
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.

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.

svdwal
2009-11-18, 16:08
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/showthread.php?t=3363

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

NvyUs
2009-11-18, 16:20
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" ;)

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

TA-t3
2009-11-18, 16:38
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?

attila77
2009-11-18, 17:14
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

abbra
2009-11-18, 17:39
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/category/labs/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?

gecebekcisi
2009-11-18, 17:57
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.

cristids
2009-11-18, 18:09
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.

daperl
2009-11-18, 18:16
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.

abbra
2009-11-18, 18:28
I would recommend reading Plasma documentation on why traditional widgets are not enough for "contemporary" UI development. http://techbase.kde.org/Projects/Plasma/TheWaysOfThePlasma 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.

Thor
2009-11-18, 19:17
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

Are you Humphrey Appleby (http://en.wikipedia.org/wiki/Sir_Humphrey_Appleby)? ;)

msoini
2009-11-18, 19:42
I would recommend reading Plasma documentation on why traditional widgets are not enough for "contemporary" UI development. http://techbase.kde.org/Projects/Plasma/TheWaysOfThePlasma 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.

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.

qgil
2009-11-18, 20:14
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 (http://wiki.maemo.org/Maemo_Summit_2009/Day_2#Introducing_the_Harmattan_UI_framework), Alex Luddy (http://wiki.maemo.org/Maemo_Summit_2009/Day_2#The_Qt_Mobility_Project), Sergiy Dubovik and Ian Monroe (http://wiki.maemo.org/Maemo_Summit_2009/Day_3#Designing_QT_application_for_Maemo_5_and_Mae mo_6). 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 (http://www.slideshare.net/lavonardo/qt-application-development-on-harmattan).

Actually I decided to start with the Miniature (http://wiki.maemo.org/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 (http://wiki.maemo.org/Miniature#Screenshots) and we have already binaries for Maemo 5 (http://maemo.org/packages/view/miniature/) and Ubuntu (https://launchpad.net/~michael-hasselmann/+archive/miniature) 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.

Texrat
2009-11-18, 20:34
Are you Humphrey Appleby (http://en.wikipedia.org/wiki/Sir_Humphrey_Appleby)? ;)

No, he's Attila the Hun!

qole
2009-11-18, 20:58
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/showthread.php?t=3363

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


Of course you'll be able to run pure Qt apps on both platforms, but if they don't look like native apps because they don't use native widgets that's a big problem for many. There'd be no major problem with separate implementations of the widgets on the two platforms as long as they shared a common set of interfaces (i.e. as long as we have source compatibility - and functional compatibility, not just "it compiles on both"). However, that doesn't appear to be the case from what I've seen so far...


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.

daperl
2009-11-18, 22:01
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.

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

*Slightly Distorted Reality Field

abbra
2009-11-18, 22:17
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.
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.

svdwal
2009-11-19, 08:35
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

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

svdwal
2009-11-19, 09:19
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.


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


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.


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.


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.


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


There were 4 key people (at least) in the Maemo Summit with relevant roles relating to this subject: Tomas Junonen (http://wiki.maemo.org/Maemo_Summit_2009/Day_2#Introducing_the_Harmattan_UI_framework), Alex Luddy (http://wiki.maemo.org/Maemo_Summit_2009/Day_2#The_Qt_Mobility_Project), Sergiy Dubovik and Ian Monroe (http://wiki.maemo.org/Maemo_Summit_2009/Day_3#Designing_QT_application_for_Maemo_5_and_Mae mo_6). 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?


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.


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 (http://www.slideshare.net/lavonardo/qt-application-development-on-harmattan).

Actually I decided to start with the Miniature (http://wiki.maemo.org/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 (http://wiki.maemo.org/Miniature#Screenshots) and we have already binaries for Maemo 5 (http://maemo.org/packages/view/miniature/) and Ubuntu (https://launchpad.net/~michael-hasselmann/+archive/miniature) 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?

[QUOTE]
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.


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.


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.

Excellent, I'll await their comments.

svdwal
2009-11-19, 09:47
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.


[QUOTE]
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.

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.

zchydem
2009-11-19, 11:08
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:)

conny
2009-11-19, 11:36
All this means that you are forced to use Qt version that is ported on the device, but that's all.


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

ColonelKilkenny
2009-11-19, 11:46
Besides, last monday Nokia announced that their Nseries devices will start using Maemo 6/Qt beginning in 2012.
Rumors, Nokia hasn't announced anything.

What's a post troll?
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).


Excellent, I'll await their comments.

Likewise. I'll hope this DuiApplication stuff / source code incompatibility is some sort of mistake. I mean Qt is bringing declarative UI (http://labs.trolltech.com/blogs/2009/05/13/qt-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)?

qgil
2009-11-19, 11:48
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.

conny
2009-11-19, 11:59
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.

tomasj
2009-11-19, 13:12
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.

tomasj
2009-11-19, 13:37
I mean Qt is bringing declarative UI (http://labs.trolltech.com/blogs/2009/05/13/qt-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)?

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.

conny
2009-11-19, 14:27
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 :)

qgil
2009-11-19, 15:52
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. :)

msoini
2009-11-19, 16:24
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.


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

eiffel
2009-11-19, 16:44
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

cristids
2009-11-19, 17:22
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.

daperl
2009-11-19, 18:24
- 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
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
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
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.

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

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
(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
There were 4 key people (at least) in the Maemo Summit with relevant roles relating to this subject: Tomas Junonen (http://wiki.maemo.org/Maemo_Summit_2009/Day_2#Introducing_the_Harmattan_UI_framework), Alex Luddy (http://wiki.maemo.org/Maemo_Summit_2009/Day_2#The_Qt_Mobility_Project), Sergiy Dubovik and Ian Monroe (http://wiki.maemo.org/Maemo_Summit_2009/Day_3#Designing_QT_application_for_Maemo_5_and_Mae mo_6). 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
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
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
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
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
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
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
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
sorry I didn't get your question. QML supposes to help you running same apps under different 'skin'.

puelocesar
2009-12-01, 15:17
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
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.

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

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:

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
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
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
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
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
Well the infection seems to be spreading. I think Qt lost it . In this article http://labs.trolltech.com/blogs/2009/12/01/qt-for-maemo-5-next-iteration/ they are saying new classes got in the QT special for maemo.


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
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
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
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
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
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
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
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
Sure :). Is that qt-maemo-feedback@trolltech.com?

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
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
@w00t

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

ColonelKilkenny
2009-12-03, 14:09
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
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
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
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...

... that still leaves Dui* existing in a rather odd not-in-mainline-not-in-any-other-platform-than-maemo type void ...

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:

daperl
2009-12-03, 18:25
they may actually have a reason for doing all this :eek:

Excuse for not knowing who is who, because I don't want that to blur the topic, but I'm sure they have a reason. As far as I can tell, someone in the know posted some of those reasons and also gave us a link further explaining those reasons, and that's when some of us responded with, "We don't like your reasons."

w00t
2009-12-03, 23:50
Just a slight update, so everyone knows what's going on: I got a little sidetracked (understatement of the century...) by the arrival of my N900 today.

I've still started on the summary, and will send it tomorrow morning, lunchtime at the latest.

I'll link you all to the archive thread so those not subscribed can follow there, but I'd strongly suggest that anyone interested subscribe also, as it could prove an interesting discussion.

w00t
2009-12-03, 23:54
Assuming that DUI *is* Symbian as well (I've seen no mention of this, but granted, I don't follow Symbian development closely), then this still leaves other platforms out in the cold, meaning it's not a part of the regular Qt API, meaning I can't write once, run anywhere - and can't develop and test with my regular PC with Qt Creator which is what I'm used to doing.

Even assuming DUI becomes mainstream, then, there becomes the point of asking why it exists *in the first place* instead of these additions being added back to the regular Qt API, because when you look at DUI, pretty much all of it is just subclassing and adding a small amount of stuff, much the same way Hildon wrapped GTK and did its own stuff.

So, it's still an issue to me, and I personally am hoping I can find out more out of it starting tomorrow.

Thanks for your feedback, ColonelKilkenny. :)

w00t
2009-12-04, 16:49
Right - I come bearing news

I wrote up a summary of what I gathered to be the points here (portability, fragmentation, etc), and sent it on to qt-maemo-feedback.

I've just received the first reply, linked for your interest here:
http://lists.trolltech.com/pipermail/qt-maemo-feedback/2009-December/000045.html

Summary of points:
- I need to ask elsewhere about Dui (which I will do)
- QMaemo5* classes *are not* intended to be too pervasive, but only where things cannot be covered by more generic concepts.
- QMaemo5KineticScroller will stay, but it will not be needed unless fine-tuning of scroll behaviour is required

Are there any other areas of direct concern with QMaemo5 I can bring up?

qgil
2009-12-05, 09:05
I'm glad to see you got a fast and clear technical answer directly from one of the developers of the Qt 4.6 port for Maemo.

Now about the dui libraries, before you ask in maemo-developers make sure you have already gone through http://www.slideshare.net/peterschneider/maemo-6-ui-framework and the posts of Tomas Junnonen in this own thread.

Texrat
2009-12-05, 18:28
Let's say the division gets to the point where it's not so fragmented but simply between desktop/laptop platforms vs highly mobile platforms (of any kind). Would that scenario be so bad?

Note that I am solely speculating here; no advance info of any kind in my head. :D

w00t
2009-12-05, 18:30
Now about the dui libraries, before you ask in maemo-developers make sure you have already gone through http://www.slideshare.net/peterschneider/maemo-6-ui-framework and the posts of Tomas Junnonen in this own thread.

Thanks for your help, and for the reference, Quim. I am indeed doing some more research first, and I will be sure to keep Tomas' post(s) in mind when I write things up. :)

w00t
2009-12-05, 18:32
Let's say the division gets to the point where it's not so fragmaneted but simply between desktop/laptop platforms vs highly mobile platforms (of any kind). Would that scenario be so bad?

Note that I am solely speculating here; no advance info of any kind in my head. :D

If it can't be used on full form factor devices at all, I'd consider that a bit of a problem, yes - because that's where most people tend to develop and test, before finally deploying onto a device.

My main concern, really, is splintering for the sake of splintering. But like I said, I want to do some more reading first.

Thanks for your reply!

Texrat
2009-12-05, 18:36
If it can't be used on full form factor devices at all, I'd consider that a bit of a problem, yes - because that's where most people tend to develop and test, before finally deploying onto a device.

Not what I meant, sorry. What if specialized UI libraries were for all highly mobile devices and just not available on desktop/laptop platforms, likely due to screen size and mode-of-use issues. Is that as harmful? Is it tolerable?

Again, sheer speculation for sake of my understanding.

EDIT: ah, maybe I misunderstood your response. Ok, I see the issue now...

cristids
2009-12-07, 12:18
I don't think windows mobile will have DUI support.

dragan
2009-12-13, 18:44
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.

Absolutely, QML + JS and webkit are they key here. There should be a way to package such an app (with all the artwork and what not) and deploy the same way on Symbian, Maemo and all desktops Qt supports (I get that not all of them will have identical input methods but the code should run). The upside of running these on Nokia devices should be that it all comes heavily HW accelerated (and battery efficient) on the back end.

Mark Wilcox
2009-12-14, 14:56
Hi,

I'll start by saying I work for the Symbian Foundation but these are my own opinions, not those of my employer. I'll also add that I'm a big Maemo fan too - I've had an N800 for ages, and my N900 is sat at the local DHL office ready to be delivered tomorrow. :-)

The criticism on this thread is spot on. Mameo DUI and Symbian DUI are not the same thing (as I understand it, the Symbian side of things accidentally stole the term from Maemo).

I've investigated this myself (and I used to be a software architect at Nokia, so you might consider I have some idea what I'm talking about) and I've also talked to people whose opinions I respect in the Qt, Symbian and Maemo organisations. We all agree - this Direct UI madness is a big mistake Nokia is making and it's going to come back to bite them.

To quote Tomas Junnonen from earlier in this thread:
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. <snip> ... One day Qt may grow to include everything, although that too would have its downsides, but we are not yet there today.

This analysis is spot on. The UI paradigm is changing - people building UIs with standard QWidgets will find them looking "old" on these rebuilt Symbian^4 and Maemo 6 products. The new UI paradigm needs some new widgets built for the GraphicsView framework. However, the very LAST THING developers need is two completely separate implementations of essentially they same thing with different APIs - one for Symbian and one for Maemo. The idea that pure Qt apps will be OK on both is pretty pointless if you have to build your own set of widgets that's portable between the two.

The very concept that Maemo and Symbian (via Orbit - currently being renamed Symbian^4 UI framework) should build new UI frameworks on top of Qt, which is supposed to be a cross-platform application and UI framework should have set alarm bells off everywhere! When you consider that Qt is owned by Nokia, along with Maemo and almost all of the Symbian development teams - it seems almost inexcusable that there should be any framework built on top of Qt. However, given that there could be a desire to preseve the quality of Qt by not expanding the team working on it too fast or diluting the quality of the engineers, and at the same time a business need to build some products on top of the technology, you might be able to excuse a common set of widgets etc on top of Qt for mobile devices. Unfortunately two separate sets is just insane and WRONG, WRONG, WRONG!

Of course there and plenty of smart people in Nokia and this was not the original plan. The thing called Orbit was meant to be cross-platform. I heard from a fairly senior guy who sat on strategy meetings that the teams involved were basically looking for reasons to diverge and build separate frameworks from day 1 - as soon as the strategy was laid out.

Why? Well there were two teams building UI frameworks before Qt was acquired and a lot of people that would like to justify their jobs! Also, building a new UI framework on GraphicsView is interesting and challenging work which the engineers in both camps would love to do. Could they not have worked together on a single one? Apparently not.

Quim Gil, who I generally have a lot of respect for, seems to be in defensive mode here:
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. <snip> ... 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.
This is just wrong. It shows total priority on building products rather than building a platform for developers. As I've said, pure Qt is not enough any more, not when the platforms build their apps with different widget sets. This problem was solved by Qt for the various desktop platforms right down to phones and coffee machines - the same solution could work again. Different styles for different platforms and in some cases platform specific private implementations of classes.

There is absolutely no reason why you can't build completely different looking apps and platforms with the same application and UI framework.

I realise that Nokia employees can't agree with me publicly and criticise the actions of their colleagues and the company they're working for. However, people with the influence of Quim Gil need to recognise the mistake that is being made and work to fix it before it's too late, or at least minimize the damage if it is indeed past the point of no return.

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.
I've done this, plain Qt apps can and do work across platforms. The future frameworks for Maemo and Symbian do offer something of interest to almost every developer - access to special platform input methods and the core widgets that the platform applications are built with. Don't you think 3rd party app developers will want the advantages of the GraphicsView framework for the same reasons the platform application developers do?

Waiting until these things have shipped will be too late. The Symbian one is not yet available for anyone outside Nokia to compare with what Maemo are building. By the time they do and all start ranting at once, it'll be too late for you to do anything about it and another own goal for Nokia.

Developers will want to build different UIs for different form factors in the future, and Qt's technologies, particularly QML should make that feasible in terms of time and effort. However, make the fragmentation optional or at least only reflecting real physical differences like screen size and input capabilities - don't create it artificially along political boundaries within Nokia's organisation.

Qt - cross-platform applicaitons for all Nokia devices.
QGraphicsView - excellent technology for creating next generation UIs.

Great strategy, botched implementation - PLEASE do everything you can to fix it.

Mark

qgil
2009-12-15, 17:07
Hi Mark, nice post with good technical insight.

Now, you know that software is developed by people with goals. In theory you can look at a toolkit and conclude that it will take this time for this amount of people to come up with a release. In practice this doesn't work like this.

Remember how was life around Qt only 2 years ago. Trolltech was a company in Norway. Symbian was a closed core OS developed by a company in the UK. There was S60 developed in a closed environment by several companies. Maemo was a GTK+ based platform pushed by a small team living basically out of the Nokia mainstream software strategy.

Now, at which point and at a which cost would you have been able to create the single team developing the toolkit to make everybody happy? Qt, Symbian and Maemo have different stakeholders with some overlaps. They have slightly different ways of working. The three organizations are going through huge transformations and in the meantime they have roadmaps, releases and products going out to the market. And yet they still have own goals, even if they complement each other and are sometimes common.

And yet they are converging their interests and releases around Qt, taking care of their own goals and stakeholder while adding on top instead of forking or reinventing. The three organizations are committed to open source development and early pre-releases, and this is why you have the elements to start this discussion in the first place. This public exposure and this long road to stable releases will fine tune a lot of what can be improved together.

I still believe this discussion will be more useful when we have concrete SDKs and platform releases to compare. The day someone comes pointing to duplicated, pointless or missing features then we will be able to have a proper technical discussion.

In the meantime we must play this game where you are the apocalyptics and we are the integrated, when actually the picture is more interesting than that.

Note that this multiparty exercise (that includes you) has a chance of big success precisely because the setting is more wide and diverse. This is one of the reasons why I think I'm working in the right platform and in the right direction, even if the story is not always as simple to explain as I'd wish.

attila77
2009-12-15, 17:44
I still believe this discussion will be more useful when we have concrete SDKs and platform releases to compare. The day someone comes pointing to duplicated, pointless or missing features then we will be able to have a proper technical discussion.

The fear is that at the point we have SDKs and platform releases, the ship has already sailed, and IF there is an 'oops' we will be discussing damage control at best (case in point: the /opt story) and maybe suggesting things for Maemo 7/Qt 4.7+. From what I've seen so far about the Maemo 6 UI Framework, it's a bit scary, exactly because it's burning bridges to the rest of the Qt ecosystem. Once you're in Dui-land, there is no going back to 'plain' Qt, in effect, creating a sub-framework. I (think I :) ) understand the challenges of adapting a general application framework to a mobile use-case, but the prospect of having so many layers and layers of complexity makes it look a bit scary. In facti, it makes the original 'Code Less. Create More. Deploy Everywhere' motto sound like a slightly hollow promise or at least subject to more and more interpretation.

sjaensch
2009-12-15, 17:56
The day someone comes pointing to duplicated, pointless or missing features then we will be able to have a proper technical discussion.

As someone else posted earlier in this thread: Isn't it too late then? Just look at libqt4-maemo5. A lot of things done there are Fremantle-only so Qt4.6-powered apps can be released for the N900 in a timely manner. Harmatten is supposed to be the release where stuff is done right. I as a developer have accepted the fact that Fremantle is this transition release, mostly based on GTK/Hildon and landscape view with portrait mode and first-class Qt support coming as additions later. Harmatten is the first real Qt-based release that better be enabling hassle-free cross-platform development (at least including Harmatten and S60).

So the API has to be gotten right for Harmatten. No developer wants a third, yet again incompatible API for Harmatten+1. If we wait for SDKs to come out, it will be to late to change such fundamental things (at least for Harmatten). History proves this: the Fremantle SDK still ships with an ancient Python and a broken (!) gdb. Even the Maemo5 Qt team inside Nokia can't get the SDK team to ship an updated gdb that will work with Qt apps.

The Symbian and Maemo teams have announced their plans for the future. If what Mark Wilcox writes is correct, we will have similar but incompatible APIs for Symbian and Harmatten. Now, why would I need a SDK to be able to talk about that? So I can check for myself that my Harmatten app just produces compile errors on S60? Obviously we need to talk about this right now and influence the proper people so that no SDK is ever released publicly with those incompatible APIs. In the alternative, a simple statement by a Nokia representative :) that of course API compatibility is a top priority and is being worked on as we speak will go a long way. Or am I missing something?

Mark Wilcox
2009-12-15, 18:17
Hi,

Thanks for the lengthy response. I don't see this situation as apocalyptic and I'm really glad that both platforms are in open source so we can start doing something about this rather than Nokia dumping a couple of largely incompatible SDKs on us shortly before products ship.

Now, you know that software is developed by people with goals. In theory you can look at a toolkit and conclude that it will take this time for this amount of people to come up with a release. In practice this doesn't work like this.
Yes, I know very well how it works (or doesn't in some cases) having been involved with platforms for most of the major OEMs at some point.

Remember how was life around Qt only 2 years ago. Trolltech was a company in Norway. Symbian was a closed core OS developed by a company in the UK. There was S60 developed in a closed environment by several companies. Maemo was a GTK+ based platform pushed by a small team living basically out of the Nokia mainstream software strategy.
Yes, I know this history very well too, having been in and around Nokia and Symbian, using Maemo regularly, a Forum Nokia Champion and writing a book that included a lot about Qt and the need to follow the Qt tech previews very closely for that. (BTW, my book is about porting to Symbian and a lot of it about porting from Linux-based platforms, so this is a subject very close to my heart. Qt was the holy grail and Nokia have shown it to us and then pulled it just out of reach again.)

Now, at which point and at a which cost would you have been able to create the single team developing the toolkit to make everybody happy? Qt, Symbian and Maemo have different stakeholders with some overlaps. They have slightly different ways of working. The three organizations are going through huge transformations and in the meantime they have roadmaps, releases and products going out to the market. And yet they still have own goals, even if they complement each other and are sometimes common.
Nokia has been through a hugely challenging time, but they've spent about 9 of the last 18 months re-organising internally - it can only be concluded that politics has trumped technical strategy and pragmatism in this process (actually I've seen lots of evidence of that elsewhere in the organisation too - ask about PlatSim vs QEMU internally on the Symbian side for example...). I'm not saying a single team to create the framework was required, just a cross-platform co-operation to define a common API set (doesn't have to be 100% common, just a common core). There would still have been a need for two implementations of this API and some agreements on who does which core bits that are pure Qt code. This suggests that despite significant improvements, Nokia hasn't yet integrated the Qt way into its DNA - it's still a company that puts products first and developer platform second. (Although the Symbian side of the organisation is much more guilty of this than Maemo I have to say!)

Yes, there were many market pressures and some people were probably in a panic but still I find that sad. However, it's crying over spilt milk now. I don't really care why we got here (except that Nokia should take this back for its lessons learned).

What are we going to do about it?

Yes, we can all get more fully involved in the conversation when some alpha SDKs are available. But the information we have already is enough to throw up red flags. I hope that you also take this back internally and get people to review things.

However, there are specific things in this thread that I wouldn't want to see dismissed. For example QApplication works across so many platforms, and you can build and test code on any one of them. Why then must I build a DuiApplication? I'm not going to be at all surprised if the Symbian^4 UI framework does something similar. If there is platform specific initialisation to be done, why can't it be pushed into the private implementation of QApplication for each platform? Just because KDE does it too doesn't make it right. ;-)

Oh, and don't worry, I'm only complaining at Maemo first because they've released their code first. I'll be giving the Symbian guys even more of a hard time when I get the chance.

qgil
2009-12-15, 20:45
By SDK I also mean an environment where you can see that code in action, both providing the UI under discussion and the API to play with.

Discussion around source code only is possible but it requires similar levels of knowledge and abstraction to keep a fruitful discussion. Like now. Some people see the N900, see the N97 and conclude that there are no strong reasons to have different Maemo and Symbian optimizations on top of Qt. I bet things will be clearer when the first pre-releases come.

Having SDKs out also allow people to see how plain Qt apps integrate in both platforms with the same source code, somethng that currently you have no other choice than imagining it yourselves.

Remember the intense No Cancel Button discussion? Big deal, and yet nowadays everybody agrees it was a good decision. Ths is what I mean when I say that some discussions need something tangible to base the debate. We are discussing UI code here without having seen any actual UI.

What would be interesting feedback now would be features, widgets etc that you are missing in Qt 4.6. Specially interesting if they happen to be expected by, say, iPhone or Android developers.

conny
2009-12-15, 21:01
For some time already I wanted to join this discussion in a productive manner. But as this is quite a complex subject I was unsure where to start. So I start with a couple of observations and questions.

I don't have Qt experience yet, but I used Gtk+ and Hildon on Diablo and Fremantle a lot. I've also used Hildon a lot during the Beta phase of Fremantle (starting from the first version with UI support).

From what I learned with the Fremantle Beta SDK, I feel save to say, that once a SDK with UI support is released it's definitively too late to change anything substantial.
Unfortunately I'm quite sure it's already too late for Harmattan even without a SDK release.

So we will have Dui* widgets and we will have Q* widgets. That's not too bad yet. The question is, how deep/thick is this UI layer?

I mean we have to redesign the UIs anyways between different platforms. So to me the main question is: How much of the backend code needs to be changed? And if I'm talking about backend, I don't mean stuff like a database or a sort algorithm. I'm talking about the UI backend like callbacks/slots.

Is there some compatibility between Dui* and Q* widgets? For example, does QPushButton and DuiButton both implement a common Button interface?

I mean, I don't really care whether a Button is implemented using the QGraphicsView or not. To me it's still a button.
I can set a label, an image, etc. and whenever it's clicked it will send out a "clicked" signal.

If now the DuiButton and the QPushButton send the same "clicked" signal. My UI backend is happy because I don't have to change it.
But if the QPushButton sends a "qClicked" signal and the DuiButton sends a "DuiClicked" signal, then we have a problem because those "small UI" changes will ripple through our complete applications.

And of course it's not only signals, it's parameters send with the signals and methods called on the widgets.

Unfortunately I'm quite sure I already know the answer. The "pressed" signal which I find in duibutton.h has probably nothing to do with the "pressed" found in QAbstractButton. At least I cannot find any signs about that looking at the code.
And that is bad. Really.

Before I had a closer look at the code and this thread I was imagine it would work approximately like this:

As a developer I'm writing my code on one platform (e.g. Maemo). A very thin UI layer is separated into one file. Or one file per window. Those files are code or XML. Handwritten or created by a designer tool. But those files really only contain what the user is seeing. So only stuff that could be made by a graphical UI designer tool.

Then I implement the rest of the application. When I'm done. I fire up the Symbian UI editor and create a UI for Symbian. And that's basically it.

In the background there would be factories which create DuiWidgets or QWidgets but to me they just look like Widgets. Now if I need to invoke the Widget::setSuperTransparentAnimation() method which is only available in DuiWidgets. Then I would just cast my Widget to DuiWidget and invoke that method.

This way I could selectively use Maemo or Symbian specific code whenever I need it. And only when I need it.


I hope I was not too confusing ;) I'm tired and if I talked BS, I'm sorry. Anyways, I think this is the single most important thread at the moment. And we should give the people on the devel-mailing list a hint that it exists.

Well, in the end it looks like Conboy will use Gtk/Hildon still a bit longer....

conny
2009-12-15, 21:08
Discussion around source code only is possible but it requires similar levels of knowledge and abstraction to keep a fruitful discussion. Like now. Some people see the N900, see the N97 and conclude that there are no strong reasons to have different Maemo and Symbian optimizations on top of Qt. I bet things will be clearer when the first pre-releases come.

I think most people see that there is the need for a different UI on different devices. But the differentiation should be on the visual level. Not on the API level.
Of course there also might be the need for different APIs, but that does not mean that you should have two _completely independent_ APIs with two completely different inheritance trees.

Jaffa
2009-12-15, 23:04
I think most people see that there is the need for a different UI on different devices. But the differentiation should be on the visual level. Not on the API level.

And this was the mistake that was made back in 2005 with Hildon. I'm sure it was the "right" decision given the constraints and expectations at the time, but duplicating an API (GtkButton/HildonButton) to prevent back-end forking and maintenance of an internal version of Gtk+ meant much more work (in the form of retraining) for developers; and I'm not convinced much less work for Nokia.

Maybe C/Gtk+ wasn't the right technology to do a proper OO API; but Qt supposedly is. Indeed, the earlier Qt porting efforts did exactly this.

I don't care - in fact, I expect - to have to change the layout and content of my app for different platforms. I DO NOT WANT to have to learn 3 different APIs to put a button on screen depending on whether I'm targetting a desktop, Symbian or Maemo app.

Of course there also might be the need for different APIs, but that does not mean that you should have two _completely independent_ APIs with two completely different inheritance trees.

+1

qgil
2009-12-16, 11:19
You can use plain Qt QGraphicsWidgets and QGraphicsItems in DUI containers.

http://doc.trolltech.com/4.6/graphicsview.html

Mark Wilcox
2009-12-16, 11:28
A quote I picked up on twitter the other day which I really liked and seems very appropriate here:

The biggest cause of failure in software-intensive systems is not technical failure; it's building the wrong thing -Mary Poppendieck

I was going to point out, again, that it's perfectly possible for two very different looking platforms, even with different interaction models to have a common core API. The reason being because you're not innovating so radically in UX that we no longer have basic concepts like lists and buttons - even if Harmattan does make a giant leap forward. However, it seems plenty of others are on the same page and have beaten me to it.

Considering Hildon's first incarnation as yet another UI framework for Symbian (Series 90) that no-one wanted to write apps specifically for, you'd have thought Nokia might have learned this lesson by now.

Having SDKs out also allow people to see how plain Qt apps integrate in both platforms with the same source code, somethng that currently you have no other choice than imagining it yourselves.
I know that the Qt folks are going to do everything they can to make things look good. However, if you're using fundamentally different building blocks the end result isn't going to be satisfactory - yes that's a prediction but it's one I'm fairly confident about.

We are discussing UI code here without having seen any actual UI.
No, this is an important distinction, we are discussing UI framework APIs here, nothing to do with how the things will actually look and everything to do with how much effort is involved in targetting multiple platforms.

What would be interesting feedback now would be features, widgets etc that you are missing in Qt 4.6. Specially interesting if they happen to be expected by, say, iPhone or Android developers.
We have one example here clearly spelled out in this thread. Qt 4.6 is missing any standard QGraphicsWidgets. If we want to build animated UIs we need some. If we want to build cross-platform animated UIs we need a common interface to them across platforms.

Developers can of course build their own QGraphicsWidget set in pure Qt. It's a lot of work. However, if their apps want to integrate well into Maemo and Symbian then they may well want to integrate with the theme engine - which is presumably separate again on each platform (I'd love someone to come and tell me otherwise, since we are surely in the realms of pure Qt here). Suddenly it's becoming a massive amount of work.

Being able to use custom QGraphicsItems and QGraphicsWidgets in the Maemo containers doesn't help at all (well you could possibly port Symbian ones to Maemo or vice versa - but that's not going to give the platform look and feel).

Of course it's all built with Qt, so it does mean you can have a lot more code reuse than you got historically, but we're still a very long way short of the cross-platform promise.

Mark

zchydem
2009-12-16, 12:42
For those who are worried about compatibility of the QWidget based widgets in Dui, you might be interested in about the itemview-ng project in Qt Software.

Their goals is to make all the Q*Widgets to run natively on QGraphicsView. I guess this would solve most of the problems discussed here related on code compatibility. I don't want comment anything about having to different platforms here because I couldn't care less about symbian stuff:)

See Thiago's comment on Qt labs discussion:

": to have all of the widgets available “natively” in Graphics View, to have them accessible from QML and to have native styling.

As for CSS, we’re probably just going to ditch that in favour of QML."

They will also introduce similiar kind of MVC model than DUI does. You can checkout the source code from git and check the examples.

More information:
http://labs.trolltech.com/blogs/2009/12/10/we-have-liftoff/
http://qt.gitorious.org/qt-labs/itemviews-ng

For me this sounds quite good. What do you think? I'm not sure if this "feature" will be available for Maemo 6...

Addition:One thing came to my mind that there will be two different MVC mechanism when both Dui and Qt releases their systems. Instead of having two almost identical systems, could they put effort to develop only one, but make it really good?

Mark Wilcox
2009-12-16, 13:58
Hi zchydem,

Addition:One thing came to my mind that there will be two different MVC mechanism when both Dui and Qt releases their systems. Instead of having two almost identical systems, could they put effort to develop only one, but make it really good?
This is the pretty much the same argument I'm making about the duplication with the Symbian framework. :)

because I couldn't care less about symbian stuff
You may not care about Symbian and that's fine, but every Maemo fan should care about UI framework compatibility for Maemo and Symbian because it'll mean more apps that run on Maemo (OK so a lot of them probably won't be open source, and you may still not care). ;)

For me this sounds quite good. What do you think? I'm not sure if this "feature" will be available for Maemo 6...
Yes, the next generation widget set from Qt is a great thing! Possibly the solution to the current mess is that the community gets behind the Qt widget effort and there's proper platform styling for Maemo & Symbian - then everyone writes pure Qt and we can all ignore Dui and Orbit. Maybe, just maybe - this is exactly the troll plan. They should have this ready by the time the devices ship and they obsolete the stuff the product platforms have done as far as 3rd party developers are concerned.

Mark

hhartz
2010-01-04, 08:41
I'd like to point out (as many probably already are aware of) that Qt code will be source compatible as long as its running on a supported platform.

dubik
2010-01-07, 18:00
Yes, the next generation widget set from Qt is a great thing! Possibly the solution to the current mess is that the community gets behind the Qt widget effort and there's proper platform styling for Maemo & Symbian - then everyone writes pure Qt and we can all ignore Dui and Orbit. Maybe, just maybe - this is exactly the troll plan. They should have this ready by the time the devices ship and they obsolete the stuff the product platforms have done as far as 3rd party developers are concerned.


I wouldn't put my money on itemview-ng. It's a great research project but not much more. Not to mention that it will take years until it become part of QT. I would suggest to all angry people download Harmattan UI Framework, review code, suggest new apis and ideas and help us make it a mainstream framework (for instance many comments from zchydum are already in master). There is a lot of things to do for everyone. However I agree it's fun to blame developers which secure their jobs for fragmenting frameworks. Haha. There are only 2 guys in libdui who still work since the beginning of project.

Mark Wilcox
2010-01-08, 10:14
Hi dubik,

Thanks very much for coming to get involved in the conversation.

I wouldn't put my money on itemview-ng. It's a great research project but not much more. Not to mention that it will take years until it become part of QT.
Really? Years? It seems stuff in Qt-labs typically gets to the mainline a version or two later - maybe Qt 4.8?

I would suggest to all angry people download Harmattan UI Framework, review code, suggest new apis and ideas and help us make it a mainstream framework (for instance many comments from zchydum are already in master). There is a lot of things to do for everyone.
Excellent! As soon as the Symbian folks have released their UI framework code I'll start comparing and contrasting and seeing where we can get the quickest wins.

However I agree it's fun to blame developers which secure their jobs for fragmenting frameworks. Haha. There are only 2 guys in libdui who still work since the beginning of project.
It's never developers that make the decisions at this level - typically someone somewhere in the upper reaches of middle management who hasn't touched code for 5+ years. There's also a big difference between what people fear will happen in a re-org and what actually happens afterwards. :)

What about one of the comments on this thread, is DuiApplication really needed, or can things be pushed back into the private implementation of QApplication? I realise the libdui guys can't do that on their own, but in theory?

lpotter
2010-01-08, 19:16
please...

Having two differing widgets/application based on the same codebase is only a minor inconvenience, easily handled with #ifdefs and differing ui forms, if even needed. Heck, you can even load the ui forms at runtime, offering the ability to change the gui without recompiling. Not to mention Qt Kinetic.
The same differences have existed between Qt, Qtopia, and KDE for a decade, and I have personally been there, and done that for the last decade (think Sharp Zaurus 5000D). It's not that difficult, really.

I don't think it's a big of a deal as you make it out to be. I wrote an app - Gutenbrowser, that can be run on Qtopia, Qt desktop, Qt embedded, KDE, or whatever. (Although the Qtopia code has been abandoned for obvious reasons). It wouldn't be all that difficult to bring back the QtopiaApplication, if the need arises.

Don't make mountains out of mole hills.

OrangeBox
2010-01-08, 19:25
Here we go again. Nokia never learns from its past mistakes.

konttori
2010-01-08, 19:31
I really like the direction that the itemview-ng project is heading for. And definitely qml is the greatest addition to Qt stack since webkit. Qml finally allows separation of UI and business logic in a way that makes sense (which is that there is also scripting for the UI so that almost all user interaction can reside in the script portion of the application). With qml and especially the itemview ng, there is true portability of at least the UI level.

konttori
2010-01-08, 21:13
Oh, and as someone commented on the broken gdb, we are finally updating that (yay!) to 7.0.

attila77
2010-01-08, 23:20
Having two differing widgets/application based on the same codebase is only a minor inconvenience, easily handled with #ifdefs and differing ui forms, if even needed. Heck, you can even load the ui forms at runtime, offering the ability to change the gui without recompiling. Not to mention Qt Kinetic.


My problem with that was that more complex Qt projects tended to have 'smart' dialogs and forms, many of the actual signals, actions, etc defined in the forms. Which is cool and makes it easier to see what's going on, except if you want to swap in another UI (say, because you were porting an UI to WinCE), it turns into a hellish tar pit. So you had a choice of throwing out the sophistication of QDesigner and do coding UIs head-to-code, like Real Men, 1999 style, or battle the bugs of never-quite-in-sync .UI-s. And peppering code with #ifdefs by design in a multiplatform framework is also a bit of a drag in 2010. For me, thus, the question is not how difficult it is, but rather if it is really necessary or not (we could just as well have a QMacApplication and a QWinApplication, but we don't and that's not because it's hard to put an #ifdef around it). Just my 2 cents :)

dubik
2010-01-09, 10:07
Really? Years? It seems stuff in Qt-labs typically gets to the mainline a version or two later - maybe Qt 4.8?


Well, how much time did it take to get animation framework into 4.6? Which is fairly simple. I took a look at activity of itemview-ng and there were only few commits during last several months. Trolls are genius but there are not so many of them. May be not years but year - easily. Phone programs can't wait :)


It's never developers that make the decisions at this level - typically someone somewhere in the upper reaches of middle management who hasn't touched code for 5+ years. There's also a big difference between what people fear will happen in a re-org and what actually happens afterwards. :)


Yeah, I know. But your first post gave an impression that arrogant developers didn't want to cooperate. Which is not true. Lets close this, noone in libdui team (even ex members who are now working in other maemo teams) feared or is fearing to loose his job.


What about one of the comments on this thread, is DuiApplication really needed, or can things be pushed back into the private implementation of QApplication? I realise the libdui guys can't do that on their own, but in theory?

I don't understand whats the big deal of replacing QApplication with DuiApplication? First, we are trying to avoid mixing Q* and Dui*. Second and it's more important, we need to initialize quite a few services: application prestarting, service framework and so on. I doubt QT guys would like to see that code in QApplicationPrivate :)

Qt will take some parts from libdui but it's not going to happened before 4.7 as far as I know (or at least make alternative implementation).

Mark Wilcox
2010-01-11, 09:33
May be not years but year - easily. Phone programs can't wait
Yes, but 1 year from now Symbian^4 devices will only just be shipping, I'm assuming Maemo 6 is intending to be out slightly ahead of that. So it doesn't really matter what version of Qt the firmware has to be built with and what you build on top of it as long as developers can get a real cross-platform solution in time for devices hitting the market and the Qt version is easily upgradeable (i.e. automatic if an app has a dependency on a later version).

Yeah, I know. But your first post gave an impression that arrogant developers didn't want to cooperate. Which is not true. Lets close this, noone in libdui team (even ex members who are now working in other maemo teams) feared or is fearing to loose his job.
It was not my intention to suggest that any of the engineering teams were arrogant - that has never been my experience of Nokia staff and I apologise if I caused offence. Of course the Maemo organisation is growing pretty fast, so no engineers there should have been concerned for their jobs. I was deliberately trying to avoid pointing fingers directly and anyone so I'm happy to leave the speculation on reasons for the mess there.

I don't understand whats the big deal of replacing QApplication with DuiApplication? First, we are trying to avoid mixing Q* and Dui*.
It breaks source compatibility. I can no longer build and test my UI against standard Linux (or Windows or Mac) Qt for a faster compile-debug-edit cycle. Ideally I want to be able to build a large subset of possible applications that look native without going near anything platform-specific. If I have to use platform-specific stuff then it should be a couple of lines with a #ifdef or something I can easily encapsulate using the private implementation pattern.

I've ported Qt apps between platforms and added platform-specific stuff - even for the rather different strand that was Qtopia, the changes are still very minor. This Dui stuff is in a different ballpark in terms of effort as far as I can see, contrary to what Lorn Potter is suggesting further up the thread. Qt Mobility is obviously going to take some time to get really good functionality coverage as they have to write separate backends for each platform, but if UI code can't be cross-platform from day 1, what can?

Second and it's more important, we need to initialize quite a few services: application prestarting, service framework and so on. I doubt QT guys would like to see that code in QApplicationPrivate

Well, if these things really need to be initialized separately for every Maemo application then there should be a Maemo-specific implementation of QApplicationPrivate - surely that's exactly what the private implementation pattern is for?

Let my try to make it clear how much of a disconnect there is between the strategy (at least as I understood it) and the implementation. At the presentation on the selection and acquisition of Qt (and reasons for) at the Nokia Developer Summit in Monaco last year, it stated that Nokia realised they were building 4 or 5 versions of each of their applications and this was incredibly wasteful - what's more, 3rd party developers would have the same problem. They immediately ditched Series 80 and 90 and then started working on a replacement cross-platform framework plan for the remaining platforms so they could build applications and services once that worked across the entire portfolio. They bought Qt and everyone was happy. :)

It's really important that Symbian and Maemo be compatible. Symbian has a real shortage of decent free apps and Maemo has almost no decent commercial apps. If most apps are trivially portable between the two then both will get a significant benefit. If not, many commercial developers won't bother with a Maemo port initially because of the low volumes and we aren't likely to see many ports of free software to Symbian either (because as we've seen in this thread, most free software guys don't care about Symbian). I thought this was very clearly understood. Indeed just in December Peter Schneider was speaking at the same developer event as me in Sweden and said that Maemo is depending on Symbian's volumes to get the commercial app developers in the first couple of years.

However, if you need to do a complete UI re-write - is that really going to happen. It certainly didn't on Symbian for S60 vs UIQ in most cases.

Now maybe the plan is still as I thought it was and all of this is just interim measures while Qt evolves to cover the new UI paradigm and mobility stuff? If that was genuinely seen as a business necessity then what thought has gone into what 3rd party developers should do? Forum Nokia is telling everyone to start working with pure Qt now? Is that going to produce the results anyone wants?

dubik
2010-01-11, 13:16
It breaks source compatibility. I can no longer build and test my UI against standard Linux (or Windows or Mac) Qt for a faster compile-debug-edit cycle. Ideally I want to be able to build a large subset of possible applications that look native without going near anything platform-specific. If I have to use platform-specific stuff then it should be a couple of lines with a #ifdef or something I can easily encapsulate using the private implementation pattern.


You are confusing me. When you say DuiApplication do you actually mean all widgets and classes which directui provides? So you want to create QPushButton, QLabel and have interface like iPhone or android has with all animations, layouts, orientation changes and so on? hm. We have no idea how to do that.

I develop libdui on Mac, rest of people use Ubuntu, we have it running on Windows, to me it looks like it runs on many platforms. You are asking for sources compatibility between Orbit and DirectUI but at the same time you ask sources compatibility even with plain QT!

Btw, there are no widgets based of QGraphicsWidget in QT. So, shell we still discuss source compatibility with plain QT?


I've ported Qt apps between platforms and added platform-specific stuff - even for the rather different strand that was Qtopia, the changes are still very minor. This Dui stuff is in a different ballpark in terms of effort as far as I can see, contrary to what Lorn Potter is suggesting further up the thread. Qt Mobility is obviously going to take some time to get really good functionality coverage as they have to write separate backends for each platform, but if UI code can't be cross-platform from day 1, what can?


In desktop world all your platform have monitor, mouse and keyboard. There is even a standard for keyboard layout. In mobile world it's total mess. Sometimes you have keyboard, sometimes don't, some have multitouch, some don't. Screen sizes and resolutions are so different. I just don't see how someone can create a UI framework which will be suited for different looking products. In Symbian you have soft keys. Thats the only platform which has softkeys (may be S40 another one actually). I doubt maemo also want to have softkeys in their applications. At least n900 happily survives without those. There are millions of such details. Can you immidiately recognize Symbian device? I bet you can. Doesn't matter what theme is installed, what collors or applications. You just notice that immediately. That will happen to common UI framework. Maemo device will look like Symbian. Whats the point of having maemo then? bash?


Well, if these things really need to be initialized separately for every Maemo application then there should be a Maemo-specific implementation of QApplicationPrivate - surely that's exactly what the private implementation pattern is for?


Not really. Private implementation pattern is just to keep implementation really private and provide ABI. But ofcourse you can build hierarchy of _really_ private classes around it. One for maemo, one for desktop. I just don't see how it can work, not technically but in practice. What if we need additional parameter, like service name which we introduced into DuiApplication?


It's really important that Symbian and Maemo be compatible. Symbian has a real shortage of decent free apps and Maemo has almost no decent commercial apps. If most apps are trivially portable between the two then both will get a significant benefit. If not, many commercial developers won't bother with a Maemo port initially because of the low volumes and we aren't likely to see many ports of free software to Symbian either (because as we've seen in this thread, most free software guys don't care about Symbian). I thought this was very clearly understood. Indeed just in December Peter Schneider was speaking at the same developer event as me in Sweden and said that Maemo is depending on Symbian's volumes to get the commercial app developers in the first couple of years.


I said it many times and will repeat again. It's not important what kind of frameworks device or platform has. If there are millions devices and something like ovistore which gives 70% revenue to developers there will be all kind of apps. Android and iphone proves it. Even palm proves it. Can you port open source twitter client to palm? I bet you can't even run it on device. (and you actually can run almost any open source app on n900, gtk, qt, tcl and so on). And still they have apps which are coming to store. And thats because of money not because of great WebOS.



Forum Nokia is telling everyone to start working with pure Qt now? Is that going to produce the results anyone wants?

You will be able to run native qt on harmattan without any changes to sources. I said that on maemo summit in amsterdam. And we are working hard to get it as native as possible to maemo 6 ui. So if you want to hack few things, you may just recompile your QT app. Otherwise you have to port. I also heard that maemo 5 supports native qt nicely as well.

Mark Wilcox
2010-01-11, 16:09
Wow, that says it all. We're coming at this from very different perspectives.

Personally I see this as an extremely dangerous attitude coming from a very flawed analysis of the mobile app development space:
I said it many times and will repeat again. It's not important what kind of frameworks device or platform has. If there are millions devices and something like ovistore which gives 70% revenue to developers there will be all kind of apps. Android and iphone proves it. Even palm proves it. Can you port open source twitter client to palm? I bet you can't even run it on device. (and you actually can run almost any open source app on n900, gtk, qt, tcl and so on). And still they have apps which are coming to store. And thats because of money not because of great WebOS.
Native Symbian code has around 300 million devices total, at least half of those are running recent versions of S60 and are out there in the market now. How many people want to develop apps for them and what's the level of activity there now? Android is a total counter-proof to your claim. Hardly any devices at all sold relative to other platforms and yet the second most apps of anything but the iPhone. Palm is the only thing with fewer sales and it actually has very few apps compared to the other US platforms, largely because it only has a web-scripting environment (well actually they just added native plug-ins) - which is what had early iPhone developers screaming for a proper native SDK.

What really worries me there is that someone working on the UI framework actually believes the frameworks don't matter - the app developers will come anyway! Or am I reading that wrong?

You are confusing me. When you say DuiApplication do you actually mean all widgets and classes which directui provides? So you want to create QPushButton, QLabel and have interface like iPhone or android has with all animations, layouts, orientation changes and so on? hm. We have no idea how to do that.

What I'm looking for here is not changing APIs significantly without a very good reason. So I'm not talking about the whole thing, just QApplication vs DuiApplication. I'm not expecting you to make a next generation UI without using the graphics view architecture and animation framework.

Not really. Private implementation pattern is just to keep implementation really private and provide ABI. But ofcourse you can build hierarchy of _really_ private classes around it. One for maemo, one for desktop. I just don't see how it can work, not technically but in practice. What if we need additional parameter, like service name which we introduced into DuiApplication?
Two possibilities spring to mind immediately, one is that you could pass something in using the standard command line arguments... people did that for decades with main() without needing to modify the entry point. The other is that you could get another parameter added to QApplication - it seems there's an S60-specific one already:
http://qt.nokia.com/doc/4.6/qapplication.html#QApplication-6

I develop libdui on Mac, rest of people use Ubuntu, we have it running on Windows, to me it looks like it runs on many platforms. You are asking for sources compatibility between Orbit and DirectUI but at the same time you ask sources compatibility even with plain QT!
Does libdui have no dependencies other than Qt - it's actually running natively on those platforms, not in some Maemo emultor? If so, it's better than I feared, although still not as good as I hoped. If libdui is actually cross-platform then there may be some hope of fixing things quite quickly. I know the Symbian^4 UI framework is mostly definitely not - for example I checked up on the theme server, it's implemented as a native Symbian server, so it's not going to run anywhere else.

In desktop world all your platform have monitor, mouse and keyboard. There is even a standard for keyboard layout. In mobile world it's total mess. Sometimes you have keyboard, sometimes don't, some have multitouch, some don't. Screen sizes and resolutions are so different. I just don't see how someone can create a UI framework which will be suited for different looking products.
Desktops can also have touchscreens with multi-touch now, and they might not have a physical keyboard - we have tablet PCs. Screen sizes and resolutions also vary massively too. I agree that the challenges are greater in mobile, but they aren't as different as you suggest. Qt has been working across all PCs and several other very different looking types of device for many years. They have always tried to minimize API fragmentation. I'm sure they plan for that to continue with the animated UI paradigm. I can accept an argument that says it couldn't be done quickly enough, but not one that says it can't be done.

In Symbian you have soft keys. Thats the only platform which has softkeys (may be S40 another one actually). I doubt maemo also want to have softkeys in their applications. At least n900 happily survives without those. There are millions of such details.
If there are millions of such details please can you at least provide a valid example? Not all Symbian devices have physical soft keys - the rigidity of the Avkon UI framework is what makes it easy to recognise and also what produces a lot of the weakness of the 5th Edition touch UI. It's not a good thing!

Will the future Symbian UI framework always have softkey labels next to where the physical soft keys would be if there were any? I certainly hope not!

That will happen to common UI framework. Maemo device will look like Symbian. Whats the point of having maemo then? bash?
No! Does a Qt application running on Mac OS X look like a Qt application running on KDE? There are two completely separate things here - one is look and feel, which should be encapsulated in a style guide and the look and behaviour of widgets. The other is the API you use to program the UI. If you get the level of abstraction right the two are fairly loosely coupled. The framework should not enforce the style guide rigidly (as Avkon does).

I'm not completely unrealistic (at least I didn't think I was) - I don't expect there to be 100% source compatibility for everything you can do with the UI. For example soft keys, if available, can have an extra API that you only use if you want to set softkey labels to something other than the default values, much as exists in the current Qt port to S60.

What's the point of having Maemo and Symbian? For a company the size of Nokia, not putting all your eggs in one basket seems like part of the reason. Another is that they have different strengths and weaknesses for addressing different market segments. Maemo is easier to port to high-end hardware and much easier to create a product that's closer to a netbook or laptop type of computing experience. Symbian is better for building a smartphone - it does the phone bit very well, including the ability to run the signalling stack on the same chip, which is not so easy in Linux. That's part of what lets Symbian reach much further down the price band than Maemo.

However, what was made clear in the Nokia Capital Markets day is that the market segments for Maemo and Symbian do have some substantial overlap too (at least if you can read anything into the pretty graphs).

I really don't see the UI as a good place for the two platforms to make radical departures from one another, since Maemo will surely want people upgrading from a Symbian device to make up a lot of its future user base? However, in this area I have to admit to pure speculation, since we're all still in the dark about future devices out here! :)

Even though we're coming at this problem from very different places, I hope we can find some common ground and work together to make porting between platforms as simple as possible for 3rd party developers. I get the impression from the interest this thread has generated that I'm not the only one who thinks this is very important. I'll not say anything more on the subject until I've got some Symbian code for comparison, then I'll start a new thread with some analysis.

dubik
2010-01-11, 17:15
Personally I see this as an extremely dangerous attitude coming from a very flawed analysis of the mobile app development space:

What really worries me there is that someone working on the UI framework actually believes the frameworks don't matter - the app developers will come anyway! Or am I reading that wrong?


Are you a yellow newspaper journalist or what? You are following weird logic. I'm talking about app stores and what's important for a
platform to be succesful (from the amount of applications point of view) and you are making conclusion that I (as a person) think that framework doesn't matter. Not to mention your dramatic remarks: "really worries", "extremely dangerous attitude".


Native Symbian code has around 300 million devices total, at least half of those are running recent versions of S60 and are out there in the market now. How many people want to develop apps for them and what's the level of activity there now? Android is a total counter-proof to your claim. Hardly any devices at all sold relative to other platforms and yet the second most apps of anything but the iPhone. Palm is the only thing with fewer sales and it actually has very few apps compared to the other US platforms, largely because it only has a web-scripting environment (well actually they just added native plug-ins) - which is what had early iPhone developers screaming for a proper native SDK.


I'm not following you. What's your point? Symbian doesn't have many applications because it's framework is bad or because it doesn't have app store (where profit is split 70 by 30)?


What I'm looking for here is not changing APIs significantly without a very good reason. So I'm not talking about the whole thing, just QApplication vs DuiApplication. I'm not expecting you to make a next generation UI without using the graphics view architecture and animation framework.

Two possibilities spring to mind immediately, one is that you could pass something in using the standard command line arguments... people did that for decades with main() without needing to modify the entry point. The other is that you could get another parameter added to QApplication - it seems there's an S60-specific one already:
http://qt.nokia.com/doc/4.6/qapplication.html#QApplication-6


So, how your QT application will look like then if you would want to port it to Symbian?

original app:
QApplication app(argc, argv);

for symbian you need that factory i guess (lets assume you need it). How are you going to include that as a first parameter without change code significantly?

are you going to write something like this?
#ifdef _S60
QApplication app(pointerToFactory, argc, argv);
#else
QApplication app(argc, argv);
#endif

If you need that factory for S60, I see no reason why you can't change QApplication to DuiApplication for maemo. It's just 3 letters.


Does libdui have no dependencies other than Qt - it's actually running natively on those platforms, not in some Maemo emultor? If so, it's better than I feared, although still not as good as I hoped. If libdui is actually cross-platform then there may be some hope of fixing

It runs natively.



Desktops can also have touchscreens with multi-touch now, and they might not have a physical keyboard - we have tablet PCs. Screen sizes and resolutions also vary massively too. I agree that the challenges are greater in mobile, but they aren't as different as you suggest. Qt has been working across all PCs and several other very different looking types of device for many years. They have always tried to minimize API fragmentation. I'm sure they plan for that to continue with the animated UI paradigm. I can accept an argument that says it couldn't be done quickly enough, but not one that says it can't be done.


Yeah, I also saw tablets with win7. It's ridiculous. Old UIs are not suitable for finger oriented interfaces. It's just proves my point. Btw, almost all vendors create their own UI shells for those device to browse pictures and so on. Do you know why?


If there are millions of such details please can you at least provide a valid example? Not all Symbian devices have physical soft keys - the rigidity of the Avkon UI framework is what makes it easy to recognise and also what produces a lot of the weakness of the 5th Edition touch UI. It's not a good thing!


Well, they all have physical soft keys, just sometimes it's part of screen. Another example is missing hardware "home" key in n900. When there is no such a key _all_ application should have "home" button. I wonder how you would do that with Avkon.


No! Does a Qt application running on Mac OS X look like a Qt application running on KDE? There are two completely separate things here - one is look and feel, which should be encapsulated in a style guide and the look and behaviour of widgets. The other is the API you use to program the UI. If you get the level of abstraction right the two are fairly loosely coupled. The framework should not enforce the style guide rigidly (as Avkon does).


Actually yes. They do look the same. I see label here, scroll bar there. It's all the same, except that they are drawn differently. If you look at mobile frameworks, they all enforce certain style guide. For instance framework enforces where menu of application will appear.


I'm not completely unrealistic (at least I didn't think I was) - I don't expect there to be 100% source compatibility for everything you can do with the UI. For example soft keys, if available, can have an extra API that you only use if you want to set softkey labels to something other than the default values, much as exists in the current Qt port to S60.


This approach even worse. Sometimes things just don't exist, like soft keys but sometimes they don't match partially and then you get a mess. Because you need several copies of "almost" same things.

arlehyn
2010-01-12, 08:51
please...

Having two differing widgets/application based on the same codebase is only a minor inconvenience, easily handled with #ifdefs and differing ui forms, if even needed.

I just want to point out, that unless you're running a professionally managed software project with developers and testers and test devices for all branches of that #ifdef tree (hopefully just two, but...), code inside #ifdefs is a big problem. If you need to change it, you often have to change all branches. But if you can't conveniently test it, can't possibly even check if it compiles without installing a new full cross-platform SDK, how confidently can you make the change? Or do you just add #error on the #ifdef branch you didn't touch, so the next person compiling for the other branch is force to fix that branch too?

For open source application development, that kind of #ifdefs are bad bad bad. They all should be hidden inside framework code, so the application developer community doesn't need to care. Isn't that the whole point of the framework?

Seriously, no to requiring #ifdefs for cross-platform operation! I mean, with enough #ifdefs, every code can be cross-platform...

Mark Wilcox
2010-01-12, 12:15
OK, I lost two goes at replying to this to a dodgy network connection on the train last night, so this might be a bit shorter than it should have been.

I said I would say nothing more until we had something to discuss, but since you ask some direct questions...

Are you a yellow newspaper journalist or what? ... Not to mention your dramatic remarks: "really worries", "extremely dangerous attitude".
No, I'm not a journalist trying to stir up trouble. I really want Nokia to continue to stay on top in the smartphone race. I see them as infinitely preferable to alternatives like control freak Apple or Google's ad-filled, privacy-free distopia. I just happen to believe that Nokia have a great strategy to do that which isn't working out as it should. I find that extremely frustrating and disappointing - hence the emotive language.

What's your point? Symbian doesn't have many applications because it's framework is bad
Yes, exactly that. At least it doesn't have as many applications as it should considering the device volumes compared to the competition. To clarify, in case I get misrepresented in some industry blog again, Avkon is not well suited to touch UI devices and Symbian C++ and the Avkon APIs are too complex to learn and use for most developers. This makes it both less economically viable and less fun to do - so people are less likely to do it. The Ovi store has improved things, but nowhere near as much as would be expected if the two factors you suggest were the only important ones.

for symbian you need that factory i guess (lets assume you need it).
No, I think it's a special case. Most apps can just use the standard QApplication constructor.

It runs natively.
Fantastic! That's a good start.

Yeah, I also saw tablets with win7. It's ridiculous. Old UIs are not suitable for finger oriented interfaces. It's just proves my point. Btw, almost all vendors create their own UI shells for those device to browse pictures and so on. Do you know why?
Yes, standard win 7 on tablets is bad - I agree. I bet the trolls could create a QTabletPCStyle that produced good looking apps from standard Qt code though. To get them looking really great you might need to change the layout, but otherwise the code wouldn't need to change.

Well, they all have physical soft keys, just sometimes it's part of screen.
If it's part of the screen it's not a "physical" soft key. That's the point, they're there in 5th Edition because the framework is too inflexible to allow the apps to do anything else easily.

Another example is missing hardware "home" key in n900. When there is no such a key _all_ application should have "home" button. I wonder how you would do that with Avkon.
I'm not sure I get your point here - Avkon has an "end" key that takes you "home", and a "menu" key that takes you to the main menu. Whatever your framework, it needs to intercept some commands before they get to the app - whether they be from physical keys, virtual keys drawn by the framework, or gestures (touch or other sensor, e.g. accelerometer). Every framework does this but it's not typically visible in the API, is it?

Actually yes. They do look the same. I see label here, scroll bar there. It's all the same, except that they are drawn differently. If you look at mobile frameworks, they all enforce certain style guide. For instance framework enforces where menu of application will appear.
OK, I picked two examples that were too close together for you. What about Qt on desktop systems and the current Qt port to Symbian/S60. On Symbian, the standard code to create your menu for a desktop puts it on the options softkey by default (no extra softkey API needed for that). As long as the UI framework APIs have the right level of abstraction, they can be the same across very different looking platforms.

This approach even worse. Sometimes things just don't exist, like soft keys but sometimes they don't match partially and then you get a mess. Because you need several copies of "almost" same things.
In my experience this is a sure sign that your API is at the wrong level of abstraction and it's time for some re-factoring.

I don't think we're really getting anywhere here though. The requirement I'm looking to fill is cross-platform development of the new paradigm animated UIs, with Symbian & Maemo as a minimum level of supported platforms. My assumption is that at a minimum we need a common set of QGraphicsWidgets for that. I'll test that assumption as soon as I can, then we can talk details.

lpotter
2010-01-12, 19:43
I just want to point out, that unless you're running a professionally managed software project with developers and testers and test devices for all branches of that #ifdef tree (hopefully just two, but...), code inside #ifdefs is a big problem.

I managed to do this fine by myself just fine for many years.


If you need to change it, you often have to change all branches. But if you can't conveniently test it, can't possibly even check if it compiles without installing a new full cross-platform SDK, how confidently can you make the change?


well of course you'll need the other development systems. You don't need cross platform sdk's, even cvs lets you share code across systems.


Or do you just add #error on the #ifdef branch you didn't touch, so the next person compiling for the other branch is force to fix that branch too?

For open source application development, that kind of #ifdefs are bad bad bad. They all should be hidden inside framework code, so the application developer community doesn't need to care. Isn't that the whole point of the framework?

sure.. but what do you think #ifdefs are for anyway?


Seriously, no to requiring #ifdefs for cross-platform operation! I mean, with enough #ifdefs, every code can be cross-platform...

ok, so what's your real problem then.. with #ifdefs?

I have given you a solution to your problem, and a way that this is not really a problem and you have tried everything to look the other way.

sjaensch
2010-01-12, 20:03
ok, so what's your real problem then.. with #ifdefs?

They are, by and large, evil. That's why Stroustrup discourages the use of macros in particular and the preprocessor in general. That's why practically all newer languages got rid of the preprocessor (while copying many other concepts and syntactic stuff from C/C++).

I'm sure you can find plenty of literature on the subject if you are really interested. The points made by Mark Wilcox are valid. Just because people manage to cope with #ifdefs does not mean they are the best (or a good) solution for the problem. One of the greatest achievements of Qt was and is that it got rid of a hell of a lot of #ifdefs, increasing productivity (and testability) along the way.

arlehyn
2010-01-13, 11:36
I managed to do this fine by myself just fine for many years.

Did you do actual programming with #ifdefs for multi-platform UI in single source? Don't you think it would have been much more fun and much more productive without #ifdefs?


well of course you'll need the other development systems. You don't need cross platform sdk's, even cvs lets you share code across systems.

So of course if you're developing software for Maemo version (because your customer wants that, or because you have Maemo device), you'll just do that and forget for example Symbian compatibility. And vice versa.

So you'll end up with a lot of software that could run on all platforms, but runs only on one, not because of required device features but because of simple source compatibility.

And isn't that precisely the concern this whole thread is about?


sure.. but what do you think #ifdefs are for anyway?

They are essentially a hack of C, meant for overcoming shortcomings of the language and the development framework.

If at framework design phase it's decided that application programmer should use #ifdefs for cross-platform development, that's simply bad design. Look at regular Qt for example. No #ifdefs needed for stuff that Qt does. That's an example of good design right there, look it up.


ok, so what's your real problem then.. with #ifdefs?

Biggest fundamental problem: When used in certain way, they are same as copy-paste coding. First you generate first version, then put it inside #ifdef, copy it inside #else and modify it in places.

If you don't know or believe what's wrong with that kind of coding, I can give a lecture on the subject... But that really is "programming 101" stuff, which I hope everybody reading this forum knows.

Now #ifdefs have their place of course but GUI design isn't one of them.

I have given you a solution to your problem, and a way that this is not really a problem and you have tried everything to look the other way.
I'm not quite sure what solution you have given to this problem:

Somebody has developed an application for Symbian+Qt, let's say a simple drawing program to entertain small kids. It does nothing Symbian-specific. Now I want to compile for Maemo+Qt or even Tablet PC+Qt. What was your suggested solution?

My impression is that it does not just compile and sort-of-work.

How much do I need to change to make it compile and sort-of-work, before staring to actually tweak it to work well? Every widget name? Even signals and slots?

Ie. how much work do I need to do before I can even start to adapt it to a new platform?

dubik
2010-01-13, 20:15
Somebody has developed an application for Symbian+Qt, let's say a simple drawing program to entertain small kids. It does nothing Symbian-specific. Now I want to compile for Maemo+Qt or even Tablet PC+Qt. What was your suggested solution?

Would it help if maemo would be based on gtk and clutter and you wouldn't have even possibility to run qt apps on it? :D

attila77
2010-01-13, 23:04
Guys. With enough #ifdefs you can make your app run both on Qt and GTK. But that's not the point. Take a look at what the trolls say about Qt portability on it's own page:

Target multiple operating systems with one source code base
Deploy code from one device target to another by reusing code
Reassign development resources regardless of platform
Future-proof code against platform changes
Allow developers to focus on building core value of software instead of maintaining API

and, a little further down...

Qt is a comprehensive application and UI framework for developing Maemo applications that can also be deployed across major device and desktop operating systems without rewriting the source code.

* Design innovative user experience
* Develop compact, high-performance applications
* Deploy your Qt for Maemo applications to Symbian, Windows Mobile, Windows CE and embedded Linux devices

This sounds very good (and how it should be!) and IMHO is one of the main reasons Qt is as successful today as it is, but the Orbit-Dui-Qt-proper story in the thread above casts quite a shadow on the promises above, at least regarding the Maemo-Symbian-WinMo-Embedded segment :(

EDIT: bold the crux of the matter

arlehyn
2010-01-14, 07:45
Would it help if maemo would be based on gtk and clutter and you wouldn't have even possibility to run qt apps on it? :D

But isn't that precisely the concern of this thread: birth of an environment, where you can't (compile and) run certain Qt apps on Maemo or Symbian or PC, not because they aren't suitable for the device interface, but because they have been coded using a non-cross-platform version of Qt?

I don't think Nokia is in a position to do that any more. They can try, but I don't think it'll work, there's too much competition (Android especially). It'll just hurt both device sales and software base of both Symbian and Maemo. Bad move business-wise. Consumers care about "millions of downloadable apps" kind of stuff, it's a big selling point, and this kind of move seriously hurts making that happen, both for Maemo and for Symbian. It'll turn directly into lost market share.

dubik
2010-01-14, 13:15
But isn't that precisely the concern of this thread: birth of an environment, where you can't (compile and) run certain Qt apps on Maemo or Symbian or PC, not because they aren't suitable for the device interface, but because they have been coded using a non-cross-platform version of Qt?


I said it many times. You can run Qt apps on Maemo and Symbian. Noone is going to remove that. Don't want to write platform specific app with DirectUI, use QWidgets and you will be fine :)

attila77
2010-01-14, 14:14
I said it many times. You can run Qt apps on Maemo and Symbian. Noone is going to remove that. Don't want to write platform specific app with DirectUI, use QWidgets and you will be fine :)

That was never the question :) It's the other way around (as Dui bases on Qt). I'll try to formulate the question as clearly and down to the point as possible:

Can Dui-based applications written for Maemo be deployed to Symbian, WinMo/CE without rewrites and ported to Desktop platforms with minimum effort ?


EDIT: Desktop editions were never claimed to do Dui, modified the question accordingly.

dubik
2010-01-14, 14:31
That was never the question :) It's the

People constantly mix QT applications, dui, orbit in one sentense.


Can Dui-based applications written for Maemo be deployed to Symbian, WinMo/CE without rewrites and ported to Desktop platforms with minimum effort ?


Sure. Libdui, is open source, multiplatform UI framework. It depends on QT. Certain parts depend on D-Bus, Socket, ICU, GStreamer. But it's possible to strip it during compilation of library. Compile libdui for symbian and you will not need to change a single line of code of your app :)

qgil
2010-01-14, 15:53
Something to be taken into account in this discussion is who is potentially affected by these layers on top of Qt. I mean, following the thread it looks as if all the developers were pushed to choose between plain Qt or DUI/Orbit.

If we put this in perspective, we have

- Web Runtime (cross-platform Maemo/Symbian probably with iPhone etc at an affordable extra cost).
- OpenGL ES apps lightly wrapped and also quite cross-platfom including again iPhone and others.
- QML, cross-platform wherever you have Qt. What is your opinion about this one?
- Should we add here "plain QGraphicsView"?, also cross-platform wherever there is Qt?
- The aforementioned plain Qt.
- At least in Maemo there will also be a noticeable % of "Other community supported", GTK+, SDL et al.

Now take all the developers that in one year time will be targetting Maemo. Start by Web Runtime and continue the list, leaving in each item the developers that will be happy with that technology.

What % do you think that will be left for the DUI/Orbit arena and what kind of profiles and applications do you expect from them?

NOTE: I don't have a crystal ball either but knowing your opinions will probably help understanding this debate and putting it in some context.

gusch5
2010-01-15, 04:12
What % do you think that will be left for the DUI/Orbit arena and what kind of profiles and applications do you expect from them?

Something like 80-90% ?
Every app that likes to be a "first class citizen".

I'm a Qt desktop developer/user. I'd like to start hacking with Qt on mobile app(s) (but only first class citizen!). But I won't start, as long as I totally confused.
Which technology should I use in the future?
Will plain Qt be sufficient? Is QML the future? QGraphicsView? ItemViewsNG? Do I have to use Maemo/DUI and Symbian/Orbit separately?

As stated before. I'm confused. And as long as I don't know where Nokia is heading, I won't likely start hacking.

arlehyn
2010-01-15, 07:43
I said it many times. You can run Qt apps on Maemo and Symbian. Noone is going to remove that. Don't want to write platform specific app with DirectUI, use QWidgets and you will be fine :)
So what's the purpose of Orbit and DUI then? Ie. what functionality they provide, that will not be available to cross-platform applications? Ie. why would a programmer want to use them in the first place? Ie. will cross-platform apps be seriously crippled in some ways?

Will it be possible to mix plain Qt and Orbit/DUI? What I mean, can Orbit/DUI widgets be insde Qt widgets, or vice versa?

What I'm after is this: Let's say there's some functionality where there exists both Orbit and DUI widget, but no plain Qt widget. So programmer would want to use plain QT for everything else, but us this functionality with something like #ifdef#else#endif around the device specific widget initialization. Is this easily possible, or will it require a lot of wrapper code, or will it be completely unsupported?

dubik
2010-01-15, 08:26
So what's the purpose of Orbit and DUI then? Ie. what functionality they provide, that will not be available to cross-platform applications? Ie. why would a programmer want to use them in the first place? Ie. will cross-platform apps be seriously crippled in some ways?


Orbit and Dui are UI Frameworks which provide ways to write finger oriented, highly animated applications. Basically something similar to what iphone, android or palm pre provides. QWidget is not designed for that. They also provide quite a few other things like virtual keyboard, localization, application lifecycle, service framework, notification framework and so on. Perhaps I phrased it wrong in my message. Dui apps are not maemo specific, they are Dui specific. You can take Dui library to your platform (where qt is supported) compile and create nice looking applications. Developers would want to use them because of current trend in application development. People don't buy crappy looking apps. They want eye candy. Eye candy is something which is not easy to achieve with QWidget. Looks like QML is coming to rescue but with QML DirectUI can and will work quite nicely, so they will be nice additions to each other and not really competing.
Btw, DUI is going to be heavily optimized for OpenGLES 2 devices. Not sure i can say the same about QWidget apps.


Will it be possible to mix plain Qt and Orbit/DUI? What I mean, can Orbit/DUI widgets be insde Qt widgets, or vice versa?


Dui/Orbit QGraphicsView based applications. You can mix QT into those framework if you can inject QWidget into QGraphicsView. Actually you can do that with proxy widget but it will be pretty slow. Check recent Gunnar's post on QT blogs.


What I'm after is this: Let's say there's some functionality where there exists both Orbit and DUI widget, but no plain Qt widget. So programmer would want to use plain QT for everything else, but us this functionality with something like #ifdef#else#endif around the device specific widget initialization. Is this easily possible, or will it require a lot of wrapper code, or will it be completely unsupported?

Noone tried to include Orbit and DUI widgets in same app. I don't see reasons why they can't coexists. They both based on QGraphicsWidget. How much #ifdef will be required depends how you structure your app, so hard to say. Lets see what is Orbit in details, what layouts and widget it has, what api it uses and so on.

qgil
2010-01-15, 14:10
Something like 80-90% ?
Every app that likes to be a "first class citizen".

I think you are overlooking the Web Runtime here, which is just as first class citizen.

How many Javascript-friendly developers you find for each developer ready to go through Qt+DUI/Orbit? How many simple mobile apps you will find for every complex app requiring the native API? If the Symbian/Maemo cross-platform story is attractive then the Symbian/Maemo/iPhone/Android/Palm/Blackberry/Bada "fairly compatible" story is even more interesting.

Qt / QML / QGraphicsView might be more than enough for a segment of native developers. We can discuss this more in details when we see plain Qt running in a Harmattan SDK.

The loud voices in this thread are coming from you innovative developers, willing to squeeze the cutting edge. Are you representative for the majority of developers now and by the time Maemo 6 is released? Well, I doubt so.

I expect DUI to play an important role in Maemo 6, setting high standards for the UI Framework and providing the promised iconic user experience. Our native applications will sport it and we will invite the most demanding developers to use it. But the Web Runtime and Qt will be just as important.

Then time will tell, and more work will be done based on concrete interests and needs. How much and how fast will Qt integrate from DUI/Orbit in future releases? How much interest will DUI raise in platforms other than Maemo? What real stories will there be about cross-platform development?

We don't know the answers but we know that things move fast.

gecebekcisi
2010-01-16, 05:08
It's sad (at least, for me) to see the resistance* in this thread to really understand what is needed is definitely NOT case-specific not-much-flexible workarounds to save the day, BUT universal flexible** solutions to save the future. I hope to see a final product of a wide vision, instead of a narrow mind.

* I'm not pointing any fingers directly to anyone, I just speak generally.
** As far as possible, for sure. Please see my comprehension (http://talk.maemo.org/showthread.php?p=381039) before replying.

Rugoz
2010-01-16, 08:53
So why Orbit and DUI and not only one widget set for symbian
and maemo? Whats their fundamental difference (did i miss something here :-))?
So in the future all widgets that Orbit and DUI have in common will be integrated into Qt?

Thanks and Cheers

noam
2010-01-17, 00:40
Almost all of Qt apps in the world extend the basic framework to include their own widget sets and APIs. Even on desktop, some of the more serious commercial application use Qt as the core commonality but not to write a single app that magically works across platforms: they want the platform differences but also relatively cheap porting and a common set of tools.

This maybe is less than perfect, but I believe that that's reality and it's going to remain reality for a good reason.

When you try to limit mobile application developers to what a cross-platform framework can do without some platform-specific extensions, you end up with something more like J2ME or very basic HTML. Generalizing UI needs in a cross-platform way takes time, more time than Nokia and other companies have if they want to innovate in a way that reacts to market needs.

To be more precise, we COULD have a 100% common API that would allow for the awesome new touch UIs and would work great on Maemo and Symbian devices, but it would probably be ready a couple of years from now - when we already want the newer thing.

What is probably more practical is letting Maemo/Symbian innovate on their time frames, and later take the common parts into the core framework. Qt has done this with KDE for years.

Qt is an excellent cross platform TOOLKIT, and if seen as such, it makes perfect sense (at least to me). It's the core for building great DUI apps for Maemo, great Orbit apps for Symbian, and later QML apps (some of which will be fully portable, some will include DUI/Orbit specific components).

There's always a difference between what a purely cross-platform app can do (whether it's QWidget / QGraphicsView / QML / WRT) and what an app with a specific platform in mind can do. Show me a solution that solves that problem - Android tried but I don't think they've proven success (see posts about subtle fragmentation between Android phones - J2ME deja-vu).

With Qt you can port the pure cross-platform apps for free, and the platform-specific apps for cheap (as QGraphicsView is still the core for both Dui and Orbit). It is my belief that that's the role Qt should have!

Texrat
2010-01-17, 01:20
I hate to interject with the voice of a noob, but...

As an old developer I understand some elements of this debate, mostly at a high level, but I am struggling with many details.

Has someone diagrammed this issue to make it clear to understand "at a glance"? If not, will someone? Before I get too deep into Qt?

bbns
2010-01-17, 01:41
@Texrat

There are few things I am pretty sure:
1) Vanilla Qt will work on all platforms.
2) There are people know the issues and already look into it.

The problem I have seen so far are the matters of UI, top level wrappers and service framework (Maemo 6 framework and Qt mobility project).

But come to think of it, it's similar to Qt on KDE. Where KDE has different set of APIs on top of Qt, but basically you could access most functionality via just writing Qt vanilla code itself.

One suggestion, if you want to write code on N900 and keep compatibility for future Maemo platform:

1) Write the core in plain Qt code
2) Decouple your UI from the core since it has to be re-written anyway for future more touch friendly experience.
3) Pack your functionality relies on devices specific hardware into components, such as bluetooth / camera, etc. In case anything change, you just need to re-write the underlying code without screw up your whole application.

Things will come more clear when close to Maemo 6 release. However, studying Qt itself is the right track since either Maemo 6 or Symbian^4 use Qt as foundation.

svdwal
2010-01-18, 10:30
Almost all of Qt apps in the world extend the basic framework to include their own widget sets and APIs. Even on desktop, some of the more serious commercial application use Qt as the core commonality but not to write a single app that magically works across platforms: they want the platform differences but also relatively cheap porting and a common set of tools.

This maybe is less than perfect, but I believe that that's reality and it's going to remain reality for a good reason.
When you try to limit mobile application developers to what a cross-platform framework can do without some platform-specific extensions, you end up with something more like J2ME or very basic HTML. Generalizing UI needs in a cross-platform way takes time, more time than Nokia and other companies have if they want to innovate in a way that reacts to market needs.


There is a big difference between having to create a couple of widgets and having to rename each and every Qt class in your app.

The Dui proposal requires you to change all the top-level UI code. Even though the change seems trivial (Q becomes Dui), it results in having to add complete UI components (an extra one for Dui and probably an extra one for Symbian ^4's UI as well), unless you take certain measures. The measure one takes is to add an extra layer of indirection called a Bridge, with a MyApplication calling either a MyDuiApplication (implemented by DuiApplication), a MySymbian^4Application (implemented by the Symbian ^4 variant of QApplication) or a MyPlainQtApplication (implemented by QApplication). Do this for each and every high-level Qt class that is or might be renamed now or in the future.

Considering that all Qt classes are already implemented as Bridge classes, the obvious thing to do is to implement Qt for Maemo 6 as an extra implementation for the main Qt classes, and to do the same for Symbian^4, and not require each and every developer that wants to target both Symbian^4 and Maemo 6, and possibly other Qt-supported platforms, to create their own set of Bridge classes. That is a complete waste of our time. The commercial realities of mobile development are such that commercial developers do not have the luxury of spending time to fix defects in vendor-provided frameworks. This is something that vendor employees should think very carefully about, because their actions will reflect on the vendors perceived willingness to support commercial third party developers.

Having dealt with the generics, its time for the specifics.

Having device specific classes is of course fine, as long as there are also plenty of generic classes. To make this more concrete, I don't care about the look and feel of the class that lets me set a boolean, as longs as its interface is the same, which means that there should be a generic Qt boolean widget. The reason is that almost all widget classes that I use in my apps will be generic widgets, maybe with a few device-specific ones at places where it matters. If I have to spend days on managing generic widgets (number and text input, radio buttons, sliders, checkboxes, labels), I don't have time for creating that single special widget that makes my app stand out from the competition.
So, create as many Dui-specific widgets as you want, but put the behind a unified Qt API that says, get me a boolean , or get me a number, or get me a bit of text.

The mayor factor on deciding what Qt-enabled platforms your app will have to run on is screen size. In that respect Maemo 6 and Symbian^4 are almost identical, compared to the desktop, notebook and netbook worlds. So changes are that I will need two sets of layout definitions, one for handheld devices and one for big-screened ones. But that is two layout definitions, not three slightly different sets of code.


To be more precise, we COULD have a 100% common API that would allow for the awesome new touch UIs and would work great on Maemo and Symbian devices, but it would probably be ready a couple of years from now - when we already want the newer thing.


I don't think it will take years. Implementing the look and feel of the widget might take a year, but defining it's interface will take days, and putting it in the Qt framework won't take that long either.


What is probably more practical is letting Maemo/Symbian innovate on their time frames, and later take the common parts into the core framework. Qt has done this with KDE for years.


By that time the mobile OS war will be over. By having a unified Qt API it might take slightly longer for the platform to become available, but the upside is that the unified mobile Qt platform will be a lot bigger from the start, combining both Maemo 6 and Symbian^4. And as a bonus, you get the additional Qt platforms for little extra work, and not for much extra work.


Qt is an excellent cross platform TOOLKIT, and if seen as such, it makes perfect sense (at least to me). It's the core for building great DUI apps for Maemo, great Orbit apps for Symbian, and later QML apps (some of which will be fully portable, some will include DUI/Orbit specific components).

There's always a difference between what a purely cross-platform app can do (whether it's QWidget / QGraphicsView / QML / WRT) and what an app with a specific platform in mind can do. Show me a solution that solves that problem - Android tried but I don't think they've proven success (see posts about subtle fragmentation between Android phones - J2ME deja-vu).


Java had problems because vendors deliberately introduced their own extensions and incompatibilities. Further, for very small screens you do need exact pixel placements. That isn't a problem with mobile screens as big as they are now, for standard components.


With Qt you can port the pure cross-platform apps for free, and the platform-specific apps for cheap (as QGraphicsView is still the core for both Dui and Orbit). It is my belief that that's the role Qt should have!

Hiding Dui behind Qt is the way to make things cheap. Only for the Dui classes that do not have a generic Qt equivalent do you need it. DuiApplication, DuiWindow and such are not needed at the third party API level.

noam
2010-01-18, 12:17
I don't have a technical argument - I completely agree that a better way to do things would be as a Qt backend and not a frontend on top of Qt. I also believe that the Maemo/Symbian people have done their best to use the Qt toolkit to create great device UIs in an acceptable timeframe, and sometimes in that process the API choices are optimized for short-term device UI work and not for portability - that's inevitable if Nokia ever wants to go to market. If I was in their place, I don't know if I could have done a better job on the same schedule and conditions without knowing what I know now, when it's already done (but maybe someone else would).

arlehyn
2010-01-19, 11:52
Almost all of Qt apps in the world extend the basic framework to include their own widget sets and APIs. Even on desktop, some of the more serious commercial application use Qt as the core commonality but not to write a single app that magically works across platforms: they want the platform differences but also relatively cheap porting and a common set of tools.

But this is not what's happening here as far as I can see. The "Qt" app does not extend the basic framework, the app uses the basic framework of the device.

There's a big difference!

sjaensch
2010-01-19, 12:10
dubik, you got me confused. You basically said that DUI and Orbit are both there to perform the same task (highly animated finger-friendly UIs). You also said that DUI will work on all platforms, be it desktop, Maemo or Symbian. If so, what's the point of Orbit? Do I even need to care about it? Or will I use DUI+Qt in the same way that I use plain Qt right now and get a first-class citizen on all platforms, (almost) without #ifdefs?

arlehyn
2010-01-19, 12:11
Orbit and Dui are UI Frameworks which provide ways to write finger oriented, highly animated applications. Basically something similar to what iphone, android or palm pre provides. QWidget is not designed for that. They also provide quite a few other things like virtual keyboard, localization, application lifecycle, service framework, notification framework and so on. Perhaps I phrased it wrong in my message. Dui apps are not maemo specific, they are Dui specific. You can take Dui library to your platform (where qt is supported) compile and create nice looking applications.
So you can take Dui to Symbian, compile it, and create nice looking applications? To port any Maemo app to Symbian, the easiest route would be to statically link against DUI library?

And same for the case of developing an app for Symbian, with an intention to release a Maemo version later, also prefer DUI?

Or prefer Orbit for both instead of DUI, assuming that Maemo devices have both more storage space for extra libraries, and better package management?

Anyway, if this works, then no problem, but somehow I have a feeling it's not this simple...?

dubik
2010-01-19, 15:27
So you can take Dui to Symbian, compile it, and create nice looking applications? To port any Maemo app to Symbian, the easiest route would be to statically link against DUI library?

And same for the case of developing an app for Symbian, with an intention to release a Maemo version later, also prefer DUI?

Or prefer Orbit for both instead of DUI, assuming that Maemo devices have both more storage space for extra libraries, and better package management?

Anyway, if this works, then no problem, but somehow I have a feeling it's not this simple...?

Yes, it's that simple :)
Dunno about orbit, but there are no technical reasons why you can't ship DirectUI lib with your app.

svdwal
2010-01-21, 09:30
So you can take Dui to Symbian, compile it, and create nice looking applications? To port any Maemo app to Symbian, the easiest route would be to statically link against DUI library?

And same for the case of developing an app for Symbian, with an intention to release a Maemo version later, also prefer DUI?

Or prefer Orbit for both instead of DUI, assuming that Maemo devices have both more storage space for extra libraries, and better package management?

Anyway, if this works, then no problem, but somehow I have a feeling it's not this simple...?

It won't be that simple.

1) Look and feel. Dui apps will have a different look and feel from Symbian ^4 apps, at least, this is one of the arguments used against my proposal. However, App Stores have look and feel as one of their main requirements, so a Dui app will not be allowed on Symbian^4 App Stores, and a Symbian ^4 app will not be allowed on Maemo 6 App Stores. This fact alone will make this proposal unusable for commercial developers.

As my proposoal results in apps having the look and feel of the host platform, it is not an issue there.

2) These libraries will be huge, and statically linking will result in huge apps. Huge apps are very hard to download, and App Stores have limitations on size too. It also results in the apps taking up more space on a device, so you cannot sell as many apps to a single customer as you could when apps were smaller.

3) Why have two libraries doing the same thing instead of one? If Dui and Symbian^4 can be put on both device classes, there is no difference. So kill either Dui or Symbian^4. The argument here was again that Maemo6 and Symbian ^4 is for different device classes. For political reasons, with two competing parties developing competing UI frameworks, it will mean the death of one party.

The problem is that both parties think that commercial third-party developers are very much interested in device look and feel, as they are, being their companies representative.

People, let me tell you, once and for all, commercial third party developers don't care at all for look and feel. True, look and feel will help sell a device to a device manufacturers customer, and for a device manufacturers perspective look and feel is vitally important.

But commercial third party developers will go for the look and feel that attracts the most paying customers. We don't care what we think ourselves about a given look and feel, we only care about the ease of making money.

Having a different API for each existing look and feel is bad for us as it makes it harder to make money. What we therefore do is support only the best money making API&look and feel combi's in the market. Currently that is iPhone OS, Symbian OS, RIM,

Again, device manufactures care about looks and feel, and commercial third party developers care about API's. What is good for both then is a unified API supporting lots of looks and feels. As far as we are concerned, different parties inside a company can slug it out all they want. It's not my company after all, and if the competition is better for my business I will switch anyway.

Hukka
2010-02-15, 09:16
As I'm sure most have already noticed from Planet Maemo, it seems like Orbit aka Uiemo will run on Maemo. At least one quite big obstacle down on the road to interoperability.

Of course, this is conjecture from an early demo, but see for yourself: http://zchydem.enume.net/?p=561

vivainio
2010-02-15, 09:21
As I'm sure most have already noticed from Planet Maemo, it seems like Orbit aka Uiemo will run on Maemo. At least one quite big obstacle down on the road to interoperability.

Of course, this is conjecture from an early demo, but see for yourself: http://zchydem.enume.net/?p=561

Moreover, it runs on N900 as well; no need to wait for Harmattan.

conny
2010-02-15, 14:29
Now it gets even more interesting with Meego. The Meego architecture (http://meego.com/developers/meego-architecture) talks about "Handheld UI Framework" and "Netbook UI Framework". The former will probably be the Harmatan UI Framework, but what about the latter? Probably also based on QGraphicsView, but will they have more in common?

Mark Wilcox
2010-10-22, 13:22
So, to return to this thread, I never did get the chance to compare those working frameworks and figure out how best to go cross-platform as they've been canned:
http://mobilephonedevelopment.com/archives/1138
With reference to a post by a Nokia employee:
http://www.gorkem-ercan.com/2010/10/my-boss-asked-me-to-use-orbit-ui-and-i.html

I don't want to say I told you so but if people had been listening to the external developers back in November/December last year a lot of wasted effort and possibly time-to-market could have been saved.

My question now is, if the MeeGo UI framework is not the thing to use what is - really just QML? Where's the standard chrome (battery and signal etc) going to come from? Are there some QML components for that on the way. What will define the standard platform look and feel?

Just curious...

Mark

NvyUs
2010-10-22, 13:26
MeeGo Touch as Not been canned

vivainio
2010-10-22, 13:29
My question now is, if the MeeGo UI framework is not the thing to use what is - really just QML? Where's the standard chrome (battery and signal etc) going to come from? Are there some QML components for that on the way. What will define the standard platform look and feel?

Here's the deal:

http://labs.qt.nokia.com/2010/09/10/building-the-future-reintroducing-the-qt-quick-components/

vvaz
2010-10-22, 13:41
My question now is, if the MeeGo UI framework is not the thing to use what is - really just QML? Where's the standard chrome (battery and signal etc) going to come from? Are there some QML components for that on the way. What will define the standard platform look and feel?

Just curious...



As far as I understand there will be QML, Qt Quick and Qt Mobile.

Also there will be no standard look and feel heavily enforced on developers. Look here:

http://labs.qt.nokia.com/2010/10/19/exporting-qml-from-photoshop-and-gimp/

Graphic designers can make any design and just export it to QML. On one hand this is usability problem but on the other massive incentive to all designers, corporations and institutions which prefer to make their own designs and not to bow to some external idea how things should like.

Not sure how guts of this system will be implemented but it offers easy way for corporate identity not only on telecom level but even on all small company phones it will be *cheap* way to create its own look&feel.

Also - not sure if such "forking" of efforts was essentially bad thing. Without trial&error you wouldn't know if things are good or bad. You have to go some distance with each path to know where you should eventually commit yourself. In Nokia and Qt case it was dramatically visible due to open source method of development.

Supposedly Apple was working on iPhone several years before it was released - do you think they were working from the day one on only one and true version? I don't think so.

Mark Wilcox
2010-10-22, 13:42
OK, if MeeGo Touch (libdui + native app UIs) really haven't been canned then you should probably do some internal and external comms to make sure everyone knows what's going on. Simon Judge is fairly widely read in the mobile world and that story could easily spread.

I was aware of the Qt Quick components project but wonder how far we are from a MeeGo device launch if we've got to wait for them to finish and new UIs to be written in QML (maybe not far... QML is pretty quick to do after all).

Thanks for the answers.

NvyUs
2010-10-22, 13:48
MeeGo 1.1 is released next week, they are a bit late canning MeeGo touch if its true.
but it could explain why the device they planned to releases this quarter as been delayed until sometime in 2011

Mark Wilcox
2010-10-22, 13:55
From the QML Components post it seems clear that if you want MeeGo users to find your UI familiar then you should follow the UI design guidelines, whether you're using native or QML.
http://meego.com/developers/ui-design-guidelines/handset
The QML components will help you to do so.

Of course you've always been able to do a completely custom UI, on just about any platform. Rigidly enforcing styles was always restricted to 3rd party stuff that went in ROMs or on memory cards... hopefully those days a pretty much over.

Mark Wilcox
2010-10-22, 14:01
MeeGo 1.1 is released next week, they are a bit late canning MeeGo touch if its true.
but it could explain why the device they planned to releases this quarter as been delayed until sometime in 2011
The first Symbian^4 PDK was released the same day that Nokia announced they would not be using the numbering any more and canned Orbit (aka UIEMO - I can confirm that really is canned) and the new apps based on it. The fun with this open source embedded stuff is that releases don't really mean a thing - until it ships in millions of devices and there's no taking it back, there's not much you can count on for certain. :-)

kate
2010-10-22, 16:01
OK, if MeeGo Touch (libdui + native app UIs) really haven't been canned then you should probably do some internal and external comms to make sure everyone knows what's going on. Simon Judge is fairly widely read in the mobile world and that story could easily spread.


MeeGotouch is part of MeeGo, so it is not just going away. Qt Quick and Qt Quick components is preferred to new applications because is is cross platform. You have Qt Quick everywhere were you have Qt4.7, all desktop platforms, maemo5, and MeeGo.


I was aware of the Qt Quick components project but wonder how far we are from a MeeGo device launch if we've got to wait for them to finish and new UIs to be written in QML (maybe not far... QML is pretty quick to do after all).

Thanks for the answers.

I can't say when Qt Quck components is is finished but what i have tried it, even it is early stages, it is not so bad shape at all.

We have plan to release ready packetized version soon so that developers can start play around with it. If you can't wait you can download it from gitorious http://qt.gitorious.org/qt-components

qgil
2010-10-22, 16:27
Now the developer story is easy to explain: Qt is the Queen, Qt Quick is the King and Qt Mobility is the Wizard. That's it.

All the rest is now tagged as legacy, which means that the teams working on these frameworks are now planning the way forward to contribute directly to Qt's speed and success.

If you are an application developer interested in MeeGo / Symbian the path is clear. If you are interested in alternative paths that's fine, but up to you.

kate
2010-10-22, 17:13
Now the developer story is easy to explain: Qt is the Queen, Qt Quick is the King and Qt Mobility is the Wizard. That's it.

All the rest is now tagged as legacy, which means that the teams working on these frameworks are now planning the way forward to contribute directly to Qt's speed and success.

If you are an application developer interested in MeeGo / Symbian the path is clear. If you are interested in alternative paths that's fine, but up to you.

I still like to clarify, even Qt is Queen and QWidgets are part of Qt, don't expect to get full MeeGo user experience with them. If target is application that really succeeds and offers optimum mobile user experience, Qt Quick with components is only reasonable choice.

Kate

cristids
2010-10-22, 17:27
I only hope Symbian, Meego, Maemo and WM will all get same widgets set and we will not have to do so many #ifdef. I think Qt and all OSes just got a second chance.

attila77
2010-10-24, 21:14
They cannot have *identical* widget sets as the functionality is different on various platforms, but you will certainly get a lot less #ifdefs than you would by making separate MTF, Orbit and QWidget UIs.

Venemo
2010-10-24, 22:15
Here's how I see the situation:
So basically we have 3 main separate and largely incompatible GUI tools:

- QWidgets: Native look&feel for each platform, cross-platform but deprecated.
- QML: also cross-platform, but mostly recommended for creating totally unique GUIs.
- MeeGo Touch: MeeGo only; hardware-accellerated

So the cheapest solution is to use one of these depending on your target platforms, and if you can afford it, you can use the others too for making different UIs for different platforms.

Do I see the situation correctly?

w00t
2010-10-24, 23:33
Here's how I see the situation:
So basically we have 3 main separate and largely incompatible GUI tools:

- QWidgets: Native look&feel for each platform, cross-platform but deprecated.
- QML: also cross-platform, but mostly recommended for creating totally unique GUIs.
- MeeGo Touch: MeeGo only; hardware-accellerated

So the cheapest solution is to use one of these depending on your target platforms, and if you can afford it, you can use the others too for making different UIs for different platforms.

Do I see the situation correctly?

well, you make one mistake in leaving 'hardware acceleration' under MTF, as QML can also be hardware accelerated (as can QWidget), and likewise, MeeGo Touch can use software rendering, so there's no functional difference between the three there.

personally, the summary, as i'd put it, is below.

summary being (as it ended out being a bit longer than I expected), with no surprises:
- QWidget is portable, but aging badly
- QML is shiny, new, and looking promising, but really needs more work in the portability department with e.g. components (no, mobiles really aren't the only target in the world, no matter what you say, Nokia) - which is something I myself have started playing with in the past day
- MeeGo Touch is an 'ok' choice if you want a good product on MeeGo now and don't care about maintaining it into the future or making the best technology choice for deployment on multiple platforms.

The comparison:
QWidget
(note, that it isn't deprecated from the Qt point of view as there is no capable replacement yet, but it clearly isn't where UIs of the future are coming from)
Pros:
- Cross platform
- Native look and feel
Cons:
- Not really flexible enough to do some of the shinier UI tricks
- Painting stuff yourself is really a pain in the ***, especially when you get on to things like delegates

QML
Pros:
- Cross platform
- Flexible
Cons:
- No native look and feel
- Immature
- QML (with Qt Components)
Same as QML, with the addition:
Pros:
- Some native look and feel, but only on limited platforms at this point.


MeeGo Touch
Pros:
- Designed for Omg! Shiny!
- Fairly mature, thanks to having had a number of applications built on it
Cons:
- A very, very moving target - I don't think the API was all that well thought out in places (seriously. MContentItem, MBasicListItem, MAdvancedListItem, MDetailedListItem?! how many different ways do we *really* need to show data in a list..), nor the requirements, and it shows in the sheer amount of stuff that is deprecated from MeeGo Touch, even in more recent times.
- No look and feel for platforms other than MeeGo whatsoever
- Increasingly less portable (things like MGConfItem, in addition to being kind of crappy design, are kind of hinting where the target platform is)

egoshin
2010-10-24, 23:46
Where I can find Qt 4.6 binaries for ARM platform (Maemo5)?

Maemo repository doesn't have it (see bug https://bugs.maemo.org/show_bug.cgi?id=11437)

w00t
2010-10-24, 23:49
Where I can find Qt 4.6 binaries for ARM platform (Maemo5)?

Maemo repository doesn't have it (see bug https://bugs.maemo.org/show_bug.cgi?id=11437)

For dev stuff, you can't. It's just not available, thanks to the way they do packages. You'll need to build it yourself via scratchbox and/or chicken sacrifice.

[I don't think this is strictly on-topic for this thread, btw]

egoshin
2010-10-24, 23:56
For dev stuff, you can't. It's just not available, thanks to the way they do packages. You'll need to build it yourself via scratchbox and/or chicken sacrifice.

[I don't think this is strictly on-topic for this thread, btw]

In my mind the absence of capability to build Qt application from source on N900 is an exactly "Maemo 5 loosing source compatibility with plain Qt". Sorry for misunderstanding.

EDIT: Yes, I understand that Maemo 5 is not Maemo 6, but...

daperl
2010-10-25, 01:06
Where I can find Qt 4.6 binaries for ARM platform (Maemo5)?

As an example:

apt-get -d --reinstall install libqt4-core

This will just download and not actually reinstall.

Then look in

/var/cache/apt/archives

and you should find

libqt4-core_4.6.2~git20100401-0maemo1+0m5_armel.deb

egoshin
2010-10-25, 01:28
As an example:

apt-get -d --reinstall install libqt4-core

This will just download and not actually reinstall.

Then look in

/var/cache/apt/archives

and you should find

libqt4-core_4.6.2~git20100401-0maemo1+0m5_armel.deb

I could not ask without reason, you can try yourself. Or just follow the reference to bug - I put some interesting output in it.

daperl
2010-10-25, 02:00
I could not ask without reason, you can try yourself. Or just follow the reference to bug - I put some interesting output in it.

LOL, that's funny. Well, in a coincidental sort of way. I ran into the same problem when trying to build fcamera on the device, so then I had to rebuild some of those (http://talk.maemo.org/showthread.php?p=771651&postcount=102). Also, I think some Qt binary package(s) messed up my FREMANTLE_ARMEL target in one of my scratchbox installs. It caused the qemu transparency stuff to stop working.

Thanks for reporting it.

daperl
2010-10-25, 05:06
Here's the bug fix for FREMANTLE_ARMEL:

--- qt4-x11-4.6.2~git20100401.orig/configure 2010-04-08 02:48:34.000000000 -0700
+++ qt4-x11-4.6.2~git20100401/configure 2010-10-24 21:52:36.000000000 -0700
@@ -2297,7 +2297,8 @@
# if we're within scratchbox, build qmake and friends with the host compiler
if [ -z "$PLATFORM" ] && [ -z "$XPLATFORM" ] && [ "$SBOX_UNAME_MACHINE" = "arm" ] ; then
XPLATFORM="linux-g++-maemo5"
- PLATFORM="linux-host-g++"
+ #PLATFORM="linux-host-g++"
+ PLATFORM="linux-g++-maemo5"
QT_FORCE_PKGCONFIG=yes
fi
if [ -z "$CFG_ARCH" ] && [ "$SBOX_UNAME_MACHINE" = "arm" ] ; then

I've successfully built armel binaries of

qmake
moc
rc
uic

with the above patch on an x86 machine in the FREMANTLE_ARMEL target with the following command:

dpkg-buildpackage -b -d -nc -rfakeroot

The build hasn't reached the other binaries yet, but their Makefiles have been created.

egoshin
2010-10-25, 05:55
For a moment I build it on N900, following your instruction in other thread.

EDIT: It again failed in opengl check -

"The EGL functionality test failed!
EGL is required for OpenGL ES to manage contexts & surfaces.
You might need to modify the include and library search paths by editing
QMAKE_INCDIR_EGL, QMAKE_LIBDIR_EGL and QMAKE_LIBS_EGL in
/root/qt4-x11-4.6.2~git20100401/mkspecs/linux-g++-maemo5."

Both packages - opengles-sgx-img-common-dev and libgles2-sgx-img-dev are installed as so as non "-dev" versions.

daperl
2010-10-25, 06:55
For a moment I build it on N900, following your instruction in other thread.

EDIT: It again failed in opengl check -

"The EGL functionality test failed!
EGL is required for OpenGL ES to manage contexts & surfaces.
You might need to modify the include and library search paths by editing
QMAKE_INCDIR_EGL, QMAKE_LIBDIR_EGL and QMAKE_LIBS_EGL in
/root/qt4-x11-4.6.2~git20100401/mkspecs/linux-g++-maemo5."

Both packages - opengles-sgx-img-common-dev and libgles2-sgx-img-dev are installed as so as non "-dev" versions.

Yes, the build failed. I'll take a closer look at the errors tomorrow, but from a quick glance I think it was gl related.

cristids
2010-10-25, 08:28
They cannot have *identical* widget sets as the functionality is different on various platforms, but you will certainly get a lot less #ifdefs than you would by making separate MTF, Orbit and QWidget UIs.

I fail to see why they must be incompatible. Actually I kind of know, it is lack of communication between divisions in the same company and this is what makes it even more unacceptable.
From a developer point of view I do want my application to look exactly the same on all targeted mobile platforms. I don't want my application to look different in symbian than meego or maemo. I mean we are talking about mobile devices having almost same screen size/resolution. There are four mobile os-es supported right now, why should one think an application needs to look different in any of them?
Well I now that the look and feel of a button is not same on meego vs symbian but that doesn't mean I need a button class for each. This should be Qt hidding it from me.
If they cannot achieve that then this means Qt fails to deliver on its promise big time.

From a user point of view it means that some platforms may not get some applications because it means redesigning all UI. So platforms having lower market adoption (think Maemo) may not get applications after all, even though they are available for other platforms supporting Qt.

attila77
2010-10-25, 09:26
I don't want my application to look different in symbian than meego or maemo. I mean we are talking about mobile devices having almost same screen size/resolution. There are four mobile os-es supported right now, why should one think an application needs to look different in any of them?
Well I now that the look and feel of a button is not same on meego vs symbian but that doesn't mean I need a button class for each.

Because the UI paradigm *is* different on these OSes, either due to historical reasons or because of HW form factors (they definitely do NOT have nearly the same size/resolution and screen/kbd). This is not about just a QPushbutton, that we could get over easily, but rather how much part of the OS the app feels. I agree that the #ifdeffing should be done away with or at least minimized, but you cannot so easily forego platform specifics (Components is no silver bullet but at least it makes the mess more manageable). As said, QPushbutton is easy, but what do you do with Symbian softkeys, Maemo's stacked windows, funky pickers, application menus, file management, etc. I know, I know 'not my problem', but am just saying that after doing a project or two you *will* realize that you don't *really* want your apps to look literally the same on all platforms, the best Qt can do is to help you minimize the pain.

Khertan
2010-10-25, 09:32
Exactly it s not cross plateform but Qt minimize the pain.

cristids
2010-10-25, 09:43
Because the UI paradigm *is* different on these OSes, either due to historical reasons or because of HW form factors (they definitely do NOT have nearly the same size/resolution and screen/kbd). This is not about just a QPushbutton, that we could get over easily, but rather how much part of the OS the app feels. I agree that the #ifdeffing should be done away with or at least minimized, but you cannot so easily forego platform specifics (Components is no silver bullet but at least it makes the mess more manageable). As said, QPushbutton is easy, but what do you do with Symbian softkeys, Maemo's stacked windows, funky pickers, application menus, file management, etc. I know, I know 'not my problem', but am just saying that after doing a project or two you *will* realize that you don't *really* want your apps to look literally the same on all platforms, the best Qt can do is to help you minimize the pain.

Please explain to me how N900 is different in HW form factor than N8 or newer symbian devices bearing Qt. They all have touch screens that are about same size. I assume N9 or whatever name will have will be somwhere between 3 and 4.5 inches.
None of the elements you mention must be os specific. I mean I would've have them all put under Qt umbrella. If I want soft keys implemented that is fine, I put the code in Qt, making a note that it is only symbian supported. Meego finds out that it needs soft keys, here they are,we enable them in qt. But each with its own set of controls it is simply bad design and bad interaction between architects. I understand that they choose the shortest path but eventually this will strike back as Qt doesn't deliver on its promise. Instead they should've plan better and when a UI component is needed implement it in all platforms, make it look the same and everybody would've been happy.

egoshin
2010-10-25, 16:21
Yes, the build failed. I'll take a closer look at the errors tomorrow, but from a quick glance I think it was gl related.

Today's PR1.3 - package libqt4-dev_4.7.0~git20100909-0maemo1+0m5_armel.deb - the same sh*t, it has Intel386 binaries instead of ARM-based.

attila77
2010-10-25, 16:43
Please explain to me how N900 is different in HW form factor than N8 or newer symbian devices bearing Qt. They all have touch screens that are about same size. I assume N9 or whatever name will have will be somwhere between 3 and 4.5 inches.

That's the point, Qt is not just a 'widget set for ~4" touchscreen devices'. It really needs to (and already does) cover a lot more ground than that, and esp with MeeGo I expect to see a lot wider device spectrum than just N8/N900 lookalikes.

None of the elements you mention must be os specific. I mean I would've have them all put under Qt umbrella. If I want soft keys implemented that is fine, I put the code in Qt, making a note that it is only symbian supported. Meego finds out that it needs soft keys, here they are,we enable them in qt. But each with its own set of controls it is simply bad design and bad interaction between architects. I understand that they choose the shortest path but eventually this will strike back as Qt doesn't deliver on its promise. Instead they should've plan better and when a UI component is needed implement it in all platforms, make it look the same and everybody would've been happy.

I have the feeling you are talking about the now bygone Orbit vs MTF discussion. Please check up on Qt Components (http://labs.qt.nokia.com/2010/09/10/building-the-future-reintroducing-the-qt-quick-components/), it is almost exactly what you seem to be missing.

egoshin
2010-10-27, 20:31
Yes, the build failed. I'll take a closer look at the errors tomorrow, but from a quick glance I think it was gl related.

I used QT 4.7.0 from PR.1.3 and build in accordance with your instructions passed up to creating bin/qmake. Good! It failed just after that on absence of X11 libs.

I am going to recreate the rest of binaries (moc etc).

But just one question - zrules.txt misses some parameters in comparison with debian/rules, like "-graphicssytem raster" or "-phonon" or "no-rpath". Do I need to add that to zrules.txt?

Venemo
2010-10-28, 10:28
well, you make one mistake in leaving 'hardware acceleration' under MTF, as QML can also be hardware accelerated (as can QWidget), and likewise, MeeGo Touch can use software rendering, so there's no functional difference between the three there

If this is the case, what is the point in having just another widget framework for MeeGo instead of using the already existing QWidget-based stuff?

daperl
2010-10-28, 14:02
I used QT 4.7.0 from PR.1.3 and build in accordance with your instructions passed up to creating bin/qmake. Good! It failed just after that on absence of X11 libs.

I am going to recreate the rest of binaries (moc etc).

But just one question - zrules.txt misses some parameters in comparison with debian/rules, like "-graphicssytem raster" or "-phonon" or "no-rpath". Do I need to add that to zrules.txt?

zrules.txt was a hack. I think my one line fix to configure is the better solution. At least for building the armel tools. So, maybe ignore zrules.txt.

I haven't tried building Qt in PR1.3 yet, but I was able to fix some other compile errors for 1.2. However, that just opened a can of worms that maybe revealed a deeper issue. Anyway, I'll try building 4.7 when I get a moment, and if the build fails as it did in 1.2, I'll post some details here.

egoshin
2010-10-28, 16:23
zrules.txt was a hack. I think my one line fix to configure is the better solution. At least for building the armel tools. So, maybe ignore zrules.txt.

Where is "one line fix"? Changing linux-g++-maemo? In any case it requires running "configure" and it's parameters issue is still here.

BTW, in 4.7.0 it seems fixed and now I bump into "absense" of XLib. It doesn't elaborate which kind of xlib it needs - run time or developer build time. Or it may just absence of /usr/X11R6/lib...

daperl
2010-10-28, 17:02
Where is "one line fix"? Changing linux-g++-maemo? In any case it requires running "configure" and it's parameters issue is still here.

Make the one line configure fix and then let the debian tools do all the work.

From scratchbox in the FREMANTLE_ARMEL target:

mkdir qt
chdir qt
apt-get source libqt4-dev
chdir qt4-x11-4.7.0~git20100909
sed -i 's/linux-host-g++/linux-g++-maemo5/' configure
dpkg-buildpackage -b -d -nc -rfakeroot

No other changes are needed in order to create qmake moc rcc and uic.

daperl
2010-10-28, 17:12
And don't forget to do the following:

fakeroot apt-get build-dep libqt4-dev

egoshin
2010-10-28, 18:55
Make the one line configure fix and then let the debian tools do all the work.

From scratchbox in the FREMANTLE_ARMEL target:

mkdir qt
chdir qt
apt-get source libqt4-dev
chdir qt4-x11-4.7.0~git20100909
sed -i 's/linux-host-g++/linux-g++-maemo5/' configure
dpkg-buildpackage -b -d -nc -rfakeroot

No other changes are needed in order to create qmake moc rcc and uic.

dpkg-buildpackage doesn't work because there is reference to /usr/share/cdbs/ files in debian/rule. Which package does it use - cdbs or cdbs-dh7? Or maemo-cflags-cdbs-rules?

egoshin
2010-10-28, 19:11
And don't forget to do the following:

fakeroot apt-get build-dep libqt4-dev

This program was written somebody worked with Microsoft - it says:

E: Build-dependencies for libqt4-dev could not be satisfied.

without elaboration and sign of more extensive diagnostic.

daperl
2010-10-29, 01:02
This program was written somebody worked with Microsoft - it says:

E: Build-dependencies for libqt4-dev could not be satisfied.

without elaboration and sign of more extensive diagnostic.

How did you upgrade your scratchbox? After commenting out all the extras repositories, here's what I did:

apt-get update
fakeroot apt-get upgrade

I then installed all the held back packages and I ran

fakeroot apt-get upgrade

until it said there were no more held back packages.

daperl
2010-10-29, 01:33
Awesome, the other build errors are gone in 1.3. Here's the debian/rules diff needed to complete the build:

--- debian/rules.orig 2010-10-27 01:04:40.140719086 +0100
+++ debian/rules 2010-10-27 01:03:16.552666520 +0100
@@ -52,7 +52,7 @@
HOST_EXCLUDES=-X/moc -X/rcc -X/uic -X/qmake -X/lrelease
EXTRA_STRIP_ARGS=$(HOST_EXCLUDES)
EXTRA_HOST_STRIP_ARGS=--strip-all bin/moc bin/rcc bin/uic bin/qmake bin/lrelease
- HOST_MKSPEC=-spec $(CURDIR)/mkspecs/linux-host-g++
+ HOST_MKSPEC=-spec $(CURDIR)/mkspecs/linux-g++-maemo5
else
HOST_EXCLUDES=
GL_BACKEND=desktop
@@ -118,7 +118,7 @@
common-build-arch:: build-dbus-tools build-linguist-tools build-maemo5-examples strip-host-tools build-uitools build-qml-tool

strip-host-tools:
- if [ -n "$(EXTRA_HOST_STRIP_ARGS)" ] ; then host-strip $(EXTRA_HOST_STRIP_ARGS) ; fi
+ if [ -n "$(EXTRA_HOST_STRIP_ARGS)" ] ; then strip $(EXTRA_HOST_STRIP_ARGS) ; fi

build-dbus-tools:
bin/qmake -o tools/qdbus/qdbusxml2cpp/Makefile tools/qdbus/qdbusxml2cpp/qdbusxml2cpp.pro

And here's the result:

-rw-r--r-- 1 maemo maemo 9898818 Oct 27 01:13 libqt4-core-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 1541266 Oct 27 01:13 libqt4-core_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 1995710 Oct 27 01:15 libqt4-dbus-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 230152 Oct 27 01:15 libqt4-dbus_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 14842646 Oct 27 01:16 libqt4-declarative-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 1425932 Oct 27 01:16 libqt4-declarative_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 5897106 Oct 27 01:16 libqt4-dev_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 42749090 Oct 27 01:14 libqt4-gui-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 5035830 Oct 27 01:13 libqt4-gui_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 554966 Oct 27 01:16 libqt4-maemo5-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 206572 Oct 27 01:16 libqt4-maemo5-examples_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 29798 Oct 27 01:16 libqt4-maemo5_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 840278 Oct 27 01:16 libqt4-multimedia-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 64888 Oct 27 01:16 libqt4-multimedia_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 6236302 Oct 27 01:14 libqt4-network-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 618632 Oct 27 01:14 libqt4-network_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 2745624 Oct 27 01:16 libqt4-opengl-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 1454 Oct 27 01:16 libqt4-opengl-dev_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 221480 Oct 27 01:16 libqt4-opengl_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 3338876 Oct 27 01:16 libqt4-phonon-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 242438 Oct 27 01:16 libqt4-phonon_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 19667124 Oct 27 01:14 libqt4-script-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 1363486 Oct 27 01:14 libqt4-script_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 1020768 Oct 27 01:14 libqt4-sql-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 165326 Oct 27 01:14 libqt4-sql-sqlite-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 21482 Oct 27 01:14 libqt4-sql-sqlite_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 100724 Oct 27 01:14 libqt4-sql_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 1708854 Oct 27 01:14 libqt4-svg-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 175042 Oct 27 01:14 libqt4-svg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 503944 Oct 27 01:15 libqt4-test-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 59552 Oct 27 01:15 libqt4-test_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 746740 Oct 27 01:13 libqt4-translations_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 1293596 Oct 27 01:15 libqt4-webkit-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 6047210 Oct 27 01:15 libqt4-webkit_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 438090 Oct 27 01:15 libqt4-xml-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 115474 Oct 27 01:15 libqt4-xml_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 23883406 Oct 27 01:15 libqt4-xmlpatterns-dbg_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 1622994 Oct 27 01:15 libqt4-xmlpatterns_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-r--r-- 1 maemo maemo 180516 Oct 27 01:16 qt4-declarative-qmlviewer_4.7.0~git20100909-0maemo1+0m5_armel.deb
-rw-rw-r-- 1 maemo maemo 7302 Oct 27 01:16 qt4-x11_4.7.0~git20100909-0maemo1+0m5_armel.changes

Don't mind my time stamps; my settings inside my Ubuntu VM are off.

egoshin
2010-10-29, 03:50
How did you upgrade your scratchbox?

I run on N900. It is a reason why I need ARMEL binaries of qmake/moc/etc

daperl
2010-10-29, 04:30
I run on N900. It is a reason why I need ARMEL binaries of qmake/moc/etc

Me too, I upgraded my on-device sdk the same way I described above. Here's the answer to your earlier question:

(chroot)root@Nokia-N900:/
# dpkg -l|grep -i cdbs
ii cdbs 0.4.48-0osso2 common build system for Debian packages

egoshin
2010-10-29, 06:32
I gave up - for qt4 build I turned to scratchbox.

On "apt-get upgrade" it find hildon-initscripts version from SDK which is clearly for scratchbox (it tryes to remove mp-fremantle-002-pr) and "apt-get build-dep libqt4-dev" repeats the same unreasonable error message (see above).

Later I will compare the installed packages on both - scratchbox and N900 with qt4 debian/control but for now I think I am spending too much time just to fix a simple bug in small qt-based program.

egoshin
2010-10-29, 16:36
OK, I successfully build all qt4 packages in scratchbox and I have now ARMEL binaries for libqt4-dev - qmake/moc/uic/etc. It took a couple of hours, so in N900 it would take a couple of days I guess.

Let's see can it work for simple qt4-based application build in N900 (I target googlelatitude) now. If it work I can share that binaries.

EDIT: googlelatitude build on N900 works... some issue does exist but it may be bugs...

In any case - big thank to daperl for providing clues and build bugs fixes.

qgil
2010-10-30, 05:11
Sorry for interrupting but aren't you taking this old thread too far from its original topic?

egoshin
2010-10-31, 02:43
Sorry for interrupting but aren't you taking this old thread too far from its original topic?

Don't sure but my point is about incompatibility of Maemo's N900 with libqt4-dev. I speak not about general incompatibility but practical one - I can't did QT development on N900 from software source.

Sorry, if it bothers you.

attila77
2010-10-31, 11:03
I would say Quim is asking that not because what you say is not interesting but because this topic is in the Harmattan forum and about Maemo 6...

egoshin
2010-11-03, 19:22
Sorry for bothering you the last time in this thread -

I upload a package libqt4-dev-armel into https://garage.maemo.org/projects/libqt4-dev-arm/

You can install it on N900 Maemo for small QT development instead of libqt4-dev. It is built from the same source but with ARMEL binaries.

svdwal
2011-02-12, 23:09
Ok, people, do you now understand, after the windows Phone 7 announcements, why I started this thread? And do you see now why it was such a bad idea?

geneven
2011-02-12, 23:26
It sounds like the OP doesn't think this is too far off topic, and it might even be relevant to what's happening nowl