i made the colors more bright @smokey @BluishHumility
1 Like
Noticable straight away, got to go offline for a bit, apparently I am a missing person, not sure how
sent pr of the updated scheme https://github.com/EndeavourOS-Community-Editions/sway/pull/96 now i go and be a chill guy and go to play cricket outside
1 Like
Nice, have a great game
i back
The colors look nice, although they are very similar to the colors already in there now! 
Here they are side by side, the current color scheme on the left and the new one on the right:
Those two new grey colors might be a little too dark (I’m worried text in those colors will be hard to read).
The background in the new PR is black now–we don’t want to keep a little purple in it?
#08052b is the current terminal background color.
#1c1824 was the shade in the first version of today’s PR. There is a hint of purple in there, but it’s subtle.
#141217 is the updated PR. Now it’s just black.
If there is purple left in there, personally I can’t see it.
Which color is this background?
Is that #1c1824? I think that’s the best one, it’s nice and dark but still has some purple to it.
Ok so i’ve reverted the change in the PR but i did not revert the colors
Hey guys, quick question regarding this github config for Sway. Is it designed to be edited, or are you supposed to run it as is? I’ve been working with it a little and when I reboot a lot of my settings get reverted, even though I’m changing the config files themselves. Thanks!
Hi @scrungle, welcome to the community. 
Can you describe more specifically what files you are changing? What is your method for changing the files?
1 Like
Been using EndeavourOS Sway for a few months now, been rock solid even on my wacky (and old) Intel-Nvidia hybrid laptop rig.
6 Likes
Thank you, @BluishHumility, for your work on keeping the community edition going. That’s often a thankless job, so wanted to let you know your work is appreciated.
Fast question for you: I’m currently running EndeavourOS + i3wm. Will sway-install.sh allow me to migrate to Sway? I understand that it’s not a 1:1 drop-in replacement and I’ll probably move my i3 config files over to .config/sway. If I have to do a bare-metal install instead, I can do that; I’m just getting a little fatigued with troubleshooting Hyprland setups and my own home-brew attempt at getting Sway running.
Thank you in advance for any pointers, wisdom, and insight you can toss my way. Cheers!
1 Like
Yes, it should set everything up for you and you can start using it right away without needing to manually configure it yourself. 
Be aware that having multiple DEs or WMs installed concurrently can cause issues in some cases. Sometimes different DEs will provide different (conflicting) solutions for the same thing, which can break stuff or cause odd behavior. If you run into any major problems right out of the gate, it might be better to nuke and pave.
I haven’t tested it extensively, but my understanding is a valid i3 config should work as-is in Sway. That is to say, you can drop your config into ~/.config/sway/config (or the ~/.config/sway/config.d/ directory) if you want to and it should Just WorkTM.
That said, probably it would be better to go through the configs that are in there first and decide what you want to keep and what you want to replace, so you don’t end up adding conflicting settings, or removing stuff you later wish you had kept.
1 Like
(singing) Regrets… I’ve had a few…. (with apologies to Frank Sinatra)
I’ll definitely check on the configs first before committing any egregious sins. My workflow is fairly basic, outside of Steam/ Heroic Games Launcher (adventures in their own right), so getting to a base config that Just Works 
Thank you for the quick reply, and I hope you have a great week!
–Mike
2 Likes
Hi, hopefully this is the right place for question: what kind of tiling logic does this sway edition use? I used sway just before I changed from arch (sway) to endeavourOS sway and I’m more than confident there’s some patch applied, that changes behaviour of master vs slave, horizontal vs vertical window moving etc? Neither this resembles anything I’ve used before: dwm or i3 (it’s been a while though.) Where’s the config / patch or even just plain source for the tiling logic so one can understand it better? Although back in the day, reading dwm’s c-code for manual patching was quite a stretch xD
PS like others, really enjoying endeavourOS sway edition, thanks for this cool distro!
This autotiling script is enabled by default in ~/.config/sway/config.d/autostart_applications: https://github.com/nwg-piotr/autotiling. Basically whenever you split a window, it defaults to splitting it along whichever window dimension (X/Y) is currently longer.
If you want, you can manually override the script on the fly with the keybindings in ~/.config/sway/config.d/default
# Set how the current window will be split
# Split the window vertically
bindsym $mod+v splitv
# Split the window horizontally
bindsym $mod+b splith
Or obviously you can just comment out or remove the exec autotiling line from the autostart_applications file if you don’t care for the way it splits your windows.
2 Likes
Thank you so much, BluishHumility! The relevant info and you write in suh a clear and concise manner.
2 Likes
I’ve been using Sway edition on my laptop for the last 6 months and just had to create an account to say keep up the good work. Moving to a tiling window manager, and in such a friction less manner as with the sway edition has been the best computing experience for me for decades.
Thank you.
3 Likes
@BluishHumility (may I call you Blue? 
): back again with some in-the-weeds Sway questions.
I’m chasing my tail trying to figure out how to set environment variables, specifically XDG_CURRENT_DESKTOP, such that X11 apps function with fewest problems. My use case is mainstream: the login manager starts the Sway session. I’m the only user and rarely drop down to a terminal at login, so don’t need to worry about pam or session seats.
From my admittedly uninformed reading, Sway inherits env vars from the process that starts it. In EOS, that appears to be greet/regreet → systemd → sway. I may be misunderstanding the sequence, so let me know if I’m getting this wrong.
In my own mangled adaptation of EOS Sway Edition, the way I currently pass variables is:
/etc/sway/config.d/10-systemd.conf:
exec "systemctl --user import-environment {,WAYLAND_}DISPLAY SWAYSOCK; systemctl --user start sway-session.target"
exec swaymsg -t subscribe '["shutdown"]' && systemctl --user stop sway-session.target
/etc/sway/config.d/50-systemd-user.conf:
//sway does not set DISPLAY/WAYLAND_DISPLAY in the systemd user environment
//See FS#63021
//Adapted from xorg's 50-systemd-user.sh, which achieves a similar goal.
//Upstream refuses to set XDG_CURRENT_DESKTOP so we have to.
exec systemctl --user set-environment XDG_CURRENT_DESKTOP=sway
exec systemctl --user import-environment DISPLAY \
SWAYSOCK \
WAYLAND_DISPLAY \
XDG_CURRENT_DESKTOP
exec hash dbus-update-activation-environment 2>/dev/null && \
dbus-update-activation-environment --systemd DISPLAY \
SWAYSOCK \
XDG_CURRENT_DESKTOP=sway \
WAYLAND_DISPLAY
While this seems to work, it doesn’t resemble what others have done. One user passes Sway variables via SDDM → systemd; I’m using SDDM, so I have a template I could use if that would be more effective/ elegant/ whatever. Only drawback is the last commit was three years ago. Unmaintained? Stable? Dunno.
A more programmatic approach appears to be uwsm which provides a number of Wayland compositor management capabilities, including Sway environment variables. Hyprland encourages this route, though H. is in so much flux I’m reluctant to adapt it to Sway wholesale.
I bring all this up because these three methods appear to be different than what is done in EOS Sway Edition. Perhaps I’m falling into the inveterate meddler trap of wanting to find out the optimal way to pass variables around. If it works, don’t fix it, right?
So I thought I’d ask and see what your thoughts are as Maintainer-In-Chief. I’m pretty happy with SDDM and Sway and just want to ensure I’m not dropping some vital env vars into /dev/null along the way. Cheers!
1 Like