wayfire: init at 0.4.0

[wucke13]

Motivation for this change

I would like to try this wm!

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

This is a re-worked version of #76759
@Thra11 @primeos

[wucke13]

@GrahamcOfBorg build wayfire wcm wf-shell

[alyssais]

Hello! I’ve been working on this for the past few days as well. I opened a PR with my implementation as #86606. My version also has support for installing Wayfire plugins, which by the looks of things this one lacks.

How do you want to go forward from here? Should we maybe look at each other’s PRs and see if we can combine efforts? I think it would make sense to use my PR as a base because of the plugin support.

Does wf-shell work in this PR? If so, how did you get around the hard-coded Wayfire prefix for plugins?

[wucke13]

@alyssais I'd love to join forces! As I'm not super confident of my skills I'm totally supporting the idea to go on with your PR. Please feel free to look at my PR.
wf-shell works, in terms of starting and displaying something. What I did was to point each components metadata directory to $out of the regarding nixpkg, and use a buildEnv of all these paths for the wcm utility to pick them up. AFAIK that does work, though I'm not aware of any functionality that wf-shell could miss by this attempt.

[wucke13]

closing in favor of #86606.