Hi Prot, I'm a happy user of swaywm and emacs pgtk. Also happy using
your "not distribution". I'm actually comfortable using your opinated
config system-wide.
I see your swaywm is feature primitive vs other wm in your dotfiles. So
I was thinking making an effort to migrate some features to sway. Have
sense to make a patch to merge upstream. Or are you not interested at
all?
Regards!
--
Juanjo Presa
https://nadanix.com
> From: Juanjo Presa <juanjo.presa@nadanix.com>> Date: Fri, 22 Apr 2022 15:10:24 +0200>> Hi Prot, I'm a happy user of swaywm and emacs pgtk. Also happy using> your "not distribution". I'm actually comfortable using your opinated> config system-wide.
Good to know!
> I see your swaywm is feature primitive vs other wm in your dotfiles. So> I was thinking making an effort to migrate some features to sway. Have> sense to make a patch to merge upstream. Or are you not interested at> all?
It is the most underdeveloped of the three tiling window managers I have
configurations for. I basically set it up to test a bug with the Emacs
pgtk build that was affecting my modus-themes. Once it was fixed, I
switched back to bspwm (and sometimes herbstluftwm).
At any rate, I like sway and am happy to improve the configs for it.
Right now, the one area I am aware that needs immediate attention is the
system panel. I don't like the fact that I cannot change its background
to a light one when I use the light theme. Also, I am not sure it is a
good idea to rely on the i3blocks package.
What do you think is missing? What would you like to change?
--
Protesilaos Stavrou
https://protesilaos.com
> From: Protesilaos Stavrou <info@protesilaos.com>> Date: Fri, 22 Apr 2022 20:59:17 +0300
Hi, thanks for your fast reply.
>> From: Juanjo Presa <juanjo.presa@nadanix.com>>> Date: Fri, 22 Apr 2022 15:10:24 +0200>>>> Hi Prot, I'm a happy user of swaywm and emacs pgtk. Also happy using>> your "not distribution". I'm actually comfortable using your opinated>> config system-wide.>> Good to know!>>> I see your swaywm is feature primitive vs other wm in your dotfiles. So>> I was thinking making an effort to migrate some features to sway. Have>> sense to make a patch to merge upstream. Or are you not interested at>> all?>> It is the most underdeveloped of the three tiling window managers I have> configurations for. I basically set it up to test a bug with the Emacs> pgtk build that was affecting my modus-themes. Once it was fixed, I> switched back to bspwm (and sometimes herbstluftwm).>> At any rate, I like sway and am happy to improve the configs for it.> Right now, the one area I am aware that needs immediate attention is the> system panel. I don't like the fact that I cannot change its background> to a light one when I use the light theme. Also, I am not sure it is a> good idea to rely on the i3blocks package.
I can change sway bar colours using `swaymsg bar 0 colors background
'#505050'`. Are you referring to this? Other option is change to
`waybar` but I prefer keep using default bar.
i3blocks/i3status has advantage of being wide standard. Maybe the point
is levereage them also in your polybar setup.
> What do you think is missing? What would you like to change?
I was also thinking in test `swhkd` [1] a Rust drop-in replacement for
`sxhkd` that works with a client-server model and works in X11, Wayland
or TTY. Is in early development. This way different WM key hotkey could
merge into one solution.
[1]: https://github.com/waycrate/swhkd
--
Juanjo Presa
https://nadanix.com
> From: Juanjo Presa <juanjo.presa@nadanix.com>> Date: Sat, 23 Apr 2022 11:37:38 +0200>>> From: Protesilaos Stavrou <info@protesilaos.com>>> Date: Fri, 22 Apr 2022 20:59:17 +0300>> Hi, thanks for your fast reply.
You're welcome!
> [... 25 lines elided]>> I can change sway bar colours using `swaymsg bar 0 colors background> '#505050'`. Are you referring to this? Other option is change to> `waybar` but I prefer keep using default bar.
Okay, I did not know that (again, I have not experimented enough with
sway). Then we can update the 'delight' script to account for this as
well.
Do you want to do it? If not, I will start using sway as my daily
driver and make those changes myself. Then you can just pull them in
your local setup.
I also prefer the default bar over waybar, especially since I don't want
to do anything fancy with it.
> i3blocks/i3status has advantage of being wide standard. Maybe the point> is levereage them also in your polybar setup.
The reason I am not sure about it pertains to Wayland. I believe they
are display-protocol-agnostic and seem to work perfectly fine in that
regard, but I have not double-checked. If you think this part is fine,
then I am good with it.
Basically, my goal is to have a Wayland-only setup without any XWayland
involved.
As for polybar, I think it requires Xorg, so it will spawn an XWayland
process. Or am I wrong?
>> What do you think is missing? What would you like to change?>> I was also thinking in test `swhkd` [1] a Rust drop-in replacement for> `sxhkd` that works with a client-server model and works in X11, Wayland> or TTY. Is in early development. This way different WM key hotkey could> merge into one solution.>> [1]: https://github.com/waycrate/swhkd
Oh, I like this! For bspwm and herbstluftwm I already have some common
keys in the 'sxhkdrc' and then individual files for each WM.
Since you note that it is in early development, is there something we
need to know right now. For this sort of thing, I prefer to use a
program that "just works" and not have to change it all the time.
Otherwise we will keep defining keys in Sway's own config file until
swhkd is stable.
--
Protesilaos Stavrou
https://protesilaos.com
> From: Protesilaos Stavrou <info@protesilaos.com>> Date: Sat, 23 Apr 2022 13:08:08 +0300>>> From: Juanjo Presa <juanjo.presa@nadanix.com>>> Date: Sat, 23 Apr 2022 11:37:38 +0200>>>> I can change sway bar colours using `swaymsg bar 0 colors background>> '#505050'`. Are you referring to this? Other option is change to>> `waybar` but I prefer keep using default bar.>> Okay, I did not know that (again, I have not experimented enough with> sway). Then we can update the 'delight' script to account for this as> well.>> Do you want to do it? If not, I will start using sway as my daily> driver and make those changes myself. Then you can just pull them in> your local setup.
I implemented this already. Check commit 9261f6b2.
--
Protesilaos Stavrou
https://protesilaos.com
> From: Protesilaos Stavrou <info@protesilaos.com>> Date: Sat, 23 Apr 2022 13:08:08 +0300>>> From: Juanjo Presa <juanjo.presa@nadanix.com>>> Date: Sat, 23 Apr 2022 11:37:38 +0200>>>>> From: Protesilaos Stavrou <info@protesilaos.com>>>> Date: Fri, 22 Apr 2022 20:59:17 +0300>>>> Hi, thanks for your fast reply.>> You're welcome!>>> [... 25 lines elided]>>>> I can change sway bar colours using `swaymsg bar 0 colors background>> '#505050'`. Are you referring to this? Other option is change to>> `waybar` but I prefer keep using default bar.>> Okay, I did not know that (again, I have not experimented enough with> sway). Then we can update the 'delight' script to account for this as> well.>> Do you want to do it? If not, I will start using sway as my daily> driver and make those changes myself. Then you can just pull them in> your local setup.
Wow that was fast!
> I also prefer the default bar over waybar, especially since I don't want> to do anything fancy with it.>>> i3blocks/i3status has advantage of being wide standard. Maybe the point>> is levereage them also in your polybar setup.>> The reason I am not sure about it pertains to Wayland. I believe they> are display-protocol-agnostic and seem to work perfectly fine in that> regard, but I have not double-checked. If you think this part is fine,> then I am good with it.
Just check status bar state of the art and I was wrong. i3blocks is
tied to i3/swaywm so its hard to use in bspwm.
> Basically, my goal is to have a Wayland-only setup without any XWayland> involved.
Same here.
> As for polybar, I think it requires Xorg, so it will spawn an XWayland> process. Or am I wrong?
I've found an interesting polybar alternative `yambar`. Works in both, Xorg and
Wayland, and it is WM agnostic. I'll test in sway and report here.
>>> What do you think is missing? What would you like to change?>>>> I was also thinking in test `swhkd` [1] a Rust drop-in replacement for>> `sxhkd` that works with a client-server model and works in X11, Wayland>> or TTY. Is in early development. This way different WM key hotkey could>> merge into one solution.>>>> [1]: https://github.com/waycrate/swhkd>> Oh, I like this! For bspwm and herbstluftwm I already have some common> keys in the 'sxhkdrc' and then individual files for each WM.>> Since you note that it is in early development, is there something we> need to know right now. For this sort of thing, I prefer to use a> program that "just works" and not have to change it all the time.>> Otherwise we will keep defining keys in Sway's own config file until> swhkd is stable.
Nice, I'll try myself and report about its stability.
--
Juanjo Presa
https://nadanix.com
> From: Juanjo Presa <juanjop@gmail.com>> Date: Sat, 23 Apr 2022 23:26:15 +0200>>> From: Protesilaos Stavrou <info@protesilaos.com>>> Date: Sat, 23 Apr 2022 13:08:08 +0300>>>>> From: Juanjo Presa <juanjo.presa@nadanix.com>>>> Date: Sat, 23 Apr 2022 11:37:38 +0200>>>>>>> From: Protesilaos Stavrou <info@protesilaos.com>>>>> Date: Fri, 22 Apr 2022 20:59:17 +0300>>>>>> Hi, thanks for your fast reply.>>>> You're welcome!>>>>> [... 25 lines elided]>>>>>> I can change sway bar colours using `swaymsg bar 0 colors background>>> '#505050'`. Are you referring to this? Other option is change to>>> `waybar` but I prefer keep using default bar.>>>> Okay, I did not know that (again, I have not experimented enough with>> sway). Then we can update the 'delight' script to account for this as>> well.>>>> Do you want to do it? If not, I will start using sway as my daily>> driver and make those changes myself. Then you can just pull them in>> your local setup.>> Wow that was fast!>>> I also prefer the default bar over waybar, especially since I don't want>> to do anything fancy with it.>>>>> i3blocks/i3status has advantage of being wide standard. Maybe the point>>> is levereage them also in your polybar setup.>>>> The reason I am not sure about it pertains to Wayland. I believe they>> are display-protocol-agnostic and seem to work perfectly fine in that>> regard, but I have not double-checked. If you think this part is fine,>> then I am good with it.>> Just check status bar state of the art and I was wrong. i3blocks is> tied to i3/swaywm so its hard to use in bspwm.>>> Basically, my goal is to have a Wayland-only setup without any XWayland>> involved.>> Same here.>>> As for polybar, I think it requires Xorg, so it will spawn an XWayland>> process. Or am I wrong?>> I've found an interesting polybar alternative `yambar`. Works in both, Xorg and> Wayland, and it is WM agnostic. I'll test in sway and report here.
Forget about `yambar`. I mix 3 different projects `yabar`, `yambar` and
`yuzbar (formerly yambar)`. The `yambar` one which have Wayland/Xorg
support have not bspwm builtin module.
So the other way I imagine to Don't Repeat Yourself is using
lemonbar+i3blocks and swaybar+i3blocks. But I check you forked lemonbar
some time ago so maybe you have much more experience with this than me.
>>>> What do you think is missing? What would you like to change?>>>>>> I was also thinking in test `swhkd` [1] a Rust drop-in replacement for>>> `sxhkd` that works with a client-server model and works in X11, Wayland>>> or TTY. Is in early development. This way different WM key hotkey could>>> merge into one solution.>>>>>> [1]: https://github.com/waycrate/swhkd>>>> Oh, I like this! For bspwm and herbstluftwm I already have some common>> keys in the 'sxhkdrc' and then individual files for each WM.>>>> Since you note that it is in early development, is there something we>> need to know right now. For this sort of thing, I prefer to use a>> program that "just works" and not have to change it all the time.>>>> Otherwise we will keep defining keys in Sway's own config file until>> swhkd is stable.>> Nice, I'll try myself and report about its stability.
--
Juanjo Presa
https://nadanix.com
> From: Juanjo Presa <juanjop@gmail.com>> Date: Sun, 24 Apr 2022 00:20:42 +0200>>> As for polybar, I think it requires Xorg, so it will spawn an XWayland>>> process. Or am I wrong?>>>> I've found an interesting polybar alternative `yambar`. Works in both, Xorg and>> Wayland, and it is WM agnostic. I'll test in sway and report here.>> Forget about `yambar`. I mix 3 different projects `yabar`, `yambar` and> `yuzbar (formerly yambar)`. The `yambar` one which have Wayland/Xorg> support have not bspwm builtin module.
Okay then.
> So the other way I imagine to Don't Repeat Yourself is using> lemonbar+i3blocks and swaybar+i3blocks. But I check you forked lemonbar> some time ago so maybe you have much more experience with this than me.
The fork was basically me merging some patches that provided support for
Xft fonts (I don't know how to program in C). Otherwise lemonbar only
supports bitmap fonts, which are not very legible on a light background.
Maybe upstream has changed this policy, though I have not checked in a
while.
Lemonbar is fine in itself. The problem is to write good scripts for
the modules to avoid looping through everything per minute or some other
fixed interval. I don't know how to have asynchronous blocks in a
lemonbar panel and also don't know how to trigger an update of a block
on demand (e.g. audio volume increase should send a signal to the
panel).
I also have not experimented with the lemonbar+i3blocks integration. If
it can be done right to keep the modules asynchronous and triggerable on
demand, then I am happy to switch to this setup.
Do you have any experience on this front? Suggestions are most welcome!
--
Protesilaos Stavrou
https://protesilaos.com