[Development] QAction-like API for QML
Thomas Hartmann
Thomas.Hartmann at digia.com
Thu Dec 20 12:07:57 CET 2012
Am 18/12/2012 00:53, schrieb André Pönitz:
> But back to the original issue, within the intended context: The
> point is that with the existence of arbitrary imperative blobs with
> arbitrary side effects and full access to global data a language's
> claim to be "declarative" is hard to defend - both in theory, and in
> practice.
True.
Once you have any imperative JS code or any binding to a function with
side effects in QML it is clearly not declarative anymore.
From the tooling side it is important to emphasize that there is a
declarative sub lanugage "hidden" in QML that we can provide tooling
for. But complete QML, including full imperative JS, is not declarative
at all.
Actually the next version of Qt Quick Designer will explcitly warn about
imperative code it finds.
Every feature properly supported by visual tooling has to be purely
declarative.
From the tooling side, not having a strict distincion between
declarative and non declarative QML, is problematic at least.
We still play with the idea to introduce something like a .qmlui
format, which strictly enforces purely declarative QML.
The reason we did not so (yet), is that in about 90% of the cases the
imperative code is not relevant for the visual design and can be savely
ignored by the tool. (e. g. the handler of a button clicked signal).
Having that in mind I strongly propose a purely declarative api for
actions in QML, if we want to support them in the tooling.
Having addiontal imperative APIs is not a show stopper, but we will not
support them.
Also it has to be 100% that because QML is so much more verbose than .ui
files and it includes a turing complete language (JS) there will always
be QML files that do not benefit from any visual tooling.
Which is not a problem in pratice at all.
Kind Regards,
Thomas Hartmann
More information about the Development
mailing list