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

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

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

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

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

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

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

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

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

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

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

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

Now #ifdefs have their place of course but GUI design isn't one of them.
I'm not quite sure what solution you have given to this problem:

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

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

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

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

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

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

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

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

• Target multiple operating systems with one source code base

• Deploy code from one device target to another by reusing code

• Reassign development resources regardless of platform

• Future-proof code against platform changes

• Allow developers to focus on building core value of software instead of maintaining API

and, a little further down...

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

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

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

EDIT: bold the crux of the matter

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

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

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

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

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

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

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

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


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

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

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

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

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

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

If we put this in perspective, we have

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* I'm not pointing any fingers directly to anyone, I just speak generally.
** As far as possible, for sure. Please see my comprehension before replying.

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

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

Thanks and Cheers

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

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

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

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

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

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

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

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

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

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

I hate to interject with the voice of a noob, but...

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

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

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

@Texrat

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There's a big difference!

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

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

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

So you can take Dui to Symbian, compile it, and create nice looking applications? To port any Maemo app to Symbian, the easiest route would be to statically link against DUI library?

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

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

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

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

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

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

It won't be that simple.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Now it gets even more interesting with Meego. The Meego architecture talks about "Handheld UI Framework" and "Netbook UI Framework". The former will probably be the Harmatan UI Framework, but what about the latter? Probably also based on QGraphicsView, but will they have more in common?

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

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

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

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

Just curious...

Mark

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

MeeGo Touch as Not been canned

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

Here's the deal:

http://labs.qt.nokia.com/2010/09/10/...ck-components/

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

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

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

http://labs.qt.nokia.com/2010/10/19/...shop-and-gimp/

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

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

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

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

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

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

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

Thanks for the answers.

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

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

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

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

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

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

The first Symbian^4 PDK was released the same day that Nokia announced they would not be using the numbering any more and canned Orbit (aka UIEMO - I can confirm that really is canned) and the new apps based on it. The fun with this open source embedded stuff is that releases don't really mean a thing - until it ships in millions of devices and there's no taking it back, there's not much you can count on for certain. :-)

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

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

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

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

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

Now the developer story is easy to explain: Qt is the Queen, Qt Quick is the King and Qt Mobility is the Wizard. That's it.

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

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

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

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

Kate

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

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