WayfireWM
A better support for out-of-tree plugins
As the number of external plugins slowly rises, it has become clear we need something like https://github.com/timgott/wfplug, but I think for a better UX it should be built-in into Wayfire itself, or at least an official tool. A vague plan that I am making up on the spot, feedback and suggestions are very welcome:
- Wayfire should start looking at a user-writable location by default (say
~/.local/lib/wayfireor whatever the standards say is a good place) - This folder should probably vary based on the installation prefix: this way we can have multiple installed Wayfire versions
- We'd need a bit more sophisticated script/tool which should support things like:
- Install/Update/Remove a new plugin from an URL for a specific wayfire installation
- Rebuild all plugins for a specific wayfire installation
- It would be also cool to enable/disable plugins from this tool, but it gets a bit hard: we do not know the exact config backend used by Wayfire ... So we are not quite certain which config file(s) to edit (or gsettings, or ...).
In any case, this will happen for Wayfire 0.9.0 at earliest.
cc @timgott
Wayfire should start looking at a user-writable location by default
It would be easier to manage if in that user plugins folder each plugin has its own installation folder, instead of one binary and one metadata folder for all plugins.
Rebuild all plugins for a specific wayfire installation
This means you need some integration with a build system (e.g. wfplug only works with meson). Maybe you could also make it easier for single cpp file plugins.
Install/Update/Remove
I had these in wfplug but removed it because it was just a wrapper around git and makes it more complicated if you e.g. need an older commit for compatibility.
Btw initially wfplug was meant to work similar to vim-plug for vim. But now I use wfplug more like a python virtualenv to test plugins (i.e. winshadows). That's also why it can generate a test config with only a specific plugin enabled. It has to be separate from my main install, otherwise it is too easy to crash the main session.
For the actual system I switched to NixOS by now and I have a simple Nix expression that simply compiles all subdirectories of a plugins folder and adds them to wayfire's path variables. This way my plugins also rebuild automatically for a new wayfire version. I could also have multiple wayfire versions but I don't need that (you might be overestimating the number of people that have multiple installations of wayfire at the same time).
Wayfire should start looking at a user-writable location by default
It would be easier to manage if in that user plugins folder each plugin has its own installation folder, instead of one binary and one metadata folder for all plugins.
What compiz did, was check $HOME/.compiz/ for folders named metadata and plugins first and load plugins from these paths before loading the ones in the system path.
This folder should probably vary based on the installation prefix: this way we can have multiple installed Wayfire versions
We can have a folder for each version:
~/.local/lib/wayfire/0.8/ for 0.8.x,
~/.local/lib/wayfire/0.9/ for 0.9.x and so on.
For git, we can use the WAYFIRE_API_ABI_VERSION as the folder name.
The same could be done for the metadata folder as well.
This folder should probably vary based on the installation prefix: this way we can have multiple installed Wayfire versions
We can have a folder for each version:
~/.local/lib/wayfire/0.8/for 0.8.x,~/.local/lib/wayfire/0.9/for 0.9.x and so on. For git, we can use theWAYFIRE_API_ABI_VERSIONas the folder name.The same could be done for the metadata folder as well.
This seems like a bit overkill. The WAYFIRE_API_ABI_VERSION version scheme that we currently have should prevent stale plugins from being loaded (though it doesn't help .xml files of course). I think ~/.wayfire/metadata/ for the xml files, ~/.wayfire/plugins/ for the libplugin.so files and maybe a ~/.wayfire/icons/ directory for wcm icons, should be enough.