[Development] QAction-like API for QML

[André Pönitz]

On Mon, Dec 17, 2012 at 08:33:47AM -0800, Alan Alpert wrote:
> On Sun, Dec 16, 2012 at 5:12 PM, André Pönitz
> <andre.poenitz at mathematik.tu-chemnitz.de> wrote:
> > On Sun, Dec 16, 2012 at 03:42:59PM -0800, Alan Alpert wrote:
> >> On Sun, Dec 16, 2012 at 1:12 PM, Bache-Wiig Jens
> >> <Jens.Bache-Wiig at digia.com> wrote:
> >> >> If you create the actions in C++, you'd still have to repeat
> >> >> each and every one in QML, unless we provide a way to iterate
> >> >> over the ones that should be in a menu, or a toolbar.
> >> >
> >> > How about having ToolBar.addAction() for convenience? It is
> >> > exactly what we do for widgets.
> >>
> >> Widgets is a toolkit for an imperative language. Looping over
> >> lists and adding things individually is acceptable there. In a
> >> declarative language it is really not the right way to go.
> >
> > You make that sound like there was a conceptual difference between
> > .ui plus C++ on one side, and some json-ish structure plus JS on
> > the other side.
> 
> The conceptual differences are: 1) Bindings. Strict json + JS would
> be a lot more similar to .ui plus C++ because it doesn't have
> bindings.  2) User approach. .ui files were never meant to be edited
> by hand.  .qml files are always meant to be edited by hand (even
> when the visual designer was around, that was more an aid than the
> primary method of editing QML).

I was aiming at the seemingly implied conceptual difference in the
style - imperative vs declarative - between the approaches, which does
not really exist. My statement was probably missing a "regarding
'declarativeness'" or whatever makes that a proper English sentence
and the context crystal clear.

Anyway, I don't think 2) is a valid reason, no matter whether the
"regarding 'declarativeness'" is there or not. Translating .ui into
"json-ish" and back can be a purely mechanical and lossless task
doable without introducing imperative blobs. "Making the .ui format
more accessible to manual editing" would be rather straightforward,
if that was a goal.

Somewhat similar for 1). I haven't given it a shot, but I find it hard
to believe that a "binding evaluation machine" within_ the existing
framework should be ugly, let alone impossible. We are approaching a
time where we can use C++ lambdas, and lacking them, we by now have
some practice to convert source markup into real code. Putting some
binding code into normal string literal and running them through a
simple(!) interpreter at runtime should not be completely off the mark
either. Lots of possible approaches. In any case, I fail to see the
intrisic complexity of the problem that justifies the effort we see
spent on the "language side" of the issue, both for the implementors,
and for the users.

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.

I personally find the practical implications for the tooling side of
things particularly irritating as all benefits of a pure declarative
approach are rendered void. Moreover, the chosen implementation as
"json-ish"-plus-JS hybrid exposes us to all the downsides of a domain
specific language. No standard to tell what's right and wrong, no
existing tooling to re-use, no shoulders of giants to stand on etc.
At the end of the day I see a lot of pain for no gain.

Why are we doing that?

Andre'