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.poen...@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?
Andre'
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
