[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