[Development] QML Runtime

[Knoll Lars]

On Dec 11, 2012, at 12:15 PM, Kevin Krammer <kevin.krammer at kdab.com> wrote:

> On Tuesday, 2012-12-11, Knoll Lars wrote:
>> On Dec 11, 2012, at 10:47 AM, Kevin Krammer <kevin.krammer at kdab.com>
>> 
>> wrote:
>>> On Tuesday, 2012-12-11, Alan Alpert wrote:
> 
>>>> One big difference would be less flexibility about the invocation. As
>>>> a debugging tool qmlscene needs to be able to run smaller "units" of
>>>> QML to simplify debugging, that's why it just puts the top-level item
>>>> into a QQuickView. While that works for a lot of cases, it's not
>>>> really application behavior. qml should leave the window entirely up
>>>> to the application, meaning that the root item of any GUI application
>>>> would be a Window{} or similar. Note that this restriction would never
>>>> fly in qmlscene, because qmlscene needs to be able to run the
>>>> components of an application (like the inside of your Button.qml) to
>>>> debug and test them in isolation. This additionally gives the
>>>> advantage of no excess QQuickView when running a non-gui QML app
>>>> (which isn't really an issue for debugging, but sucks for deployment).
>>> 
>>> The main difficulty I see is how to determine which application class to
>>> instantiate.
>>> 
>>> If you load a non-UI QML file you might not want QGuiApplication to be
>>> instantiated.
>>> If you load a QtQuick1 file you'll need QApplication instantiated.
>> 
>> I'd assume that the runtime will be limited to Qt Quick 2.
> 
> Ah, pity :-/
> I was hoping for a generic QML runtime :)
> 
>>> If you load a BB10 Cascades application you'll need a
>>> bb::cascades::Application (which is a direct subclass of
>>> QCoreApplication) instantiated.
>> 
>> Yikes. Do you really need a different Application type for Cascades? That's
>> pretty bad IMO.
> 
> KDE has been doing that for years as well and I've seen it in customer 
> projects also.

Yes, and we always tried to get rid of that subclassing. It has quite some issues.
> 
> I guess subclassing and putting your init code into your constructor and your 
> shutdown code into your destructur is just the most obvious thing to do to the 
> common C++ developer.

Application developers can do that, but I rarely see a need for it to be honest.

But if you do this in frameworks, you're creating a *major* problem. Esp. in this case as you say you inherit from QCoreApplication. 

Tell me: How can I as an application developer use Cascades together with QPainter, or a Qt image loader? I can't, as I don't have a QApplication when using cascades, or I don't have a cascades app when using QApp. I can't use the OpenGL support from Qt neither. Basically all I can use is Qt Core, Network and that's it.

It's a major showstopper for interoperability.

Please fix this when bringing things over to Qt 5.0, ideally before.

Lars

> 
> It could also hint that qt_startup_hook and qAddPostRoutine are not as well 
> documented as they could be.
> 
> Cheers,
> Kevin
> -- 
> ** Qt Developer Conference: http://qtconference.kdab.com/ **
> 
> Kevin Krammer | kevin.krammer at kdab.com | Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development