On Dec 11, 2012, at 12:15 PM, Kevin Krammer <[email protected]> wrote:
> On Tuesday, 2012-12-11, Knoll Lars wrote: >> On Dec 11, 2012, at 10:47 AM, Kevin Krammer <[email protected]> >> >> 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 | [email protected] | 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
