Notices


Reply
Thread Tools
Posts: 4 | Thanked: 1 time | Joined on Dec 2009
#91
Originally Posted by bbns View Post
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.
 

The Following User Says Thank You to dragan For This Useful Post:
Posts: 12 | Thanked: 125 times | Joined on Dec 2009 @ York UK
#92
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
 

The Following 42 Users Say Thank You to Mark Wilcox For This Useful Post:
qgil's Avatar
Posts: 3,105 | Thanked: 11,075 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#93
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.

Last edited by qgil; 2009-12-15 at 17:16.
 

The Following 14 Users Say Thank You to qgil For This Useful Post:
Posts: 3,319 | Thanked: 5,607 times | Joined on Aug 2008 @ Finland
#94
Originally Posted by qgil View Post
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.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 

The Following 10 Users Say Thank You to attila77 For This Useful Post:
Posts: 24 | Thanked: 38 times | Joined on Nov 2009
#95
Originally Posted by qgil View Post
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?
 

The Following 9 Users Say Thank You to sjaensch For This Useful Post:
Posts: 12 | Thanked: 125 times | Joined on Dec 2009 @ York UK
#96
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.
 

The Following 15 Users Say Thank You to Mark Wilcox For This Useful Post:
qgil's Avatar
Posts: 3,105 | Thanked: 11,075 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#97
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.
 

The Following User Says Thank You to qgil For This Useful Post:
Posts: 654 | Thanked: 664 times | Joined on Feb 2009 @ Germany
#98
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....
 

The Following 13 Users Say Thank You to conny For This Useful Post:
Posts: 654 | Thanked: 664 times | Joined on Feb 2009 @ Germany
#99
Originally Posted by qgil View Post
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.
 

The Following 9 Users Say Thank You to conny For This Useful Post:
Jaffa's Avatar
Posts: 2,535 | Thanked: 6,676 times | Joined on Mar 2008 @ UK
#100
Originally Posted by conny View Post
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
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
 

The Following 15 Users Say Thank You to Jaffa For This Useful Post:
Reply

Tags
cross-platform, dui, future, harmattan, libdui, maemo, maemo 6, plain qt, programming, source compatibility, symbian

Thread Tools

 
Forum Jump


All times are GMT. The time now is 04:25.