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

Here's how I see the situation:
So basically we have 3 main separate and largely incompatible GUI tools:

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

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

Do I see the situation correctly?

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

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

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

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

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


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

Where I can find Qt 4.6 binaries for ARM platform (Maemo5)?

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

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

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

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

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

As an example:

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

This will just download and not actually reinstall.

Then look in

/var/cache/apt/archives

and you should find

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

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

LOL, that's funny. Well, in a coincidental sort of way. I ran into the same problem when trying to build fcamera on the device, so then I had to rebuild some of those. Also, I think some Qt binary package(s) messed up my FREMANTLE_ARMEL target in one of my scratchbox installs. It caused the qemu transparency stuff to stop working.

Thanks for reporting it.

Here's the bug fix for FREMANTLE_ARMEL:

I've successfully built armel binaries of

qmake
moc
rc
uic

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

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