You are not logged in.
So I decided to have a Wayland WM just in case, since I want to update my dwm with having some default backup.
So first of all:
But you can just go back to your previous state in your dwm, just compile again right ? Yep I can do that, but I want to just run quick hyprland if I need to do something quickly, yeah I know dwm compiles in less than 10 seconds, but It also an excuse to check how Hyprland is going on because of my failure in trying sway cuz I have nvidia gpu :C. so long story short: Excuses to try wayland and Hyprland again, and in the process create a wayland compositor alternative for my general usage just in case.
Long story short: I'm working in my status bar, but I also want to add it in my Hyprland setup, I'm working in the same machine having Xorg with dwm also. So i compiled eww with Xorg flag as this says: https://elkowar.github.io/eww/
So this creates issues in hyprland because when I want to run a widget:
WARN eww > Eww compiled without wayland support. Falling back to X11, eventhough wayland was requested.
failed to open window `bar`
Caused by:
Failed to get x11 window for gtk windowSo According to this: https://wiki.hypr.land/Configuring/XWayland/ I tried this in my config file:
xwayland {
enabled = true
force_zero_scaling = true
}
env = GDK_SCALE,2
env = XCURSOR_SIZE,32but I'm having the error of before :C . So I have three options I guess:
1) Compile eww with wayland flag, which I don't want to do because I will lost the xorg support of my bar :C
2)Trying to run eww with xorg flag with Xwayland, which I want to try first.
3)Tweak the application building to have two binaries in the end that can work in a machine that have Xorg and wayland, and call the corresponding one in the .xinitrc and hyprland.conf. Not sure if this is a good idea in this case.
And btw: But workspaces switching code is going to be different in Xorg and wayland but that I cant comment the wayland part and deal with it during the development of both ![]()
Last edited by Succulent of your garden (2026-02-02 18:40:50)
str( @soyg ) == str( @potplant ) btw!
Offline
https://github.com/elkowar/eww/blob/fdd … o.toml#L13
Default seems to be to build for both backends?
Offline
https://github.com/elkowar/eww/blob/fdd … o.toml#L13
Default seems to be to build for both backends?
I'm astonish in how you are so quickly to find the useful information in git repos. Any method you use for that ? Or just pure years of experience in action
?
Sadly compiling with this forms it doesn't work:
cargo build --release --no-defaults-features --features default
cargo build --release --features default
cargo build --releaseYou need to make your marry with --features x11 or --features wayland to make it work. If not eww doesn't show anything. So I complied both and put it in different file paths. then In .bashrc:
alias eww="~/eww/target/release/eww"
alias xeww="~/xeww/target/release/eww" #The xorg version of ewwand also
export PATH="~/eww/target/release:$PATH"
#Xorg eww
export PATH="~/xeww/target/release:$PATH"When you invoke eww in wayland it works, compositor opens the widgets instantly. When I invoke it in xorg by startx it doesn't, But if I do in a terminal session:
xeww daemon
xeww open-many "my list of widgets"Xorg session is able to launch the widget. So I think is startx script that doesn't read in some sense the env of the user shell by default. What do you think about this ? Should I just create a simple script with xeww daemon && xeww open-many "bla bla bla" and make it run it by .xinitrc file ? or you suggest a more wisely and elegant solution for my issue ? ![]()
Last edited by Succulent of your garden (Yesterday 21:58:14)
str( @soyg ) == str( @potplant ) btw!
Offline
If not eww doesn't show anything.
On both, X11 and wayland?
Do you export GDK_BACKEND to any value and/or does doing so help anything?
So I think is startx script that doesn't read in some sense the env of the user shell by default.
Aliases are not expanded in non-interactive shells, for the PATH environment it depends on how and where you run startx
I'd however most like just opt for having and running two differently named binaries, rather than using aliases or fudging around w/ the PATH here.
But the best solution is to get the same eww to work on both display servers and that should™ not be a problem.
Offline
instead of building it manually, use the aur package https://aur.archlinux.org/packages/eww
Offline