Excuse for not knowing who is who, because I don't want that to blur the topic, but I'm sure they have a reason. As far as I can tell, someone in the know posted some of those reasons and also gave us a link further explaining those reasons, and that's when some of us responded with, "We don't like your reasons."

Just a slight update, so everyone knows what's going on: I got a little sidetracked (understatement of the century...) by the arrival of my N900 today.

I've still started on the summary, and will send it tomorrow morning, lunchtime at the latest.

I'll link you all to the archive thread so those not subscribed can follow there, but I'd strongly suggest that anyone interested subscribe also, as it could prove an interesting discussion.

Assuming that DUI *is* Symbian as well (I've seen no mention of this, but granted, I don't follow Symbian development closely), then this still leaves other platforms out in the cold, meaning it's not a part of the regular Qt API, meaning I can't write once, run anywhere - and can't develop and test with my regular PC with Qt Creator which is what I'm used to doing.

Even assuming DUI becomes mainstream, then, there becomes the point of asking why it exists *in the first place* instead of these additions being added back to the regular Qt API, because when you look at DUI, pretty much all of it is just subclassing and adding a small amount of stuff, much the same way Hildon wrapped GTK and did its own stuff.

So, it's still an issue to me, and I personally am hoping I can find out more out of it starting tomorrow.

Thanks for your feedback, ColonelKilkenny.

Right - I come bearing news

I wrote up a summary of what I gathered to be the points here (portability, fragmentation, etc), and sent it on to qt-maemo-feedback.

I've just received the first reply, linked for your interest here:
http://lists.trolltech.com/pipermail...er/000045.html

Summary of points:
- I need to ask elsewhere about Dui (which I will do)
- QMaemo5* classes *are not* intended to be too pervasive, but only where things cannot be covered by more generic concepts.
- QMaemo5KineticScroller will stay, but it will not be needed unless fine-tuning of scroll behaviour is required

Are there any other areas of direct concern with QMaemo5 I can bring up?

I'm glad to see you got a fast and clear technical answer directly from one of the developers of the Qt 4.6 port for Maemo.

Now about the dui libraries, before you ask in maemo-developers make sure you have already gone through http://www.slideshare.net/peterschne...6-ui-framework and the posts of Tomas Junnonen in this own thread.

Let's say the division gets to the point where it's not so fragmented but simply between desktop/laptop platforms vs highly mobile platforms (of any kind). Would that scenario be so bad?

Note that I am solely speculating here; no advance info of any kind in my head.

Thanks for your help, and for the reference, Quim. I am indeed doing some more research first, and I will be sure to keep Tomas' post(s) in mind when I write things up.

If it can't be used on full form factor devices at all, I'd consider that a bit of a problem, yes - because that's where most people tend to develop and test, before finally deploying onto a device.

My main concern, really, is splintering for the sake of splintering. But like I said, I want to do some more reading first.

Thanks for your reply!

Not what I meant, sorry. What if specialized UI libraries were for all highly mobile devices and just not available on desktop/laptop platforms, likely due to screen size and mode-of-use issues. Is that as harmful? Is it tolerable?

Again, sheer speculation for sake of my understanding.

EDIT: ah, maybe I misunderstood your response. Ok, I see the issue now...

I don't think windows mobile will have DUI support.