On Wednesday, December 12, 2012 01:15:14 André Pönitz wrote: > On Tue, Dec 11, 2012 at 03:20:35PM -0800, Alan Alpert wrote: > > On Tue, Dec 11, 2012 at 2:57 PM, André Pönitz > > > > <[email protected]> wrote: > > > On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote: > > > ... > > > > > >> But there are other ways to support those use cases than adding a > > >> C++ API for the new Actions. My initial thought is something like a > > >> QActionBridge which can take a QAction or a QML Action to start with > > >> and then generates the other on the fly. It's not pretty, but it's a > > >> lot easier than abstracting out a QGuiAction and still allows you to > > >> get a reference to the other type if you need the interoperability. > > > > > > That's already an implementation detail. It does indeed not have to be > > > the same object, and it does not have to have _exactly_ the same > > > interface. But it has to be "highlevel", and one has to be able to > > > easily shift stance, i.e. move things from one side of the divide to > > > the other without much ado. This sort of implies that the interfaces, > > > down to property names, should be as close as possible - even if the > > > "using" languages are quite different. > > > > Yes, the interfaces should be as close as possible where appropriate. > > If the same thing is in both APIs, it should have the same name (and > > the same type where possible). But this does not mean that things in > > the QAction API should get any extra weighting when we design the QML > > Action API - it should only have the things that make sense for what > > QML does and how it will be used in QML. That would lead to > > compromising the QML API for porting concerns, which is a *terrible* > > choice for anyone writing a QML only application. It's a tough set of > > concerns to balance. > > I tend to disagree. Similiarity of APIs and familiarity with > concepts has quite some impact on porting. > > We can safely assume that most of the C++ API is not there just for > historical reason, but actually serves a purpose. There might be > exceptions, there might be a grey zone ("whatsThis" probably belong > there), but lacking any additional input I tend to believe that > what's there will be needed, also in QML, sooner or later.
Yes, we have consistently found this to be true. > > I am certainly ready to balance different needs of different users > of Qt. However, I find it quite hard to get a proper gut feeling > here. Maybe you know better: Who is currently doing or intents to do > pure QML applications? What is the expected share of those people in > two or three years? Thanks, -- Stephen Kelly <[email protected]> | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
