Apparently X11 connections are a scarce resource, so it seems like a
good idea to not hang on to them for too long. Now this is sort of a
hybrid between COM-style memory management and a singleton.
This doesn't do anything useful yet, but it will print the names of
files that are being dragged and dropped on the Wine server (using the
OLE API) while the plugin is open.
This is needed as a workaround to support Waves VST3 plugins.
Right now does does not actually fix the issue because the arguments are
not updated in the subclasses. The next commit will fix this.
Seems weird to need this specifically so we can use the map overload
that creates a new instance when the key doesn't exist in the map. This
seems safer.
Letting `std::unique_ptr<T>` do the thinking for us makes a lot more
sense. We only need manual memory management for the error because we
need to pass a pointer to that pointer to xcb, but at least we have the
macro there so it still stays nice and readable.
We sadly cannot call `shared_library()` and `executable()` in these
subdirectories while still maintaining the same `build/` directory
structure, but this is still much cleaner. All of the other build
artifacts are now also gone from the root of `build/` so it's cleaner
overall.
We should only have the global options in the main meson.build file. It
made sense to keep everything in one place at one point, but an 800 line
build script becomes a bit difficult to skim through.
Since there isn't any public documentation on VST2, I saw JUCE and a
couple of other plugins and bridges use this, but they all redefined the
symbol to`main`.
Some interaction between JUCE and Wine would cause these cursors to be
hidden and then never shown again. This is of course more of a temporary
workaround until the issue gets solved within Wine.
At some point Doom Emacs broke on-save formatting with lsp-mode in
certain circumstances, and I made these changes with wgrep so apparently
they were never formatted.
Since we're using the XDG base dir package in yabridgectl we were
already doing this there, so it makes sense to also do this in yabridge
itself even though it's very unlikely the user will have this set.
These critical notifications don't expire under KDE Plasma, which would
mean that you'd get absolutely flooded with notifications you have to
manually close when something is wrong.
Robbert van der Helm