Trying to autostart in GNOME, and "//homeless-shelter" directory?

Help
1

I recently decided to leave Hyprland, following the switch to lua, and I’ve settled in on a GNOME config that I actually really like. One piece of my Hyprland config that I’m trying to replicate, though, is a login workaround that I used to make my system remotely accessible via Sunshine on boot. Basically, I would use auto-login via greetd, then exec hyprlock as part of my Hyprland startup config. This worked really nicely and allowed me to turn on my system remotely and start playing games or do whatever else right away without having to ssh and fumble around with Sunshine via TTY.

Now the easy part of this in GNOME is the auto-login, but I can’t seem to figure out a decent way of running xdg-screensaver lock on start. I discovered xdg.autostart in Home-Manager, but now I’m afraid I’ve run into some really weird issues. As you can see in my xdg.nix Home-Manager module, I’m trying to place a .desktop file from my dotfiles into the autostart folder:

{
  config,
  lib,
  pkgs,
  ...
}:
with lib;
let
  cfg = config.roles.desktop.xdg;
in {
  options.roles.desktop.xdg = {
    enable = mkEnableOption "Enable XDG config";
  };

  config = mkIf cfg.enable {
    xdg = {
      enable = true;
      autostart = {
        enable = true;
        entries = [
          "/$HOME/.dotfiles/modules/home-manager/desktop/gnome/screenlock.desktop"
        ];
      };
      mime.enable = true;
      mimeApps = {
        enable = true;
      };
      portal = {
        enable = true;
        extraPortals = [pkgs.xdg-desktop-portal-gnome];
        configPackages = [pkgs.gnome-session];
      };
    };
  };
}

That .desktop file is as follows, very simple stuff:

[Desktop Entry]
Type=Application
Name=Lock Screensaver
Exec=xdg-screensaver lock

Now where it gets weird is when I build my system with this and navigate to the autostart folder, I’m met with a broken symlink. I think this has to do with my previous lack of understanding with xdg.autostart, trying to use both home.file and xdg.autostart to place the .desktop file, but I’m not quite sure. In any case, I tried to check the symlink in the Nix store, and I get this mess:

283d7jy13p6kn5974jhc3mmy3rcw10fv-home-manager-files/.config/autostart🔒
❯ ll
total 12
lrwxrwxrwx 1 root root  82 Dec 31  1969 screenlock.desktop -> //homeless-shelter/.dotfiles/modules/home-manager/desktop/gnome/screenlock.desktop
lrwxrwxrwx 1 root root 122 Dec 31  1969 stylix-activate-gnome.desktop -> /nix/store/9wnas4kizsvdv3vjg42iqp7898j62aaf-stylix-activate-gnome.desktop/share/applications/stylix-activate-gnome.desktop
lrwxrwxrwx 1 root root 118 Dec 31  1969 stylix-activate-kde.desktop -> /nix/store/phdvzcg7njdfdmgw6rkdv14w7sxbprj5-stylix-activate-kde.desktop/share/applications/stylix-activate-kde.desktop

So I guess I have two problems here:

  1. Is there a better way to get GNOME to autolock after auto login, or is this pretty much the expected way? And if so, what am I doing wrong?
  2. How on Earth do I rm this dangling symlink, which seems to point to a non-existent //homeless-shelter directory that I can’t delete?
  3. Bonus question: how do I remove the stylix-activate-kde.desktop symlink, which seems to persist despite having uninstalled KDE Plasma and not finding any reference to it anywhere in my config?

Thanks in advance for any help!

2

Is there a reason this is a string instead of a path e.g. ./gnome/screenlock.desktop?

2 Likes
3

What @MaxHearnden said. /homeless-shelter is the value of $HOME inside the derivation sandbox. xdg.autostart.entries is not escaping shell variables; it probably ought to, but then the ‘correct’ behavior is a symlink to a nonexistent path literally named /$HOME/....

Check stylix.targets.kde.enable. (It defaults to true if you have set stylix.autoEnable, so in that case you have to explicitly disable it.)

3 Likes
4

Primary reason is ignorance. That worked, thank you!

Now I just need to figure out why this .desktop file doesn’t seem to do anything… Even running it as an executable doesn’t do anything, nor does changing the exec to loginctl lock-session.

Edit: Found a solution. Here’s the complete .desktop file; just need to figure out why the GNOME unblank plugin isn’t working, but that’s minor. Thanks everyone!

[Desktop Entry]
Type=Application
Name=Lock Screen
Exec=gdbus call --session --dest org.gnome.Shell.ScreenShield --object-path /org/gnome/ScreenSaver --method org.gnome.ScreenSaver.Lock
5

Just wanted to give a quick update here. The .desktop file technically worked, but it had some issues. From how it behaved, I’m guessing it loaded way too quickly because the GNOME unblank plugin never worked. This kind of ruined the whole idea, as it still required input from a physically connected device for Moonlight to be able to connect.

What ended up working (perfectly, so far) is a systemd service that calls the lockscreen after a short delay. This gives the system the time it needs to load all the GNOME plugins. This along with setting up auto login results in the system logging in, locking, and the screen staying on as intended. The systemd service is as follows:

    # Run GNOME Screen Shield on login to secure after autoLogin
    systemd.user.services.screenlock = {
      enable = true;
      after = [ "graphical.target" "gnome-session.target" ];
      wantedBy = [ "graphical.target" "gnome-session.target" ];
      description = "Lock screen on login";
      serviceConfig = {
        type = "oneshot";
        BusName = "org.gnome.ScreenSaver";
        ExecStartPre = "/run/current-system/sw/bin/sleep 1.78";
        ExecStart = "/run/current-system/sw/bin/xdg-screensaver lock";
      };
    };

I hope this helps anyone who wanted to get this working in this specific way like I did. Thanks again for the help!

1 Like