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

Switchable Dark Theme - Attempt 2 - Ongoing #726

Open
wants to merge 189 commits into
base: dev
Choose a base branch
from

Conversation

Laimonade
Copy link

Hey! :) Here's my second attempt at implementing a theme switching for Bela's IDE.

The approach here is to use SCSS @mixin and a map, allowing to define a colour variables for each of the themes.

The main logic and colour variable definitions are located in IDE/frontend-dev/scss/base.scss.

The idea is that we (only) move every specific element properties affected by the theme switching into a theme switching function (themify), performing the colour switch only on the relevant properties.

In each scss file containing elements which need to change colour, the relevant properties for the element is being moved at the top of the file inside of the themify function.

While this may not the cleanest of look, it allows 2 things:

  1. To only transpile into css the relevant properties, rather than having an entire duplicate of the code for each added theme.
  2. It gives a good base to support further themes. We only need to define the colour palettes and the rest of the infrastructure is already there.

There's still a bit of work to get this polished, but sharing now if people wants to start testing/using it before.

ps: You can discard the commit history before Feb 14, 2024. They shouldn't be in the commit history but not sure how to safely rewrite the history.

…e on Bela or Xenomai (well ... except for rt_fprintf()...), using std::thread and a std::mutex to manipulate the static constructor and properties. It could still use use some clarity around thread starting/stopping
…it is idempotent. Fixed a couple uninitialised values. Thanks valgrind
…r the ref count of neither will ever reach zero and destructors won't be called
…d of shared_ptr. See https://floating.io/2017/07/lambda-shared_ptr-memory-leak/ for reasoning. This was not an immediate issue, but worth avoiding future issues and it makes more sense to have the shared_ptr for _managing_ objects and the weak_ptr for _using_ them
…e server thread as it may become stale by the time the callback is executed. Instead, use the same weak_ptr approach used elsewhere. Also, use the same procedure where possible for sending binary or string.
…tly from the same thread as the callback. This allows to avoid allocation and copy as the send can be executed immediately instead of postponed in a lambda.
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

Successfully merging this pull request may close these issues.

3 participants