[Development] QAction-like API for QML

[André Pönitz]

On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
> >
> > We also need to find out whether we can come up with something which
> > QtWidgets users can migrate to (the QWidget* in the QAction API is
> > quite niche, and not necessarily ideal API anyway). Possibly even
> > investigating whether QAction can be implemented in terms of a new
> > QGuiAction (?) API should be done. This can't be QML-only. There
> > needs to be C++ backing too.
> 
> Why can't this be QML-only? For the set of controls exposed in
> C++-only we have a C++-only Action API. When we add a set of controls
> exposed in QML-only we can have a QML-only Action API. We don't
> currently have a C++ UI something which QtWidget users can migrate to,
> we'd need to consider that first before trying to make this new API
> fit in with whatever that would be.

The missing _easy_ accessibility from C++ is _the_ pain point of the
whole QML story right now from a "medium sized application" point of
view. It would be really nice to get rid of that divide, not to pile
up more code that's not addressing both sides.

> I agree there should be a migration path for existing QAction users,
> and that we should support hybrid applications.

Right. And not as after-thought, but as first class citizen.

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

Andre'