search

sodiboo / niri-flake

Nix packages and modules for niri
https://github.com/YaLTeR/niri
MIT License
125 stars 14 forks source link

document nix-specific equivalents of topics from niri wiki (+ off-topic nix talk, vscode ozone) #5

Closed KiaraGrouwstra closed 8 months ago

KiaraGrouwstra commented 8 months ago

niri's wiki documents a bunch of common tasks and how to achieve them using niri. users of this flake repo will face the challenge of how to translate those solutions to the NixOS context, or may further wonder how much of those concerns will have been addressed by this repo out of the box already. it would be nice to have perhaps the readme here explain tackling such related tasks for users of this repo as well, including which of those have been tackled by this flake and which ones should be handled manually (and if so, how).

KiaraGrouwstra commented 8 months ago

e.g. for vscode/vscodium i had to pass --ozone-platform=wayland, automated using an override

sodiboo commented 8 months ago

I think this seems like a good idea to document in the README more thoroughly at some point, but for now, here's a rough overview of nix-specific notes to the wiki:

this flake is "supposed" to deal with installing the niri session, and its core dependencies (portals, polkit). I am not 100% confident that it actually handles all that correctly. other addons like swaylock, swaybg are not part of this flake. it also handles the niri config.

e.g. for vscode/vscodium i had to pass --ozone-platform=wayland, automated using an override

This is not how it's "supposed" to be done on nix - you should set the environment variable NIXOS_OZONE_WL=1 and then the ozone args will be passed automatically to vscode (and several other electron apps), this is behaviour already present in nixpkgs and you do not need an override. it gives the app --ozone-platform-hint=auto, so they will still work on non-Wayland with this option set.

The wiki covers "example systemd setup" which involves symlinking various things into niri.service.wants. I find, from my experience with some of the mentioned applications (mako, waybar), on NixOS they generally already have some sort of coupling to graphical-session.target. waybar seems to somewhat inconsistently start? like it does but not always. needs more investigation. how to set overrides from nix config? lol idk

"important software" notes with this flake:

vscode: as mentioned above, set NIXOS_OZONE_WL=1. WaylandWindowDecorations feature is mentioned on niri wiki, this is not necessary (and does not seem to have any effect when I tried it?). do not set prefer-no-csd

wezterm: idk i never tried it

Xwayland: no additional notes.

KiaraGrouwstra commented 8 months ago

This is not how it's "supposed" to be done on nix - you should set the environment variable NIXOS_OZONE_WL=1 and then the ozone args will be passed automatically to vscode

yeah, i had been trying it that way, yet only got it to work on niri passing the extra flag. did it work with just NIXOS_OZONE_WL=1 for you?

how to set overrides from nix config?

i think you can configure systemd services using systemd.services

sodiboo commented 8 months ago

This is not how it's "supposed" to be done on nix - you should set the environment variable NIXOS_OZONE_WL=1 and then the ozone args will be passed automatically to vscode

yeah, i had been trying it that way, yet only got it to work on niri passing the extra flag. did it work with just NIXOS_OZONE_WL=1 for you?

it works fine for me, just setting the environment variable. Do you get warnings about unknown flags when you run code? (you will, if the env var is working). Does it show up if you run env | grep NIXOS? How are you setting it? i use environment.variables in system config (as opposed to, say, niri config or home-manager. i haven't tried it in either of those places so i don't know if it'd work, but they are reasonable places to set it)

KiaraGrouwstra commented 8 months ago

i did get the warnings:

Warning: 'ozone-platform-hint' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.

i'd set the NIXOS_OZONE_WL=1 thru environment.variables myself as well.

$ env | grep NIXOS
NIXOS_OZONE_WL=1
NIXOS_XDG_DESKTOP_PORTAL_CONFIG_DIR=/nix/store/ad1j5436sm9aqfx05301n9fi7qlvvhzm-xdg-portal-configs/share/xdg-desktop-portal
__NIXOS_SET_ENVIRONMENT_DONE=1

if for you it works tho then perhaps this is mostly still of interest once others start running into this as well.

sodiboo commented 8 months ago

Interesting. You're getting the flags passed, but vscode refuses to launch in Wayland? do you have anything X-related running such that it may decide "auto => X11"? 'cause otherwise i don't know why it wouldn't work. this seems very strange

KiaraGrouwstra commented 8 months ago

that might be it, tho i feel a bit over my head there. i enabled services.xserver for services.xserver.displayManager.defaultSession = "niri"; (and thinking the DM might need it), tho otherwise i haven't consciously tried to enable X-related stuff. i guess if anything it looks like this one isn't a problem about niri or niri-flake tho. :)

