Change all sway references to swayfx

[notpeelz]

Notes:

• I changed as little as possible to minimize merge conflicts with upstream
• SWAYSOCK wasn't renamed because it would break e.g python scripts using i3ipc
• Commands such as swaynag_command are unchanged
• The project description in the manpage (sway(1)) was updated, hopefully you will find it adequate :)
• CONTRIBUTING.md was updated to reflect the direction of this project
• Contributor and author mentions in manpages/documentation were updated

Packages:

AUR: I've tested the AUR packages and use the PKGBUILD on my own machine as a daily driver. I have sway installed side-by-side with swayfx with no conflicts.

RPM: I'm not familiar with RPM. I've updated the spec file to the best of my ability. Untested.

Nix: Unchanged. I don't have a Nix/NixOS environment to test with.

Fixes #191

[notpeelz]

I'm thinking maybe it would be a good idea to rename SWAYSOCK to SWAYFXSOCK after all:

1. if a program calls sway --get-socketpath, it returns SwayFX's socket path, which could be considered incorrect, as sway isn't running.
2. tools that integrate with sway might want to check if the user is running SwayFX (and not sway). XDG_CURRENT_DESKTOP is the preferred way to check what compositor the user is running; however, sway doesn't set that environment variable, which becomes the user's responsibility to set it to the correct value (and therefore might be unreliable). Renaming it to SWAYFXSOCK gives programs a more reliable way to determine the "flavor" of sway in use.
3. SwayFX's IPC might not remain 100% compatible with sway's in the long run
4. it would allow scenarios where sway is run as a nested compositor on top of SwayFX, without clobbering the environment variable. I've accidentally run sway with the default config at least a couple times... On Arch Linux, the default config sources 50-systemd-user.conf, which updates SWAYSOCK in the systemd environment block, breaking all scripts that make use of swaymsg.
5. SWAYSOCK is pretty much the only thing remaining that could result in accidental "crosstalk" between compositors.

[notpeelz]

Marking as draft until the review is done.

Edit: nevermind, draft PRs can't be reviewed. I thought it just blocked merging lol

pokes @WillPower3309

[mochaaP]

Could we provide distro packages like sway-is-swayfx or swayfx-sway to provide /usr/bin/sway{,msg,nag,bar}? This could break some packages depending on the binaries or the sway package name.

[notpeelz]

I've squashed the fixup commits and added a new subpackage to alias swayfx's versions of sway{,bar,msg,nag}. I also tried modifying the Fedora spec file, but rpkg was giving me strange errors (tested in a Fedora 39 VM). Also, rpkg-util is no longer maintained/developed, so we should probably use some other packaging tool (such as fedpkg, dist-git or tito).

[mochaaP]

We usually use fedpkg for day-to-day packaging works. https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/#common_fedpkg_commands Hope this helps!

[notpeelz]

Thanks! I'll look into it.

BTW, if we go forward with the SWAYSOCK rename, the compat packages could ship a config file to alias the environment variable, e.g.

/etc/swayfx/config.d/50-swaysock-compat.conf:

exec systemctl --user set-environment \
  SWAYSOCK="$SWAYFXSOCK" \
  I3SOCK="$SWAYFXSOCK"

[notpeelz]

I rebased against the latest changes and got rid of most packaging-related commits. This should make it easier to review. I plan on submitting the rest of the changes in separate PR(s).

[WillPower3309]

Hey peelz! Thanks a ton for all the work here and apologies on my end for the delays. I think it's a good call to save the swaysock change for a separate PR as I'd like to have more of a conversation there on if this is something we'd want

[WillPower3309]

Just a minor comment and a question

[werdahias]

Allowing side-by-side installing (where no binaries are named the same) with sway would also really ease packaging for debian and in consequence, ubuntu