Certainly. - Embed-ability: Qt can be used to build a plugin interface, but when a plugin host (which may be implemented in some version of Qt) loads multiple

Certainly. - Embed-ability: Qt can be used to build a plugin interface, but when a plugin host (which may be implemented in some version of Qt) loads multiple different plugins (which can be different versions), then it's possible to see conflicts with the global data that Qt creates. These problems are fairly hard for typical users to report and debug. IIRC this can be worked around with static linkage, though that opens up a separate can of worms with respect to Qt. - Licensing: For the initial fundraiser the plan was to release binaries of the GUI for a fee with the full source being released at a later date. Doing this was simplified by using custom tools which were almost all under the MIT license. - Layout: QML tries to specify widget properties in terms of fixed sizes of the leaf nodes and then using bottom-up algorithms to place the parent widgets. The initial system in zest was to use a constraint layout framework to specify all system constraints without hard coding pixel sizes for any widget (other than the top level window as specified by the window manager). Incorporating this different approach did not mesh cleanly with QML's existing abstraction - Remote Data: QML works great if you're going to hook onto an app driven by Qt classes and the associated signal-slot system. Unfortunately Qt's approach does not work in a 'realtime-safe' manner. That is to say that if it was deeply integrated it could cause faults where the audio processing would be delayed generating audio glitches due to the timing being incorrect. When working with the OSC interface that existed on the target app (ZynAddSubFX), specifying parameter bindings felt rather unnatural and once again, didn't mesh with QML's expectation of how events should flow. - Javascript: Personally I'm not a fan of javascript, so developing in a different scripting language made the process faster in Ruby. - QML's C++ API: At the time I started work prototyping the GUI I needed to occasionally work with QML classes from a C++ perspective and sometimes extend/create new classes there. The C++ API was under-documented and the API felt clumsy. This is something that the Qt documentors have likely resolved at this point, but at the time it was a limitation. - QML's mental model: I have worked with Qt in the past, though not all that extensively. Qt and QML work very well if you stay within their own realm, but once you start going against the grain, you need to understand the internals fairly well. I found it difficult to learn about the internals and as such for a long development process which needed to have fast iterations, it seemed like a better fit to work with code that I was more familiar with even at the cost of needing to write it myself. In the end I think this was mostly justified by the relative small size of the 'framework' vs the size of the widget code within the overall Zyn-Fusion GUI written using mruby-zest. I know there were a few other issues at the time that I decided it would be more productive to build a framework along the way, though those are the items that come to mind first.