Change all sway references to swayfx #257

notpeelz · 2023-12-26T15:58:05Z

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 · 2023-12-27T17:29:34Z

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

if a program calls sway --get-socketpath, it returns SwayFX's socket path, which could be considered incorrect, as sway isn't running.
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.
SwayFX's IPC might not remain 100% compatible with sway's in the long run
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.
SWAYSOCK is pretty much the only thing remaining that could result in accidental "crosstalk" between compositors.

ErikReider

Some nits, hopefully the "same here" comments are in the correct order.

Kudos for rewriting some of the texts too! :)

ErikReider · 2023-12-30T19:20:20Z

build-scripts/aur-git/50-systemd-user.conf

@@ -12,5 +12,5 @@ exec systemctl --user import-environment DISPLAY \
 exec hash dbus-update-activation-environment 2>/dev/null && \
     dbus-update-activation-environment --systemd DISPLAY \
                                                  SWAYSOCK \
-                                                  XDG_CURRENT_DESKTOP=sway \
+                                                  XDG_CURRENT_DESKTOP="swayfx:sway:wlroots" \


Does having it colon separated actually work? Will it be detected by the portals conf?

Portals work fine on my end. If I initiate screen sharing from Firefox/Discord, it calls xdp-wlr. Everything else calls xdp-gtk (as defined in swayfx-portals.conf).

The colon-separated list is used by NotShowIn=/OnlyShowIn= in .desktop files: https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

If $XDG_CURRENT_DESKTOP is set then it contains a colon-separated list of strings. In order, each string is considered. If a matching entry is found in OnlyShowIn then the desktop file is shown. If an entry is found in NotShowIn then the desktop file is not shown. If none of the strings match then the default action is taken (as above).
$XDG_CURRENT_DESKTOP should have been set by the login manager, according to the value of the DesktopNames found in the session file. The entry in the session file has multiple values separated in the usual way: with a semicolon.

ErikReider · 2023-12-30T19:23:06Z

completions/bash/sway


-_sway()
+_swayfx()


Shouldn't these file names be renamed to swayfx? (all completion files)

I didn't rename any files to avoid creating unnecessary conflicts when pulling from upstream.
The files get renamed by meson at install time (see the changes in meson.build).
e.g completions/bash/sway gets deployed to /usr/share/bash-completion/completions/swayfx

completions/zsh/_sway

completions/zsh/_swaymsg

ErikReider · 2023-12-30T19:27:38Z

meson.build

+	swayfx_zsh_files = [
+		'_swayfx',
+		'_swayfxmsg',
+	]


Should this be here? Shouldn't zsh_files also be removed then?

swayfx_zsh_files is passed to install_data() a couple lines below. It's used for renaming purposes.

meson.build

sway/sway.1.scd

notpeelz · 2024-01-13T20:53:43Z

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 · 2024-01-17T09:54:31Z

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 · 2024-01-18T05:21:22Z

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 · 2024-01-18T13:22:09Z

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 · 2024-01-18T16:44:36Z

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 · 2024-02-15T15:42:19Z

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).

Breaking changes: - path: /etc/sway -> /etc/swayfx - path: /etc/swaynag -> /etc/swayfxnag - path: $XDG_CONFIG_HOME/sway -> $XDG_CONFIG_HOME/swayfx - path: $XDG_CONFIG_HOME/swaynag -> $XDG_CONFIG_HOME/swayfxnag - bin: sway -> swayfx - bin: swaymsg -> swayfxmsg - bin: swaynag -> swayfxnag - bin: swaybar -> swayfxbar Other changes: - meson option: swaybar -> swayfxbar - meson option: swaynag -> swayfxnag - XDG_CURRENT_DESKTOP: sway -> swayfx:sway

WillPower3309 · 2024-02-27T06:31:28Z

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 · 2024-02-27T06:32:46Z

README.md

-    - The current layer namespaces can be shown with `swaymsg -r -t get_outputs | jq '.[0].layer_shell_surfaces | .[] | .namespace'`
+    - The current layer namespaces can be shown with `swayfxmsg -r -t get_outputs | jq '.[0].layer_shell_surfaces | .[] | .namespace'`
    - Example: `layer_effects "waybar" blur enable; shadows enable; corner_radius 6`
      - Note: If an application uses gtk, its namespace is likely to be "gtk-layer-shell"
-    - SwayIPC Example: `swaymsg "layer_effects 'waybar' 'blur enable; shadows enable; corner_radius 6'"`
+    - SwayIPC Example: `swayfxmsg "layer_effects 'waybar' 'blur enable; shadows enable; corner_radius 6'"`


not sure how I feel about this one. Do you mind if we save the IPC changes for a follow-up PR? I think we need some more discussion there

Same here. I have scripts using the Sway IPC that i can now use in both Sway and SwayFX. The change would mean that i need to change all of them to be only SwayFX compatible. However, if I do want to run Sway instead (development etc) none of my scripts will work and I feel like those negatives are gonna outweigh the (possible) positives.

