[Development] QML engine changes

[Bubke Marco]

Alan Alpert:
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.
Like a said in a other mail Qml is not that much declarative anymore. Actually I
think it burned to many man years here in the tooling team that it was not worth it.
If you want help the designer than make Qml more declarative again.

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.

Good to hear. So what is the plan for the "PropertyCache"?
What about a new better list interface(we have prototype here?
Maybe add signal compression instead of componentComplete.
Always think about that you need a reverse transformation for direct manipulation(visual to text).
Refactor the item code base.
  Why do we have parent and parentItem?
  Why do we mix the setParent and child list pattern?


This a short list of a much longer. ;-) I know many things are historical grown but if we not clean it up
we end in my opinion in a mess.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130626/410dc8fa/attachment.html>