On Tuesday, 2012-12-11, Knoll Lars wrote: > 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:
> >>> 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 | [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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
