[Development] QML Runtime

Alan Alpert 416365416c at gmail.com
Tue Jan 8 19:03:26 CET 2013


On Tue, Jan 8, 2013 at 9:32 AM, Mohamed Fawzi <Fawzi.Mohamed at digia.com> wrote:
> 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.

We've limited divergence by putting the main functionality of the qml
tool in QQmlApplicationEngine. The idea is that the qml tool remains a
thin wrapper around that, and a development tool could be a thicker
one. But the core functionality is already abstracted and shared (also
shared with all custom C++ QML applications)

> 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).

We already have TWO plugin based approaches.

1) QML module plugins
2) I'd call Qt Creator a plugin-based approach for developing Qt applications ;)

Would either of those work for layering more development functionality
on the one binary?

And just to clarify things I assume the anti-divergence point is to
move to one binary instead of the many different ones we have
(although another interpretation is to not add this one but try to
extend the various existing ones as they are?). If we removed all
divergence by bundling everything into one binary, what would that
binary be?

--
Alan Alpert



More information about the Development mailing list