[Development] The place of QML

[Alan Alpert]

On Tue, 8 May 2012 20:08:38 ext Frank Hemer wrote:
> On Tuesday 08 May 2012 09:50:16 Peter Kuemmel wrote:
> > > > Now we suddenly have an easy to use, yet compulsory, Turing complete
> > > > language with essentially no support from off-the-shelf tools.
> > > 
> > > It's this "compulsory" part that I don't understand.
> > > The current situation is that if you don't want to use
> > > QML you don't use it.
> > 
> > Does "don't use it" mean I should use QWidgets?
> > But who wants to base a new project on a system which
> > is officially called something that sounds like "obsolete"
> > and "dead (no new features)"; I know the marketing calls this
> > only "done".
> 
> +1 with a big '!'
> 

If you have a better idea for the naming, I'd love to hear it. I'd call it 
"Sunshine" status, to evoke the imagery of an elder cat dozing the the sun, 
while still able to pounce the instant you approach. (This demonstrates that
 at least I need help coming up with good names ;) ).

> > ...
> > There is no smooth migration path for old-school Qt/C++ developers.
> 
> And I expect porting an application using QWidget & friens to become an qml
> application will cause at least equal pain as porting a qt3 application to
> qt4:-(
> 
> What I miss is the perspective for applications with long sales cycles
> (expect this to be 10 to 15 years). Could we see a chance for a smooth
> migration here ... like a qml replacement for QWidgets that do NOT imply a
> complete redesing?

Of course this was considered and a smooth migration path was developed. It 
has been documented here for some time: http://doc.qt.nokia.com/4.7/qml-
integration.html . Just because there is one doesn't mean that it's perfect 
(or even addresses your needs), but it will be most constructive to discuss it 
from this point, i.e. what's missing from the current migration path.

Unlike Qt3->Qt4, you can transition your UI elements over at your own pace, 
while still having a working intermediate product. Want to add some complex 
movement behaviors to your button, and think QML is the only solution (it's 
not, but it works well for this)? The button can become a QML based widget and 
fit into your existing UI. Maybe in five years you'll have replaced enough of 
your components with QML versions that it makes sense to drop the Widgets 
entirely and have a pure QML UI. But if your application was working fine 
before, you don't need a complete rewrite just to get it back to that level - 
and you still have options going forwards.

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks