Personally I see this as an extremely dangerous attitude coming from a very flawed analysis of the mobile app development space: 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?
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 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
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!
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.