On Tue, Apr 29, 2014 at 12:43 AM, Hartmann Thomas <[email protected]> wrote: > Hi, > > On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz <[email protected]> wrote: >> I think at least three modifications are inavoidable: For one, things that >> could be written in a declarative way but which currently are only possible >> using JavaScript, a declarative way should be added. Second, it should be >> stressed in the documentation (including the examples), that using >> inline imperative code is naughty. This can be supported by e.g. the QML >> Designer refusing to operate on such files. People can still do that, but >> would be on their own. And finally, and that's also acting as a proof that >> the first two items actually have been done, the JavaScript dependency >> should be _optional_. > > Can we turn this into action points we _all_ agree on? > My personal favorites are (In no strict order): > > (1) Identify non declarative parts of Qt Quick and add declarative API (e.g. > setting states)
Agreed. This is my personal favorite ;) . > (2) Document that inline Java Script and mixing declarative and imperative > code in one file has its pitfalls in big projects and creates issues for > tooling. Explain the difference between pure declarative QML and QMLJS and > the impact on tooling. Agreed. While I think that mixing declarative and imperative code in one file has it's advantages in small projects, there should be a clear line between "pure declarative and toolable" vs "you're on your own". I'd like to see something like ".pragma declarative" which defines this line, such that if you add ".pragma declarative" un-toolable JS blocks or bindings become compile errors. > (3) Document that accessing ids from other .qml files without any interface > (just relying on the fact that they are in the context) creates hard to > maintain QML code. Agreed (honestly, it should already be there, I guess https://bugreports.qt-project.org/browse/QTBUG-20453 was never finished...). Again, we have some rough plans for a ".pragma strict". Which should ban this. > (4) Writing (more) QML(JS) static analyzers that can check/enforce a proper > strict mode for QML. Agreed, see ".pragma strict" comments. Speaking of which, this idea has been around for a while: https://bugreports.qt-project.org/browse/QTBUG-30069 > (5) Write refactoring tools that help to clean up existing code. Kinda agree. If we have the two .pragma's mentioned then this is purely a convenience step (because they can find all cases by using the .pragmas). It's probably not worth writing a full refactoring tool that can turn anything into a .pragma declarative/strict file. Just do what's convenient to tool and users can do the rest (if they wish). > (6) Fix/cleanup existing demos and examples. Agreed. This is probably a good step to do in conjunction with (1), so as to ensure that the added declarative APIs make sense. In most cases, the added declarative APIs should make more sense even for the primitive (non-tool) users and we can verify it here. > (7) Investigate how we can improve the interplay of QML and C++. Especially > in C++/backend heavy projects. Agreed. Known issues: https://bugreports.qt-project.org/browse/QTBUG-33233 https://bugreports.qt-project.org/browse/QTBUG-23052 https://bugreports.qt-project.org/browse/QTBUG-19212 Can't find task: More powerful QJSEngine API so that C++ value-type-like objects can be exposed as JS objects when you want more control at the cost of convenience https://bugreports.qt-project.org/browse/QTBUG-21844 (in conjunction with above) But there's probably some additional research to be done too. > As a second step the actual work has to be done of course. Yeah, that's always the biggest issue... Every time these discussions come up there's no major theoretical point of contention. It's just that the work still hasn't been done and we all like arguing. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