That defeats the whole point of #191.

There's two options:

we close this PR and keep SwayFX as a drop-in replacement for Sway

we go forward with the rename and make SwayFX independent, allowing it to be installed side-by-side with Sway

If we go forward with the rename, we can't have any packaged files conflicting with upstream.
Splitting up the changes into more PRs is only going to make it harder to complete the migration.

When it comes to "IPC compatibility", you can temporarily symlink the binaries, e.g.: ~/.local/bin/swaymsg -> /usr/bin/swayfxmsg

As I stated in my earlier comments, I had started working on the packaging side of things. Before the rebase, I had a commit (a06a4ab) that added a subpackage to create those symlinks. This would alleviate the friction when switching between SwayFX and Sway.

From what I understand both @RicArch97 and @WillPower3309 use Nix/NixOS, in which case you can create those symlinks in the postInstall step, i.e:

postInstall = (old.postInstall or "") + '' for f in "" msg nag bar; do ln -sT "swayfx$f" "$out/bin/sway$f" done '';

WillPower3309 · 2024-02-27T06:34:33Z

build-scripts/aur-git/50-systemd-user.conf

@@ -12,5 +12,5 @@ exec systemctl --user import-environment DISPLAY \
 exec hash dbus-update-activation-environment 2>/dev/null && \
     dbus-update-activation-environment --systemd DISPLAY \
                                                  SWAYSOCK \
-                                                  XDG_CURRENT_DESKTOP=sway \
+                                                  XDG_CURRENT_DESKTOP="swayfx:sway" \


Q: does this env var play well with having multiple values?

Yep. Erik asked the same question (see previous review).

WillPower3309 · 2024-02-27T06:38:50Z

Just a minor comment and a question

werdahias · 2024-05-23T16:50:12Z

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

ErikReider requested changes Dec 30, 2023

View reviewed changes

notpeelz marked this pull request as draft January 13, 2024 20:53

notpeelz marked this pull request as ready for review January 13, 2024 20:55

notpeelz force-pushed the rename-sway-to-swayfx branch from 024aa4b to a06a4ab Compare January 18, 2024 05:13

notpeelz marked this pull request as draft January 24, 2024 02:40

notpeelz force-pushed the rename-sway-to-swayfx branch from a06a4ab to 7c6545f Compare February 15, 2024 15:41

notpeelz marked this pull request as ready for review February 15, 2024 15:44

notpeelz requested a review from ErikReider February 15, 2024 15:46

notpeelz force-pushed the rename-sway-to-swayfx branch from 7c6545f to 5c87702 Compare February 23, 2024 20:26

WillPower3309 reviewed Feb 27, 2024

View reviewed changes

ozwaldorf mentioned this pull request Apr 5, 2024

Overhaul nix flake #279

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Change all sway references to swayfx #257

Change all sway references to swayfx #257

notpeelz commented Dec 26, 2023 •

edited

notpeelz commented Dec 27, 2023 •

edited

ErikReider left a comment

ErikReider Dec 30, 2023

notpeelz Dec 30, 2023

ErikReider Dec 30, 2023

notpeelz Dec 30, 2023

ErikReider Dec 30, 2023

notpeelz Dec 30, 2023

notpeelz commented Jan 13, 2024 •

edited

mochaaP commented Jan 17, 2024

notpeelz commented Jan 18, 2024 •

edited

mochaaP commented Jan 18, 2024

notpeelz commented Jan 18, 2024

notpeelz commented Feb 15, 2024 •

edited

WillPower3309 commented Feb 27, 2024

WillPower3309 Feb 27, 2024

RicArch97 Feb 27, 2024

notpeelz Feb 27, 2024

WillPower3309 Feb 27, 2024

notpeelz Feb 27, 2024

WillPower3309 commented Feb 27, 2024

werdahias commented May 23, 2024


		_sway()
		_swayfx()

Change all sway references to swayfx #257

Are you sure you want to change the base?

Change all sway references to swayfx #257

Conversation

notpeelz commented Dec 26, 2023 • edited

Notes:

Packages:

notpeelz commented Dec 27, 2023 • edited

ErikReider left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

notpeelz commented Jan 13, 2024 • edited

mochaaP commented Jan 17, 2024

notpeelz commented Jan 18, 2024 • edited

mochaaP commented Jan 18, 2024

notpeelz commented Jan 18, 2024

notpeelz commented Feb 15, 2024 • edited

WillPower3309 commented Feb 27, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WillPower3309 commented Feb 27, 2024

werdahias commented May 23, 2024

notpeelz commented Dec 26, 2023 •

edited

notpeelz commented Dec 27, 2023 •

edited

notpeelz commented Jan 13, 2024 •

edited

notpeelz commented Jan 18, 2024 •

edited

notpeelz commented Feb 15, 2024 •

edited