[Qt-interest] hi, a question

[Oliver.Knoll at comit.ch]

On 2010-10-28 André André Somers wrote:

> ...
> So, by all means, go ahead and see if Quick fills your needs, but
> don't disgard widgets just because the focus for new developments is
> more with Quick than with widgets at the moment.

I haven't yet much digged into QML / Quick, but isn't that technology based on at least QWidget as base classes?

For me it sound more like "it is a different way to specify the UI (QML vs UI files) and add some more fancy widgets and effects (as apparently desired on mobile systems) like easier specification for animating UI objects (brrrrr, *shudder*...;)"

But then again, since for me it appears QML focuses mobile devices with simple screens (the applications I know on my iPhone typically have a few simple "dialogs" or "pages" with shiny effects), but I don't think it is suitable or even intended to be used for designing "desktop applications" with dockable widgets, menus, MDI interfaces with possibly complex dependencies when elements are to be enabled / disabled... or put it simple: for me "mobile apps" are rather static (I am not talking about "animation" and other shiny effects), whereas desktop apps can have a very "dynamic" UI, that is widgets are created/added/moved/destroyed depending on business logic.


And for me the QWidget / Designer / programmatic way is simply better suited once a GUI crosses that "critical threshold of complexity", especially when it comes to custom widgets, how would you implement a "hi-fi frequency indicator" (found in most music players) widget with QML, for example? Well, I don't know. But with the traditional QWidget approach that would be very straight-forward (custom widget, override the paint method, use QPainter, ...).

Summary: for me the QML / UI approach are simply two technologies to define user interfaces, the former making it way easier (probably, haven't tried yet ;) to define "flashy" (but simple) GUIs on mobile devices and most probably also very suitable to quickly implement "simple desktop widgets" such as weather / news / stock quote "apps", the later when it comes to implement "complex and dynamic GUIs".


And André is totally right when saying that the "widget approach" is very mature and stable, and from my point of view nothing much is missing; but then again, I am not among the people that complain that my "Qt app doesn't look like a REAL Cocoa app on Mac", for instance - I am totally happy that I can compile the same code - and nowadays even with the SAME TOOLS AND IDE :) - on different platforms, without having to cope with the same amount of toolkits (MFC, Cocoa, ...), and at the same time making my code much much more readable when using QList and co. (when comared to the corresponding STL containers, for example). /That/ is the key strength for me, and I am totally willing to pay the price of the "smallest common denominator" of all platforms (but keep in mind, no one is preventing me from using the native APIs as well, and mixing native Cocoa widgets with my Qt app, if I wanted to).

And by the way, did anyone notice that iPhoto, iTunes, iWhatever all come with their own custom GUI? I mean, iTunes doesn't look like a "typical Mac application" either! Now they even changed the positions of the "Maximise / Minimise / Close" buttons in the (non-existing!) application title (vertical vs horizontal) - Apple, HOW DARE YOU! ;) And yes, I like the look of Qt Creator as well, for me it looks "just as Cocoa-ish" on Mac as any other iApp with "custom GUI"...


Cheers, Oliver
--
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22