Thomas & Tero: There is no way that I can make it to the contributors summit, but Thomas' message might be a important discussion pience when you arrive in Berlin.
Related to points 5,6,7 of Thomas' message Below: Is there a class diagram on the current code base? This would help newbies when trying to contribute to the refactoring strategy. The code supporting the QML, JS, and C++ must be layered and sensibly separated so that people can "opt-in" on various parts at compile/link time. When respected people like Thiago Macieira put forth the idea that there is no public API at the C++ level for Scene Graph and other QML locked in design pieces, that does not smell right. Where are the unit tests and test benches for the Qt code base? I have not seen a script that runs the test bench/unit tests for this large QT code base. Anybody have insights on that? Thanks, Marco On 4/28/2014 3:26 AM, Thiago Macieira wrote:> Em seg 28 abr 2014, às 08:33:23, Peter Kümmel escreveu: >>>> ATM the problem is to get started because I don't know much about the >>>> current architecture of the graphic stack. >>>> Any hints where to start for a first hello world? >>> >>> Maybe a translation from QML to a .ui file could be a first step? That >>> could work if you use QtWidgets in the QML file. >> I think we should start on top of the C/C++ part of current QMLv2 stack (if >> such a thing exists), with some handwritten widget code. Otherwise we have >> a QPainter based system which we already have with QWidgets. > > Forget about QPainter. > > Your first step, it seems to me, would be to add the necessary C++ public API > to QtQml so you can instantiate new items in the QML graph, then manipulate > their properties and bindings, as well as set new JavaScript code and > expressions. This simply replaces the QML parser, keeping all the benefits (and > problems) of the QML language. In particular, it does not extricate the JS > interpreter and engine. > > If you want to extricate the JS engine, you probably need to move the Scene > Graph classes out of QtQuick and into a module that depends only on QtGui, > bypassing the QtQml dependency. You'll need a way to insert generic items into > the graph. But, at this point, I question: why don't you just use an existing > OpenGL scene graph, like Ogle3D? > > Once you've got the base API, you can start thinking of writing widgets again, > the platform look and feel. If the QtQml dependency was maintained, it might > be possible to reuse the code from Qt Quick Components. If not, you'll > probably need to start from scratch. > On 4/29/2014 3:43 AM, Hartmann Thomas 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) > (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. > (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. > (4) Writing (more) QML(JS) static analyzers that can check/enforce a proper > strict mode for QML. > (5) Write refactoring tools that help to clean up existing code. > (6) Fix/cleanup existing demos and examples. > (7) Investigate how we can improve the interplay of QML and C++. Especially > in C++/backend heavy projects. > > As a second step the actual work has to be done of course. > > Kind Regards, > Thomas Hartmann > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
