[Development] QML Runtime

[Kevin Krammer]

On Tuesday, 2012-12-11, Knoll Lars wrote:
> 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:

> >>> 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 know, I was just pointing out that this wasn't an uncommon thing:

- it is not that obvious how a library on top of Qt can ensure that certain 
things are initialized after the Qt application is instantiated and how to 
make they are cleanup up before it is destructed
- subclassing the closest applicaton class and letting C++/the compiler ensure 
the correct order is

> > 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.

Right, I've seen this mostly used by framework developers, i.e. to ensure 
application developers using said frameworks cannot forget to initialize 
things that require an existing Qt application.

I guess using a subclass feels more natural to C++ developers then wrapping 
the application object construction in a macro that creates the Qt class' 
instance and then the initialization functions.

> 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.

I am just enumerating usages of "derive from Qt application classes" that I 
know of.
There are obviously negative consequences, however my guess would be that each 
instance of such an decision was a trade-off between pros and cons.

In the case of Cascades obviously not being dependent on QWidget (which 
QApplication is) outweighted drawbacks of using QCoreApplication.
(btw, I think QPainter can be used in a QCoreApplication context, e.g. drawing 
on QImage)

> It's a major showstopper for interoperability.
> 
> Please fix this when bringing things over to Qt 5.0, ideally before.

I am just a messenger [1], this is something RIM will have to look into.
There was obviously no way to do that in Qt4 and they most likely have other 
priorities right now than looking into rebasing to Qt5 (i.e. their major 
release coming up in a couple of weeks)

Cheers,
Kevin

[1] yes, yes, I know that the messenger always "gets it" ;)
-- 
** 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4712 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121211/3fb5c0ad/attachment.bin>