No `.xsession` is created, and xfce does not load `.profile`

[tobiasBora]

Hello,

first, thanks for this great project. I would like to use it to configure GTK/QT theme on xfce. However, I have some troubles with that, because for some reason, the home-manager creates a .profile but does not create a .xsession, and xfce seems to load only the .xsession file.

To demonstrate that, I'm using the following code:

  # To avoid error about ca.desrt.dconf:
  services.dbus.packages = with pkgs; [ gnome3.dconf ];
  # Or maybe programs.dconf.enable = true;?
  home-manager.users.me = { pkgs, ... }: {
    programs.bash.enable = true;
    gtk = {
      enable = true;
      font.name = "Noto Sans Light 10";
      theme = {
        package = pkgs.breeze-gtk;
    name = "Breeze-Dark";
      };
      iconTheme = {
        package = pkgs.iconpack-obsidian;
    name = "Obsidian-Aqua";
      };
    };
    qt = {
      enable = true;
      platformTheme = "gtk";
    };
    xsession.profileExtra =
      ''
        eval $(ssh-agent)
      '';
  };

and after deployement, it creates a file .profile that sets the environment variable QT_QPA_PLATFORMTHEME:

$ cat ~/.profile
# -*- mode: sh -*-
. "/home/me/.nix-profile/etc/profile.d/hm-session-vars.sh"
$ cat "/home/me/.nix-profile/etc/profile.d/hm-session-vars.sh"
# Only source this once.
if [ -n "$__HM_SESS_VARS_SOURCED" ]; then return; fi
export __HM_SESS_VARS_SOURCED=1

export QT_QPA_PLATFORMTHEME="gtk2"

However, this environment variable is not exported in xfce, so i guess xfce just read the .xsession files:

$ echo $QT_QPA_PLATFORMTHEME

However, I don't really understand why the .xsession file is not created, as it's written here:

xsession.importedVariables = [ "QT_QPA_PLATFORMTHEME" ];

And even my code

xsession.profileExtra = "...";

does not appear as .xsession does not even exist:

$ ls ~/.xsession*
/home/me/.xsession-errors

Is it a bug or a feature? Why does nothing create the .xsession file for me?

Thanks!

[Gerschtli]

Hey, you have to enable xsession first like this:

{
  xsession.enable = true;
}

So technically this is a feature and a common pattern in every NixOS and home-manager modules that you need to enable the module before other option are taken into account.

[tobiasBora]

Thanks for your answer. However, it turns out that it doesn't exactly solve my problem. Or more precisely, it creates more problems than it solve...

So basically, when I enable xsession, it creates the xsession file only if I provide a command to launch the desktop manager. Naively, I set the command to the empty string, as I was thinking that in case no WM was run, the WM chosed in SDDM would just run (If possible I'd like to still be able to change my WM directly from SDDM, I like to go from xfce to KDE, come back, use awesome...). And when you put an empty command... Boom, you can't connect graphically to your session anymore: when you log in your are logged out directly (I don't understand why, because this code suggests that if .xsession does not run any WM, then it continues to the usual connection. if you have any idea let me know).

After searching a bit, it appears that debian runs .xsessionrc (note the rc at the end!). However, if I'm not wrong, it's not the case of Nixos (I tried and it failed). I tried to read this code a bit, and it seems that the file that is loaded by NixOS is .xprofile (not .profile!). However, as I understand, home manager does not creates the .xprofile file with the .xsession file, that I do not want as I can't connect anymore to my session with that...

What is the good way to solve this problem, and let me use the WM provided by SDDM?

[Gerschtli]

The problem here is that xsession-wrapper of NixOS searches for ~/.xsession and if this file exists, it will be executed and exiting from xsession-wrapper (see the exec in this line). Therefore, if ~/.xsession does not start any graphical interface, nothing happens.

What you want is just to have a plain ~/.xprofile. I don't know if it would make much sense to provide a home-manager module for this special case as you can just write this file by yourself:

{
  home.file.".xprofile".text = "...";
}

[tobiasBora]

Ok, thanks you, I'll do that. Maybe the documentation could say something about that? When you enable gtk/qt theme, you expect it to work kind of out of the box.

Thanks!

[rycee]

You can use xsession.scriptPath to change the name of the generated xsession file. E.g.,

xsession.scriptPath = ".xsession-hm";

then NixOS won't force you into this X session.

You can still run the HM generated session by adding

services.xserver.desktopManager.session = [{
  name = "home-manager";
  bgSupport = true;
  start = ''
    ${pkgs.stdenv.shell} $HOME/.xsession-hm &
    waitPID=$!
  '';
}];

to the system configuration.

[tobiasBora]

This script won't setup the environment variables for the current DE right (assuming I'm not running the DE from it, but directly from SDDM)? So I'm not sure to see why it could be useful to run this script...

[rycee]

@tobiasBora I was thinking about the issue that @Gerschtli mentioned

The problem here is that xsession-wrapper of NixOS searches for ~/.xsession and if this file exists, it will be executed and exiting from xsession-wrapper (see the exec in this line). Therefore, if ~/.xsession does not start any graphical interface, nothing happens.

If you set xsession.scriptPath = ".xsession-hm"; then you can also set xsession.enable = true; without causing xsession-wrapper to run .xsession since there no longer is a file with that name.

The services.xserver.desktopManager.session suggestion I made was if you wanted to also have the HM session as a login option. If you don't then you can ignore that part.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.