[Development] QAction-like API for QML

André Pönitz andre.poenitz at mathematik.tu-chemnitz.de
Wed Dec 12 01:15:14 CET 2012

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.

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?


More information about the Development mailing list