[Development] QML engine changes

Alan Alpert 416365416c at gmail.com
Wed Jun 26 19:16:57 CEST 2013

On Wed, Jun 26, 2013 at 3:34 AM, Bubke Marco <Marco.Bubke at digia.com> wrote:
> Hi
> Alan Alpert:
>>> The staunch refusal to provide reasonable interfaces to the individual layers
>>> of the Qt Quick stack adds insult to injury, no matter how you put it.
>> Good thing we never did that. In fact, V4+V8->V4VM and
>> QtDeclarative->QtQml+QtQuick both promise to improve the interfaces
>> between individual aspects of the QtQuick stack.
> Do you really believe the C++ interface of Qml is well designed?

No, the C++ interface of QML is not ideal. My point is that it's
getting better, and you can help with that process.

>E.g. the list interface is only providing clear,
> so if we change the one element in the list, we have to clear the list and build it new. But append has only the
> [...]
>> Now maybe these don't solve your specific toolability concerns. But as
>> you haven't mentioned any specific concerns yet, I can only address
>> the problems I'm aware of. As I said, I'd like to hear your
>> toolability complaints about JS embedded in QML, in a separate thread.
>> It will almost certainly be easier to address them with the new JS
>> engine than the old one.
> My general concern is that Qml is designed from the text(vi) perspective, and not so much from the tool perspective.

That is correct. I would argue that this design choice is also
correct, because text is the best common format for human editing.
Everyone will already have a fully feature text editor that they are
comfortable with, and then they can use all of the features
immediately. In contrast, building a specific tool requires that tool
to be built, then people to get it, learn it, and adapt to it. The
specific tool is better in the long run (for most usage) but we can't
wait for it to finish.

Of course, that attitude does make it even harder to write the tool
and so it takes even longer for it to finish. That is an issue we
would like to mitigate where possible.

> One example for it:
> [...]
> Sorry for the rant, but I really believe we need a more global approach(development story) to Qml, a wider scope
> and if we are not sure we should ask the other guy what they think about the change.

Better yet, join the discussion if you're interested. As an open
project we do need to get better about having the design discussions
in the open, and joining those discussions from the tooling side is
encouraged. Then you aren't relying on other developers to be 'unsure'
about something.

Alan Alpert

More information about the Development mailing list