[Development] QAction-like API for QML

[Stephen Kelly]

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
> > 
> > <andre.poenitz at mathematik.tu-chemnitz.de> 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 <stephen.kelly at kdab.com> | 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121212/80a81961/attachment.sig>