I understand the attractiveness of small tools, especially if one wants to deploy bundling that tool. Still I am with Kay on this, I see the probability of diverging, and thus having more bugs, that happen only in one tool and not the other as bigger. Even having a single binary does not remove all those bugs, but I think it helps in keeping things under control.
To adress both concerns one could think about a plugin based approach. It might be unfeasible, but if doable I would see it as the best solution (activable callbacks, plugin that can register stuff and so on). Fawzi ________________________________________ From: [email protected] [[email protected]] on behalf of Alan Alpert [[email protected]] Sent: Tuesday, January 08, 2013 5:43 PM To: Koehne Kai Cc: Sorvig Morten; [email protected] Subject: Re: [Development] QML Runtime On Tue, Jan 8, 2013 at 4:56 AM, Koehne Kai <[email protected]> wrote: >> -----Original Message----- >> From: Alan Alpert [mailto:[email protected]] >> Sent: Monday, December 24, 2012 8:23 AM >> To: Koehne Kai >> Cc: Sorvig Morten; [email protected] >> Subject: Re: [Development] QML Runtime >> >> For those interested in the matter, the discussion has now moved to >> codereview. >> >> https://codereview.qt-project.org/#change,43539 adds the >> QQmlApplicationEngine >> https://codereview.qt-project.org/#change,43540 adds the qml tool using it > > Sorry for the late response. Anyway, I feel somewhat uncomfortable adding > yet another tool. I see that the requirements for a runtime vs a previewer / > debugging tool are different, but can't we achieve this nevertheless in one > binary ? After all you also use the same webbrowser both for development of > HTML and browsing. Technically you could achieve the same thing with one big binary instead of several smaller ones. I prefer the several smaller ones approach, because it's simpler and more efficient. You can technically use the runtime for development in the same way you use a webbrowser, but for serious QML development I think the answer will always be Qt Creator. Note that if the qml binary works sufficiently for basic development as a more generic runtime, qmlscene and qmlviewer could theoretically move to Qt Creator (or go away, depending on what Qt Creator wants). As specialized development tools they should fit into the Qt Creator story properly. An example would be if we had a separate development tool for running QML it would be nice to integrate the performance profiler - like QtCreator has already done. -- Alan Alpert _______________________________________________ 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