sodiboo commented 8 months ago

what display manager do you use? i suppose it's possible that it's starting an Xorg server. is DISPLAY set when you're in the niri environment? does it work fine without additional args if you start it manually from tty? (Ctrl+Alt+F{whatever tty index}, then login and run niri manually or niri-session. then, i suppose ensure DISPLAY is unset, it will be unless you somehow set it externally, and of course NIXOS_OZONE_WL is set). at least for me, running from tty works (i use greetd + tuigreet, which is basically just a nicer login screen, and then a custom "command to run", which i set to niri-session. i haven't actually tried niri with anything else, my setup is just a thin wrapper around "login and run a single command instead of starting the default shell")

I tried to, at this point, create some sample config that modifies the niri-session script to unset DISPLAY but i give up. it requires major changes to the flake in order to do it and i don't even know for sure it will have any benefit. i spent 2 hours this. fuck this. just make a wrapper package that takes an override arg pkgs, and copies every file from the niri package to itself, then runs sed -i "39s/^/unset DISPLAY/" $out/bin/niri-session to fixup the script. maybe this works if DISPLAY really is being set.

KiaraGrouwstra commented 8 months ago

i also use tuigreet (which i hadn't managed to configure nicely, so i'd be curious to steal your config). i used it with --cmd niri over niri-session tho, and my DISPLAY then returns empty. i'll try it with --cmd niri-session as well.

sodiboo commented 8 months ago

Ah, I'd imagine that has to be it. The niri-session script is a wrapper around the systemd service that among other things, sets XDG_SESSION_TYPE=wayland, which (without having actually looked at how electron is implemented) i think is likely the reason it's not working on "auto" for you. this seems like maybe where it'd get that info from. My setup with tuigreet isn't that polished either, it's basically just letting it access fprint and then the greetd invocation is tuigreet with some args to set the correct time style and menu options, and of course --cmd niri-session. Currently, my nix config is private as I use it to sync between devices, and I'd like to polish it more before publishing. But, if you'd find it useful, I can publish my nix config tomorrow

KiaraGrouwstra commented 8 months ago

nice, thanks! it seems niri-session has indeed allowed me to drop the flag to vscodium. DISPLAY seems still unset, but a few other things did change. some of that i might take to the main repo, but fyi in case any sound familiar:

fyi, i'd yet to get the services for swaybg/waybar to works as well (already prior to this change).

sodiboo commented 8 months ago

that's... certainly an interesting list of side effects. "fixed XDG autostart" is the only one I expected, as this is mentioned in niri's README (and on the wiki). The rest seem very strange and likely upstream issue(??? idk). As for my experience with niri-session, i straight up haven't bothered to theme my environment (as I generally use Firefox, foot, vscode and chat apps including Discord and Element -- none of which actually respect these settings in most regards, or at least for firefox it won't respect them given how I've set it up), and I have no issue with using spawn on binds (though, for autostart stuff I use systemd). for ipc or spawn-at-startup, I've never tried these

KiaraGrouwstra commented 8 months ago

thanks! i'll try and report the theming gap upstream then (edit: https://github.com/YaLTeR/niri/issues/193). and yeah, those apps do seem to have opinions. :) i have been trying some styling, so far using stylix tho i also wanna try and better pull off the likes of pywal.

