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.