The problem with the two apps posted is that there's no consistency with any other application on the platform - or even between themselves.

This is not a technical issue with Qt (and fms' point seemed reasonable to me), but with great power to do whizzy custom UIs, comes the responsibility to not go silly.

Problem with input is because gtk+ is so lowly tied with system that for working Qt has to do some weird qt-gtk+ bindings which still isn't mastered enough.

<yawn> My "problem" is not with Qt. It is with how Qt is being presented as the next big thing that will solve all Nokia UI problems, both in Maemo and S60, paint reality in psychedelic colors, and cure world hunger. And my point, which some people manage to miss, is that Qt is nothing new and it will not solve most of Nokia's UI problems any better than GTK+ or some other toolkit would. It is just another toolkit, not a bad one, but not principally new either.

Well said.

The downside of QT on the tablets is just the accumulation of cruft. From here going forwards, even a minimal Maemo will need to include both libraries. I would rather have seen GTK+ and first class Java support, than GTK+ plus Qt.

But I think Nokia wanted something they could "own".

Regards,
Roger

That is a point I can definitely agree with. One UI library is enough on a mobile device with such a small memory. If Nokia does decide to use Qt everywhere, I would rather see them phase GTK+ out.

And that is a point that I could agree with...

Not because of any preference but also for improving focus and maximizing efforts.

is that my dismembered finger in the videos then?
my apps and videos use real fingers on real hardware, not mockups

for me, starting from the ground up has been one of the best things I couldv done.

to the folks mentioning about 2 libraries, theres more - canola and the e foundation UI will have to be squashed in there.

Linux is meant to be about diversity and those mockups look really cool and do get over the spirit of what I would like to achieve, however some of the multiple re-purposing of space seems over the top.
In my testing having the UI do multiple things on the same location caused its own problems and you end up cursing because the computer did what you thought and not what you wanted it to do.

I know with confidence that recipe list effect will annoy people as they try to scroll and the list expands because the list view miscalculated you making a click instead of a panning stroke - its something I thought a lot about and having it running on a dodgy used touch screen that doesn't react to every stroke confirmed it enough for me.

The problem with consistency on that level is that you can't write BETTER applications. If you want to stay consistent all the time you will always stick to the same old paradigms. Just look at Windows Mobile and TouchFlo: without breaking consistency the TouchFlo UI wouldn't have been possible and every WinMo phone would still only be usable with a stylus.
As long as an application is consistent within itself and doesn't break too many of the established paradigms it's ok to break consistency with other applications if it makes it more usable.

Consistency is important, but IMHO it should not be made a dogma. Some types of applications (maps, video/audio players, games) may just work better with a slightly different, non-standard UI, as they do not fit the normal desktop paradigm. In some sense, these applications create their own desktops abiding by their own set of rules dictated by specific usage case classes (i.e. "navigation", "media browsing", etc.).

That's what i meant, thanks fms.