if niri's spawning functionality works for you, i might wanna peek at your setup as well to figure out how i messed up there.

sodiboo commented 8 months ago

as promised, here's my nix config: https://github.com/sodiboo/nix-config

be warned, it is not optimized to be pretty. it's a single mega file for home and system configuration on two machines. at some point, i want to split it into multiple files. but not now.

KiaraGrouwstra commented 8 months ago

i wish my config still looked like that. :sob:

sudo -i and nix-shell will create a bash shell. So it must also be enabled or i don't get my prompt

that's interesting, i don't use the bash.enable = true; line.

the inputs.etc-nixos blew my mind. :sweat_smile:

i love how you handled niri, i def need to steal more of that (once i figure out what i did wrong).

sodiboo commented 8 months ago

that's interesting, i don't use the bash.enable = true; line.

yeah. i don't think i really need it. i have nix-shell aliased to nix-shell --run fish and i don't use sudo -i often. bash.enable is useful still, though, mostly to test POSIX shell syntax, such as when writing my blurred-locker script which was.. a pain to debug. especially trying to iterate/benchmark on different blur parameters because imagemagick can take a while, and a simple gaussian blur filter on the full image either looks terrible at low radii or takes excess of 20 seconds for quality results (which is acceptable latency for a keybind)

sodiboo commented 8 months ago

Can you try adding this line to your config, to potentially solve the gtk theming issue?

xdg.portal.extraPortals = [pkgs.xdg-desktop-portal-gtk];
sodiboo commented 8 months ago

Can you try adding this line to your config, to potentially solve the gtk theming issue?

xdg.portal.extraPortals = [pkgs.xdg-desktop-portal-gtk];

nevermind. i actually tried this on my own system; it fails to build. surely xdg-desktop-portal-gnome depends on it? still try if it works, but don't expect it to. i figured it might also solve my own issues with default applications, but ether way, i think you're not alone in xdg troubles and very much like YaLTeR said, likely not actually a niri issue

KiaraGrouwstra commented 8 months ago

it did actually built for me, tho it didn't seem to solve it yet for me. you're right they depend on the gtk one tho.

sodiboo commented 8 months ago

sudo -i and nix-shell will create a bash shell. So it must also be enabled or i don't get my prompt

that's interesting, i don't use the bash.enable = true; line.

I actually tried sudo -i just now and it launched fish. I think that this comment might be old enough that i was just setting fish for my user, rather than the "default shell" for the root user also. nix-shell seems to be incorrect still, but i handled that long ago by aliasing it to nix-shell --run fish. So, basically i don't need bash.enable at all.

KiaraGrouwstra commented 8 months ago

i figured out what broke spawn for me in niri-session, seems that was systemd.user.services.niri.wants (either waybar/swaync/swaybg broke it). i'd tried that as per the niri wiki example, but if anyone figures that out on nixos i'd be curious - now i'm just settling for spawn-on-startup there.

sodiboo commented 8 months ago
  • authentication agent: should be (is it actually?) handled by my flake

It definitely wasn't at all when i wrote this, but i implemented it in https://github.com/sodiboo/niri-flake/commit/3ae38e76c73fb705cac9d8a5011f37e43bdbdd6a. I've also documented some nix-specific steps in the latest revision of the README. What do you think? https://github.com/sodiboo/niri-flake/commit/f027c2c713433865bda5a24498ba15a153c8c27e

KiaraGrouwstra commented 8 months ago

thanks, great to see some docs! guess maybe i can mark this issue as closed, tho you may feel free to tag me for testing/feedback more often. :) hopefully nixpkgs niri 1.2 will land soon as well then.

i'm personally having trouble with programs.waybar.systemd.enable = true; as well (already using programs.waybar.settings.mainBar.layer = "top";), so i wonder what's up with that.