Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Things to sort out before using Zest outside of Zyn #13

Open
3 of 14 tasks
pdesaulniers opened this issue Dec 29, 2018 · 1 comment
Open
3 of 14 tasks

Things to sort out before using Zest outside of Zyn #13

pdesaulniers opened this issue Dec 29, 2018 · 1 comment

Comments

@pdesaulniers
Copy link
Member

pdesaulniers commented Dec 29, 2018

  • There should be some way to set the QML files path at compile time. I think it has to be set in both mruby-zest-build/rebuild-fcache.rb and mruby-widget-lib/src/api.c
  • It should be possible to build zest as a static library, to make things simple for the users of the library.
  • It should not be necessary to add -ldl when linking statically
  • The UI should be self-contained. I think the fonts, QML files and other resources should be embedded in the binary.
  • Some letter case standards should be established for QML properties and callbacks.
  • Most of the widgets shipped with the library are Zyn-specific, or act in a Zyn-specific way (for instance, the Text widget is all-caps by default). There should be some cleaning up.
  • It should be possible to activate / deactivate hot-reloading without modifying zest's code. Perhaps a compiler flag or environment variable could be used?
  • There should be some way to build zest without building the standalone UI (the zest executable). Perhaps we could add a Makefile rule, so we can do make lib .
  • Two plugins that use different versions of Zest might enter in conflict with one another. Something might need to be done about how symbols are exported.
  • make clean in mruby-zest-build doesn't clean up everything. For instance, libzest.so remains.
  • I guess controlling plugin parameters using OSC doesn't make sense for all plugins. In my case, I'd like to use regular DPF parameters. Quoting from IRC:

<fundamental> per using OSC, it's fairly abstract to the individual widgets. Almost all of them just assume there's a $remote which translates string+value into some stateful update
if you instantiate a different $remote object at startup then switching to DPF parameters will be possible

  • Error messages refer to zyn-fusion. They should refer to "mruby-zest", or to a configurable plugin name.
  • It's a very minor issue, but I guess it would be nice if we could build the library in a single command, instead of make setup, make builddep and make

================

After all changes have been done:

  • Make sure Zyn itself builds and runs fine on Linux and Windows (and Mac?)
@pdesaulniers pdesaulniers self-assigned this Dec 29, 2018
@pdesaulniers
Copy link
Member Author

pdesaulniers commented Dec 29, 2018

In case it wasn't obvious, I think that the users of the library should not have to care about the contents of the zest submodule. They should (mostly) just call something like make -C mruby-zest-build, maybe with some environment variables, and link to the resulting library file.

@pdesaulniers pdesaulniers removed their assignment Mar 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant