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

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

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

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.

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

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

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

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...er/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?

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

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/peterschne...6-ui-framework and the posts of Tomas Junnonen in this own thread.

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

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

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

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

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

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!

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

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

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

I don't think windows mobile will have DUI support.

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

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.

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

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

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

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.

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

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.

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

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?

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

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.

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.

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

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.

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

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.

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

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

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

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.

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

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.

+1

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

You can use plain Qt QGraphicsWidgets and QGraphicsItems in DUI containers.

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

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

A quote I picked up on twitter the other day which I really liked and seems very appropriate here:

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

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.

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.

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

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

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

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

Hi zchydem,

This is the pretty much the same argument I'm making about the duplication with the Symbian framework. :)

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

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

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

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.

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

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.

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

Hi dubik,

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

Really? Years? It seems stuff in Qt-labs typically gets to the mainline a version or two later - maybe Qt 4.8?

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.

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?

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

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.

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

Here we go again. Nokia never learns from its past mistakes.

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

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.

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

Oh, and as someone commented on the broken gdb, we are finally updating that (yay!) to 7.0.

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

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

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

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

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.

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

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

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

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.

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?

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?

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

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?

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?

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?

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.


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.

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

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

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/qapplica...QApplication-6

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.

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.

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!

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.

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

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

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

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.

It runs natively.


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?

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.

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.

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.

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

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

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

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

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.

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.

No, I think it's a special case. Most apps can just use the standard QApplication constructor.

Fantastic! That's a good start.

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.

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.

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?

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.

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.

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

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

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.

sure.. but what do you think #ifdefs are for anyway?
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.