bemenu VS wslg

I've already highlighted how using environment variables to change themes is a horrible user experience. The bemenu program suffers from the same flaw. Environment Variables should never be used in any way for values that might change inside a running session.

bemenu

Environment variables are fine when used for things that usually don't change once they're set. For example, XDG_CONFIG_HOME or GOPATH. They are, however, absolutely awful when used to configure values that will probably change inside a session. A good example is BEMENU_OPTS from the bemenu program, which is used to change colors, font etc. Should I relogin into my session just to make a program use dark mode colors?

https://github.com/Cloudef/bemenu#environment-variables

In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts or overridden on the command line before executing a command, which is extremely annoying.

Bemenu - "Dynamic menu library and client program inspired by dmenu"

Instead of rofi, bemenu[2] is nice too.

[1] https://github.com/dunst-project/dunst/issues/264

[2] https://github.com/Cloudef/bemenu

tessen can use either bemenu, the wayland fork of rofi, or wofi to show password store data. It relies on wtype for autotyping instead of using ydotool because ydotool needs root privileges.

I've made a script called tessen which is, more or less, a replacement of rofi-pass but for Wayland. It can use bemenu or the wayland fork of rofi. It relies on wtype for autotyping instead of using ydotool because ydotool needs a daemon running with root privileges.

Thanks. I found this issue https://github.com/Cloudef/bemenu/issues/149

WSLg on windows 11 can run Linux GUI applications more easily, it's harder to do that on Windows 10 with WSL2. And USB pass-through supposedly works better.

If you use windows 11, you can skip that altogether now that WSL2 has built-in X11 and Wayland support. Even without that, I've found it much more reliable to use a framebuffer streaming protocol like VNC or RDP instead of a remote X client, which can be notoriously finicky.

I've seen it run using WSL, but performance wasn't great because the graphics was software emulated, but WSLg might improve that situation.

If your os is Win 11, then you should be able to run GUI applications: https://github.com/microsoft/wslg

The developer channel version of WSL2 comes with Wayland, which might help push adoption a bit. https://github.com/microsoft/wslg

I'm getting into graphics programing with Rust, and very basic graphical apps spin up 50% of my CPU running through the software renderer. After reading through this GitHub thread I've ensured that Mesa is installed and up to date, but the older driver referenced in this article linked in the first post, which the accepted answer says is the solution, can no longer be located on the Intel website. Am I $#@!ed until Intel driver support catches up to this issue from nearly a year ago? Are there more troubleshooting steps I can take to try to get Mesa/OpenGL to use my GPU?

If you run Windows 11 and for whatever reason want to use a Linux GUI app, you can use WSLg to install apps through your distro and they will show up in the start menu as if you installed them on Windows. It has some limitations and might be a bit unreliable for some cases (ex. you can't use aero snap with Linux apps right now) , but it is an option in case you would like.

It seems this is a common issue regarding keyboard locales on abnt/abnt2 layouts. Here's the discussion regarding the topic.

With WSLg, you can run GUI apps too.