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.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
