5 ms·

Yep, that was one of the things that I got working early on. It's used a fair bit in the codebase, though it's not necessarily all that apparent if you don't kn

Yep, that was one of the things that I got working early on. It's used a fair bit in the codebase, though it's not necessarily all that apparent if you don't know where to look. As mentioned at https://github.com/mruby-zest/mruby-qml-spawn/blob/master/mrblib/database.rb#L61 https://github.com/mruby-zest/mruby-qml-spawn/blob/master/mr... the properties form a dependency graph, so the property bindings should stay up-to-date when you change dependent properties. This is one of the features of the overall framework which may be a bit under-tested at the moment. I've fixed a number of bugs in the system, though you certainly can get into odd edge cases when updating bindings during widget creation or destruction.

jcelerier 8y ago
> Yep, that was one of the things that I got working early on. It's used a fair bit in the codebase, though it's not necessarily all that apparent if you don't know where to look. hmmm... but what I don't see is stuff like `onColorChanged: doStuff(color)`. Basically, the event system ?
- fundamental 8y ago
  That's in there as well, though certainly not as refined as it is in Qt's QML. https://github.com/mruby-zest/mruby-zest/blob/master/qml/Valuator.qml#L18-L20 https://github.com/mruby-zest/mruby-zest/blob/master/qml/Val... shows one example of having a callback when a property is changed ( defined at https://github.com/mruby-zest/mruby-zest/blob/master/qml/Widget.qml#L15 https://github.com/mruby-zest/mruby-zest/blob/master/qml/Wid... ). Elsewhere in the codebase you'll see whenEvent style callbacks https://github.com/mruby-zest/mruby-zest/blob/master/qml/Valuator.qml#L11 https://github.com/mruby-zest/mruby-zest/blob/master/qml/Val... Most of the events, however, are handled through more traditional methods as that ended up being more comfortable when scaling to a larger program.
  - jcelerier 8y ago
    so... if I may ask : why not use Qt directly ?
    - fundamental 8y ago
      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.

jcelerier 8y ago

> Yep, that was one of the things that I got working early on. It's used a fair bit in the codebase, though it's not necessarily all that apparent if you don't know where to look. hmmm... but what I don't see is stuff like `onColorChanged: doStuff(color)`. Basically, the event system ?

fundamental 8y ago
That's in there as well, though certainly not as refined as it is in Qt's QML. https://github.com/mruby-zest/mruby-zest/blob/master/qml/Valuator.qml#L18-L20 https://github.com/mruby-zest/mruby-zest/blob/master/qml/Val... shows one example of having a callback when a property is changed ( defined at https://github.com/mruby-zest/mruby-zest/blob/master/qml/Widget.qml#L15 https://github.com/mruby-zest/mruby-zest/blob/master/qml/Wid... ). Elsewhere in the codebase you'll see whenEvent style callbacks https://github.com/mruby-zest/mruby-zest/blob/master/qml/Valuator.qml#L11 https://github.com/mruby-zest/mruby-zest/blob/master/qml/Val... Most of the events, however, are handled through more traditional methods as that ended up being more comfortable when scaling to a larger program.
- jcelerier 8y ago
  so... if I may ask : why not use Qt directly ?
  - fundamental 8y ago
    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.