nixpkgs/nixos/modules/services/x11/window-managers/xmonad.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

205 lines
7.4 KiB
Nix
Raw Normal View History

{pkgs, lib, config, ...}:
2015-12-04 14:32:21 +00:00
with lib;
let
inherit (lib) mkOption mkIf optionals literalExpression optionalString;
cfg = config.services.xserver.windowManager.xmonad;
XMonad: configured recompile (#107696) * nixos/xmonad: xmonad config w/ghc+xmessage When the "config" option isn't set, we use xmonad-with-packages to provide xmonad with runtime access to an isolated ghc, ensuring it can recompile and exec a user's local config (e.g. $HOME/.xmonad/xmonad.hs) regardless of which ghc (if any) is on PATH. When the "config" option is set, however, we compile a configured xmonad executable upfront (during nixos-rebuild), and prior to this commit, it was not provided with runtime access to an isolated ghc. As a result, with the "config" option set, it was not possible to recompile and exec a user's local config unless there was a compatible version of ghc on PATH with the necessary packages (xmonad, xmonad-contrib, etc.) in its package database. Adding such a ghc to environment.systemPackages, e.g. (haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib])) is problematic because it adds both ghc and an unconfigured xmonad to PATH, e.g. $ ls -l $(which xmonad ghc) lrwxrwxrwx ... /run/current-system/sw/bin/ghc -> /nix/store/...-ghc-8.10.2-with-packages/bin/ghc lrwxrwxrwx ... /run/current-system/sw/bin/xmonad -> /nix/store/...-ghc-8.10.2-with-packages/bin/xmonad Having the unconfigured xmonad on PATH is particularly bad because restarting xmonad will dump the user into the unconfigured version, and if no local config exists (e.g. in $HOME/.xmonad/xmonad.hs), they'll be left in this unconfigured state. In this commmit, we give the configured xmonad runtime access to ghc like xmonad-with-packages does for the unconfigured version. The aim is to allow the user to switch between the nixos module's config and a local config (e.g. $HOME/.xmonad/xmonad.hs) at will, so they can try out config changes without performing a nixos-rebuild. Since the xmonad on PATH is the configured executable, there's no danger a user could unwittingly restart into the unconfigured version, and because xmonad will refuse to recompile when no local config exists, there's no danger a user could unwittingly recompile into an unconfigured version. Given that a local config exists, the recompile/restart behavior depends on two factors: - which entry point is used * 'XMonad.xmonad' (default) * 'XMonad.launch' (recommended in "config" option description) - what operation is triggered (i.e. via mod+q) * `spawn "xmonad --recompile && xmonad --restart"` (default) * `restart "xmonad" True` * custom function If the default 'XMonad.xmonad' entrypoint and default mod+q operation are used, hitting mod+q will compile and exec the local config, which will remain in use until next time the display manager is restarted. If the entrypoint is changed to 'XMonad.launch' but mod+q left with its default operation, hitting mod+q will have no visible effect. The logs (as seen by running `journalctl --identifier xmonad --follow`) will show an error, X Error of failed request: BadAccess (attempt to access private resource denied) which indicates that the shell was unable to start xmonad because another window manager is already running (namely, the nixos-configured xmonad). https://wiki.haskell.org/Xmonad/Frequently_asked_questions#X_Error_of_failed_request:_BadAccess_.28attempt_to_access_private_resource_denied.29 Changing the mod+q operation to `restart "xmonad" True` (as recommended in the "config" option's description) will allow a restart of the nixos-configured xmonad to be triggeredy by hitting mod+q. Finally, if the entrypoint is 'XMonad.launch', mod+q has been bound to `restart "xmonad" True` and another key bound to a custom recompile/restart function (e.g. `compileRestart` as shown in the "config" option example), the user can switch between the nixos module's config and their local config, with the custom key switching to the local config and mod+q switching back. * nixos/xmonad: refactor let binding * nixos/xmonad: refactor (eliminate duplicate code) * nixos/xmonad: install man pages Prior to this commit, man pages were not installed if the "config" option was set. * nixos/xmonad: comment grammar fixups * nixos/xmonad: writeStateToFile in example config Calling writeStateToFile prior to recompiling and restarting allows state (workspaces, etc.) to be preserved across the restart. * nixos/xmonad: add ivanbrennan to maintainers * nixos/xmonad: adjust compileRestart example * nixos/xmonad: add missing import to example config
2020-12-28 16:27:36 +00:00
ghcWithPackages = cfg.haskellPackages.ghcWithPackages;
packages = self: cfg.extraPackages self ++
optionals cfg.enableContribAndExtras
[ self.xmonad-contrib self.xmonad-extras ];
xmonad-vanilla = pkgs.xmonad-with-packages.override {
XMonad: configured recompile (#107696) * nixos/xmonad: xmonad config w/ghc+xmessage When the "config" option isn't set, we use xmonad-with-packages to provide xmonad with runtime access to an isolated ghc, ensuring it can recompile and exec a user's local config (e.g. $HOME/.xmonad/xmonad.hs) regardless of which ghc (if any) is on PATH. When the "config" option is set, however, we compile a configured xmonad executable upfront (during nixos-rebuild), and prior to this commit, it was not provided with runtime access to an isolated ghc. As a result, with the "config" option set, it was not possible to recompile and exec a user's local config unless there was a compatible version of ghc on PATH with the necessary packages (xmonad, xmonad-contrib, etc.) in its package database. Adding such a ghc to environment.systemPackages, e.g. (haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib])) is problematic because it adds both ghc and an unconfigured xmonad to PATH, e.g. $ ls -l $(which xmonad ghc) lrwxrwxrwx ... /run/current-system/sw/bin/ghc -> /nix/store/...-ghc-8.10.2-with-packages/bin/ghc lrwxrwxrwx ... /run/current-system/sw/bin/xmonad -> /nix/store/...-ghc-8.10.2-with-packages/bin/xmonad Having the unconfigured xmonad on PATH is particularly bad because restarting xmonad will dump the user into the unconfigured version, and if no local config exists (e.g. in $HOME/.xmonad/xmonad.hs), they'll be left in this unconfigured state. In this commmit, we give the configured xmonad runtime access to ghc like xmonad-with-packages does for the unconfigured version. The aim is to allow the user to switch between the nixos module's config and a local config (e.g. $HOME/.xmonad/xmonad.hs) at will, so they can try out config changes without performing a nixos-rebuild. Since the xmonad on PATH is the configured executable, there's no danger a user could unwittingly restart into the unconfigured version, and because xmonad will refuse to recompile when no local config exists, there's no danger a user could unwittingly recompile into an unconfigured version. Given that a local config exists, the recompile/restart behavior depends on two factors: - which entry point is used * 'XMonad.xmonad' (default) * 'XMonad.launch' (recommended in "config" option description) - what operation is triggered (i.e. via mod+q) * `spawn "xmonad --recompile && xmonad --restart"` (default) * `restart "xmonad" True` * custom function If the default 'XMonad.xmonad' entrypoint and default mod+q operation are used, hitting mod+q will compile and exec the local config, which will remain in use until next time the display manager is restarted. If the entrypoint is changed to 'XMonad.launch' but mod+q left with its default operation, hitting mod+q will have no visible effect. The logs (as seen by running `journalctl --identifier xmonad --follow`) will show an error, X Error of failed request: BadAccess (attempt to access private resource denied) which indicates that the shell was unable to start xmonad because another window manager is already running (namely, the nixos-configured xmonad). https://wiki.haskell.org/Xmonad/Frequently_asked_questions#X_Error_of_failed_request:_BadAccess_.28attempt_to_access_private_resource_denied.29 Changing the mod+q operation to `restart "xmonad" True` (as recommended in the "config" option's description) will allow a restart of the nixos-configured xmonad to be triggeredy by hitting mod+q. Finally, if the entrypoint is 'XMonad.launch', mod+q has been bound to `restart "xmonad" True` and another key bound to a custom recompile/restart function (e.g. `compileRestart` as shown in the "config" option example), the user can switch between the nixos module's config and their local config, with the custom key switching to the local config and mod+q switching back. * nixos/xmonad: refactor let binding * nixos/xmonad: refactor (eliminate duplicate code) * nixos/xmonad: install man pages Prior to this commit, man pages were not installed if the "config" option was set. * nixos/xmonad: comment grammar fixups * nixos/xmonad: writeStateToFile in example config Calling writeStateToFile prior to recompiling and restarting allows state (workspaces, etc.) to be preserved across the restart. * nixos/xmonad: add ivanbrennan to maintainers * nixos/xmonad: adjust compileRestart example * nixos/xmonad: add missing import to example config
2020-12-28 16:27:36 +00:00
inherit ghcWithPackages packages;
};
XMonad: configured recompile (#107696) * nixos/xmonad: xmonad config w/ghc+xmessage When the "config" option isn't set, we use xmonad-with-packages to provide xmonad with runtime access to an isolated ghc, ensuring it can recompile and exec a user's local config (e.g. $HOME/.xmonad/xmonad.hs) regardless of which ghc (if any) is on PATH. When the "config" option is set, however, we compile a configured xmonad executable upfront (during nixos-rebuild), and prior to this commit, it was not provided with runtime access to an isolated ghc. As a result, with the "config" option set, it was not possible to recompile and exec a user's local config unless there was a compatible version of ghc on PATH with the necessary packages (xmonad, xmonad-contrib, etc.) in its package database. Adding such a ghc to environment.systemPackages, e.g. (haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib])) is problematic because it adds both ghc and an unconfigured xmonad to PATH, e.g. $ ls -l $(which xmonad ghc) lrwxrwxrwx ... /run/current-system/sw/bin/ghc -> /nix/store/...-ghc-8.10.2-with-packages/bin/ghc lrwxrwxrwx ... /run/current-system/sw/bin/xmonad -> /nix/store/...-ghc-8.10.2-with-packages/bin/xmonad Having the unconfigured xmonad on PATH is particularly bad because restarting xmonad will dump the user into the unconfigured version, and if no local config exists (e.g. in $HOME/.xmonad/xmonad.hs), they'll be left in this unconfigured state. In this commmit, we give the configured xmonad runtime access to ghc like xmonad-with-packages does for the unconfigured version. The aim is to allow the user to switch between the nixos module's config and a local config (e.g. $HOME/.xmonad/xmonad.hs) at will, so they can try out config changes without performing a nixos-rebuild. Since the xmonad on PATH is the configured executable, there's no danger a user could unwittingly restart into the unconfigured version, and because xmonad will refuse to recompile when no local config exists, there's no danger a user could unwittingly recompile into an unconfigured version. Given that a local config exists, the recompile/restart behavior depends on two factors: - which entry point is used * 'XMonad.xmonad' (default) * 'XMonad.launch' (recommended in "config" option description) - what operation is triggered (i.e. via mod+q) * `spawn "xmonad --recompile && xmonad --restart"` (default) * `restart "xmonad" True` * custom function If the default 'XMonad.xmonad' entrypoint and default mod+q operation are used, hitting mod+q will compile and exec the local config, which will remain in use until next time the display manager is restarted. If the entrypoint is changed to 'XMonad.launch' but mod+q left with its default operation, hitting mod+q will have no visible effect. The logs (as seen by running `journalctl --identifier xmonad --follow`) will show an error, X Error of failed request: BadAccess (attempt to access private resource denied) which indicates that the shell was unable to start xmonad because another window manager is already running (namely, the nixos-configured xmonad). https://wiki.haskell.org/Xmonad/Frequently_asked_questions#X_Error_of_failed_request:_BadAccess_.28attempt_to_access_private_resource_denied.29 Changing the mod+q operation to `restart "xmonad" True` (as recommended in the "config" option's description) will allow a restart of the nixos-configured xmonad to be triggeredy by hitting mod+q. Finally, if the entrypoint is 'XMonad.launch', mod+q has been bound to `restart "xmonad" True` and another key bound to a custom recompile/restart function (e.g. `compileRestart` as shown in the "config" option example), the user can switch between the nixos module's config and their local config, with the custom key switching to the local config and mod+q switching back. * nixos/xmonad: refactor let binding * nixos/xmonad: refactor (eliminate duplicate code) * nixos/xmonad: install man pages Prior to this commit, man pages were not installed if the "config" option was set. * nixos/xmonad: comment grammar fixups * nixos/xmonad: writeStateToFile in example config Calling writeStateToFile prior to recompiling and restarting allows state (workspaces, etc.) to be preserved across the restart. * nixos/xmonad: add ivanbrennan to maintainers * nixos/xmonad: adjust compileRestart example * nixos/xmonad: add missing import to example config
2020-12-28 16:27:36 +00:00
xmonad-config =
let
xmonadAndPackages = self: [ self.xmonad ] ++ packages self;
xmonadEnv = ghcWithPackages xmonadAndPackages;
configured = pkgs.writers.writeHaskellBin "xmonad" {
ghc = cfg.haskellPackages.ghc;
libraries = xmonadAndPackages cfg.haskellPackages;
inherit (cfg) ghcArgs;
} cfg.config;
in
pkgs.runCommandLocal "xmonad" {
nativeBuildInputs = [ pkgs.makeWrapper ];
} (''
XMonad: configured recompile (#107696) * nixos/xmonad: xmonad config w/ghc+xmessage When the "config" option isn't set, we use xmonad-with-packages to provide xmonad with runtime access to an isolated ghc, ensuring it can recompile and exec a user's local config (e.g. $HOME/.xmonad/xmonad.hs) regardless of which ghc (if any) is on PATH. When the "config" option is set, however, we compile a configured xmonad executable upfront (during nixos-rebuild), and prior to this commit, it was not provided with runtime access to an isolated ghc. As a result, with the "config" option set, it was not possible to recompile and exec a user's local config unless there was a compatible version of ghc on PATH with the necessary packages (xmonad, xmonad-contrib, etc.) in its package database. Adding such a ghc to environment.systemPackages, e.g. (haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib])) is problematic because it adds both ghc and an unconfigured xmonad to PATH, e.g. $ ls -l $(which xmonad ghc) lrwxrwxrwx ... /run/current-system/sw/bin/ghc -> /nix/store/...-ghc-8.10.2-with-packages/bin/ghc lrwxrwxrwx ... /run/current-system/sw/bin/xmonad -> /nix/store/...-ghc-8.10.2-with-packages/bin/xmonad Having the unconfigured xmonad on PATH is particularly bad because restarting xmonad will dump the user into the unconfigured version, and if no local config exists (e.g. in $HOME/.xmonad/xmonad.hs), they'll be left in this unconfigured state. In this commmit, we give the configured xmonad runtime access to ghc like xmonad-with-packages does for the unconfigured version. The aim is to allow the user to switch between the nixos module's config and a local config (e.g. $HOME/.xmonad/xmonad.hs) at will, so they can try out config changes without performing a nixos-rebuild. Since the xmonad on PATH is the configured executable, there's no danger a user could unwittingly restart into the unconfigured version, and because xmonad will refuse to recompile when no local config exists, there's no danger a user could unwittingly recompile into an unconfigured version. Given that a local config exists, the recompile/restart behavior depends on two factors: - which entry point is used * 'XMonad.xmonad' (default) * 'XMonad.launch' (recommended in "config" option description) - what operation is triggered (i.e. via mod+q) * `spawn "xmonad --recompile && xmonad --restart"` (default) * `restart "xmonad" True` * custom function If the default 'XMonad.xmonad' entrypoint and default mod+q operation are used, hitting mod+q will compile and exec the local config, which will remain in use until next time the display manager is restarted. If the entrypoint is changed to 'XMonad.launch' but mod+q left with its default operation, hitting mod+q will have no visible effect. The logs (as seen by running `journalctl --identifier xmonad --follow`) will show an error, X Error of failed request: BadAccess (attempt to access private resource denied) which indicates that the shell was unable to start xmonad because another window manager is already running (namely, the nixos-configured xmonad). https://wiki.haskell.org/Xmonad/Frequently_asked_questions#X_Error_of_failed_request:_BadAccess_.28attempt_to_access_private_resource_denied.29 Changing the mod+q operation to `restart "xmonad" True` (as recommended in the "config" option's description) will allow a restart of the nixos-configured xmonad to be triggeredy by hitting mod+q. Finally, if the entrypoint is 'XMonad.launch', mod+q has been bound to `restart "xmonad" True` and another key bound to a custom recompile/restart function (e.g. `compileRestart` as shown in the "config" option example), the user can switch between the nixos module's config and their local config, with the custom key switching to the local config and mod+q switching back. * nixos/xmonad: refactor let binding * nixos/xmonad: refactor (eliminate duplicate code) * nixos/xmonad: install man pages Prior to this commit, man pages were not installed if the "config" option was set. * nixos/xmonad: comment grammar fixups * nixos/xmonad: writeStateToFile in example config Calling writeStateToFile prior to recompiling and restarting allows state (workspaces, etc.) to be preserved across the restart. * nixos/xmonad: add ivanbrennan to maintainers * nixos/xmonad: adjust compileRestart example * nixos/xmonad: add missing import to example config
2020-12-28 16:27:36 +00:00
install -D ${xmonadEnv}/share/man/man1/xmonad.1.gz $out/share/man/man1/xmonad.1.gz
makeWrapper ${configured}/bin/xmonad $out/bin/xmonad \
'' + optionalString cfg.enableConfiguredRecompile ''
--set XMONAD_GHC "${xmonadEnv}/bin/ghc" \
'' + ''
XMonad: configured recompile (#107696) * nixos/xmonad: xmonad config w/ghc+xmessage When the "config" option isn't set, we use xmonad-with-packages to provide xmonad with runtime access to an isolated ghc, ensuring it can recompile and exec a user's local config (e.g. $HOME/.xmonad/xmonad.hs) regardless of which ghc (if any) is on PATH. When the "config" option is set, however, we compile a configured xmonad executable upfront (during nixos-rebuild), and prior to this commit, it was not provided with runtime access to an isolated ghc. As a result, with the "config" option set, it was not possible to recompile and exec a user's local config unless there was a compatible version of ghc on PATH with the necessary packages (xmonad, xmonad-contrib, etc.) in its package database. Adding such a ghc to environment.systemPackages, e.g. (haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib])) is problematic because it adds both ghc and an unconfigured xmonad to PATH, e.g. $ ls -l $(which xmonad ghc) lrwxrwxrwx ... /run/current-system/sw/bin/ghc -> /nix/store/...-ghc-8.10.2-with-packages/bin/ghc lrwxrwxrwx ... /run/current-system/sw/bin/xmonad -> /nix/store/...-ghc-8.10.2-with-packages/bin/xmonad Having the unconfigured xmonad on PATH is particularly bad because restarting xmonad will dump the user into the unconfigured version, and if no local config exists (e.g. in $HOME/.xmonad/xmonad.hs), they'll be left in this unconfigured state. In this commmit, we give the configured xmonad runtime access to ghc like xmonad-with-packages does for the unconfigured version. The aim is to allow the user to switch between the nixos module's config and a local config (e.g. $HOME/.xmonad/xmonad.hs) at will, so they can try out config changes without performing a nixos-rebuild. Since the xmonad on PATH is the configured executable, there's no danger a user could unwittingly restart into the unconfigured version, and because xmonad will refuse to recompile when no local config exists, there's no danger a user could unwittingly recompile into an unconfigured version. Given that a local config exists, the recompile/restart behavior depends on two factors: - which entry point is used * 'XMonad.xmonad' (default) * 'XMonad.launch' (recommended in "config" option description) - what operation is triggered (i.e. via mod+q) * `spawn "xmonad --recompile && xmonad --restart"` (default) * `restart "xmonad" True` * custom function If the default 'XMonad.xmonad' entrypoint and default mod+q operation are used, hitting mod+q will compile and exec the local config, which will remain in use until next time the display manager is restarted. If the entrypoint is changed to 'XMonad.launch' but mod+q left with its default operation, hitting mod+q will have no visible effect. The logs (as seen by running `journalctl --identifier xmonad --follow`) will show an error, X Error of failed request: BadAccess (attempt to access private resource denied) which indicates that the shell was unable to start xmonad because another window manager is already running (namely, the nixos-configured xmonad). https://wiki.haskell.org/Xmonad/Frequently_asked_questions#X_Error_of_failed_request:_BadAccess_.28attempt_to_access_private_resource_denied.29 Changing the mod+q operation to `restart "xmonad" True` (as recommended in the "config" option's description) will allow a restart of the nixos-configured xmonad to be triggeredy by hitting mod+q. Finally, if the entrypoint is 'XMonad.launch', mod+q has been bound to `restart "xmonad" True` and another key bound to a custom recompile/restart function (e.g. `compileRestart` as shown in the "config" option example), the user can switch between the nixos module's config and their local config, with the custom key switching to the local config and mod+q switching back. * nixos/xmonad: refactor let binding * nixos/xmonad: refactor (eliminate duplicate code) * nixos/xmonad: install man pages Prior to this commit, man pages were not installed if the "config" option was set. * nixos/xmonad: comment grammar fixups * nixos/xmonad: writeStateToFile in example config Calling writeStateToFile prior to recompiling and restarting allows state (workspaces, etc.) to be preserved across the restart. * nixos/xmonad: add ivanbrennan to maintainers * nixos/xmonad: adjust compileRestart example * nixos/xmonad: add missing import to example config
2020-12-28 16:27:36 +00:00
--set XMONAD_XMESSAGE "${pkgs.xorg.xmessage}/bin/xmessage"
'');
2018-11-28 22:08:20 +00:00
xmonad = if (cfg.config != null) then xmonad-config else xmonad-vanilla;
in {
meta.maintainers = with maintainers; [ lassulus xaverdh ivanbrennan slotThe ];
options = {
services.xserver.windowManager.xmonad = {
enable = mkEnableOption (lib.mdDoc "xmonad");
2021-12-07 17:36:11 +00:00
haskellPackages = mkOption {
default = pkgs.haskellPackages;
defaultText = literalExpression "pkgs.haskellPackages";
example = literalExpression "pkgs.haskell.packages.ghc810";
2021-12-07 17:36:11 +00:00
type = types.attrs;
description = lib.mdDoc ''
haskellPackages used to build Xmonad and other packages.
This can be used to change the GHC version used to build
Xmonad and the packages listed in
{var}`extraPackages`.
'';
};
extraPackages = mkOption {
type = types.functionTo (types.listOf types.package);
default = self: [];
defaultText = literalExpression "self: []";
example = literalExpression ''
haskellPackages: [
haskellPackages.xmonad-contrib
haskellPackages.monad-logger
]
'';
description = lib.mdDoc ''
Extra packages available to ghc when rebuilding Xmonad. The
value must be a function which receives the attrset defined
in {var}`haskellPackages` as the sole argument.
'';
};
enableContribAndExtras = mkOption {
default = false;
type = lib.types.bool;
description = lib.mdDoc "Enable xmonad-{contrib,extras} in Xmonad.";
};
2018-11-28 22:08:20 +00:00
config = mkOption {
default = null;
type = with lib.types; nullOr (either path str);
2018-11-28 22:08:20 +00:00
description = lib.mdDoc ''
2020-10-12 10:18:26 +00:00
Configuration from which XMonad gets compiled. If no value is
specified, a vanilla xmonad binary is put in PATH, which will
attempt to recompile and exec your xmonad config from $HOME/.xmonad.
This setup is then analogous to other (non-NixOS) linux distributions.
If you do set this option, you likely want to use "launch" as your
XMonad: configured recompile (#107696) * nixos/xmonad: xmonad config w/ghc+xmessage When the "config" option isn't set, we use xmonad-with-packages to provide xmonad with runtime access to an isolated ghc, ensuring it can recompile and exec a user's local config (e.g. $HOME/.xmonad/xmonad.hs) regardless of which ghc (if any) is on PATH. When the "config" option is set, however, we compile a configured xmonad executable upfront (during nixos-rebuild), and prior to this commit, it was not provided with runtime access to an isolated ghc. As a result, with the "config" option set, it was not possible to recompile and exec a user's local config unless there was a compatible version of ghc on PATH with the necessary packages (xmonad, xmonad-contrib, etc.) in its package database. Adding such a ghc to environment.systemPackages, e.g. (haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib])) is problematic because it adds both ghc and an unconfigured xmonad to PATH, e.g. $ ls -l $(which xmonad ghc) lrwxrwxrwx ... /run/current-system/sw/bin/ghc -> /nix/store/...-ghc-8.10.2-with-packages/bin/ghc lrwxrwxrwx ... /run/current-system/sw/bin/xmonad -> /nix/store/...-ghc-8.10.2-with-packages/bin/xmonad Having the unconfigured xmonad on PATH is particularly bad because restarting xmonad will dump the user into the unconfigured version, and if no local config exists (e.g. in $HOME/.xmonad/xmonad.hs), they'll be left in this unconfigured state. In this commmit, we give the configured xmonad runtime access to ghc like xmonad-with-packages does for the unconfigured version. The aim is to allow the user to switch between the nixos module's config and a local config (e.g. $HOME/.xmonad/xmonad.hs) at will, so they can try out config changes without performing a nixos-rebuild. Since the xmonad on PATH is the configured executable, there's no danger a user could unwittingly restart into the unconfigured version, and because xmonad will refuse to recompile when no local config exists, there's no danger a user could unwittingly recompile into an unconfigured version. Given that a local config exists, the recompile/restart behavior depends on two factors: - which entry point is used * 'XMonad.xmonad' (default) * 'XMonad.launch' (recommended in "config" option description) - what operation is triggered (i.e. via mod+q) * `spawn "xmonad --recompile && xmonad --restart"` (default) * `restart "xmonad" True` * custom function If the default 'XMonad.xmonad' entrypoint and default mod+q operation are used, hitting mod+q will compile and exec the local config, which will remain in use until next time the display manager is restarted. If the entrypoint is changed to 'XMonad.launch' but mod+q left with its default operation, hitting mod+q will have no visible effect. The logs (as seen by running `journalctl --identifier xmonad --follow`) will show an error, X Error of failed request: BadAccess (attempt to access private resource denied) which indicates that the shell was unable to start xmonad because another window manager is already running (namely, the nixos-configured xmonad). https://wiki.haskell.org/Xmonad/Frequently_asked_questions#X_Error_of_failed_request:_BadAccess_.28attempt_to_access_private_resource_denied.29 Changing the mod+q operation to `restart "xmonad" True` (as recommended in the "config" option's description) will allow a restart of the nixos-configured xmonad to be triggeredy by hitting mod+q. Finally, if the entrypoint is 'XMonad.launch', mod+q has been bound to `restart "xmonad" True` and another key bound to a custom recompile/restart function (e.g. `compileRestart` as shown in the "config" option example), the user can switch between the nixos module's config and their local config, with the custom key switching to the local config and mod+q switching back. * nixos/xmonad: refactor let binding * nixos/xmonad: refactor (eliminate duplicate code) * nixos/xmonad: install man pages Prior to this commit, man pages were not installed if the "config" option was set. * nixos/xmonad: comment grammar fixups * nixos/xmonad: writeStateToFile in example config Calling writeStateToFile prior to recompiling and restarting allows state (workspaces, etc.) to be preserved across the restart. * nixos/xmonad: add ivanbrennan to maintainers * nixos/xmonad: adjust compileRestart example * nixos/xmonad: add missing import to example config
2020-12-28 16:27:36 +00:00
entry point for xmonad (as in the example), to avoid xmonad's
2020-10-12 10:18:26 +00:00
recompilation logic on startup. Doing so will render the default
"mod+q" restart key binding dysfunctional though, because that attempts
to call your binary with the "--restart" command line option, unless
you implement that yourself. You way mant to bind "mod+q" to
`(restart "xmonad" True)` instead, which will just restart
XMonad: configured recompile (#107696) * nixos/xmonad: xmonad config w/ghc+xmessage When the "config" option isn't set, we use xmonad-with-packages to provide xmonad with runtime access to an isolated ghc, ensuring it can recompile and exec a user's local config (e.g. $HOME/.xmonad/xmonad.hs) regardless of which ghc (if any) is on PATH. When the "config" option is set, however, we compile a configured xmonad executable upfront (during nixos-rebuild), and prior to this commit, it was not provided with runtime access to an isolated ghc. As a result, with the "config" option set, it was not possible to recompile and exec a user's local config unless there was a compatible version of ghc on PATH with the necessary packages (xmonad, xmonad-contrib, etc.) in its package database. Adding such a ghc to environment.systemPackages, e.g. (haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib])) is problematic because it adds both ghc and an unconfigured xmonad to PATH, e.g. $ ls -l $(which xmonad ghc) lrwxrwxrwx ... /run/current-system/sw/bin/ghc -> /nix/store/...-ghc-8.10.2-with-packages/bin/ghc lrwxrwxrwx ... /run/current-system/sw/bin/xmonad -> /nix/store/...-ghc-8.10.2-with-packages/bin/xmonad Having the unconfigured xmonad on PATH is particularly bad because restarting xmonad will dump the user into the unconfigured version, and if no local config exists (e.g. in $HOME/.xmonad/xmonad.hs), they'll be left in this unconfigured state. In this commmit, we give the configured xmonad runtime access to ghc like xmonad-with-packages does for the unconfigured version. The aim is to allow the user to switch between the nixos module's config and a local config (e.g. $HOME/.xmonad/xmonad.hs) at will, so they can try out config changes without performing a nixos-rebuild. Since the xmonad on PATH is the configured executable, there's no danger a user could unwittingly restart into the unconfigured version, and because xmonad will refuse to recompile when no local config exists, there's no danger a user could unwittingly recompile into an unconfigured version. Given that a local config exists, the recompile/restart behavior depends on two factors: - which entry point is used * 'XMonad.xmonad' (default) * 'XMonad.launch' (recommended in "config" option description) - what operation is triggered (i.e. via mod+q) * `spawn "xmonad --recompile && xmonad --restart"` (default) * `restart "xmonad" True` * custom function If the default 'XMonad.xmonad' entrypoint and default mod+q operation are used, hitting mod+q will compile and exec the local config, which will remain in use until next time the display manager is restarted. If the entrypoint is changed to 'XMonad.launch' but mod+q left with its default operation, hitting mod+q will have no visible effect. The logs (as seen by running `journalctl --identifier xmonad --follow`) will show an error, X Error of failed request: BadAccess (attempt to access private resource denied) which indicates that the shell was unable to start xmonad because another window manager is already running (namely, the nixos-configured xmonad). https://wiki.haskell.org/Xmonad/Frequently_asked_questions#X_Error_of_failed_request:_BadAccess_.28attempt_to_access_private_resource_denied.29 Changing the mod+q operation to `restart "xmonad" True` (as recommended in the "config" option's description) will allow a restart of the nixos-configured xmonad to be triggeredy by hitting mod+q. Finally, if the entrypoint is 'XMonad.launch', mod+q has been bound to `restart "xmonad" True` and another key bound to a custom recompile/restart function (e.g. `compileRestart` as shown in the "config" option example), the user can switch between the nixos module's config and their local config, with the custom key switching to the local config and mod+q switching back. * nixos/xmonad: refactor let binding * nixos/xmonad: refactor (eliminate duplicate code) * nixos/xmonad: install man pages Prior to this commit, man pages were not installed if the "config" option was set. * nixos/xmonad: comment grammar fixups * nixos/xmonad: writeStateToFile in example config Calling writeStateToFile prior to recompiling and restarting allows state (workspaces, etc.) to be preserved across the restart. * nixos/xmonad: add ivanbrennan to maintainers * nixos/xmonad: adjust compileRestart example * nixos/xmonad: add missing import to example config
2020-12-28 16:27:36 +00:00
xmonad from PATH. This allows e.g. switching to the new xmonad binary
2020-10-12 10:18:26 +00:00
after rebuilding your system with nixos-rebuild.
For the same reason, ghc is not added to the environment when this
option is set, unless {option}`enableConfiguredRecompile` is
set to `true`.
2020-10-12 10:18:26 +00:00
If you actually want to run xmonad with a config specified here, but
also be able to recompile and restart it from a copy of that source in
$HOME/.xmonad on the fly, set {option}`enableConfiguredRecompile`
to `true` and implement something like "compileRestart"
from the example.
2020-10-12 10:18:26 +00:00
This should allow you to switch at will between the local xmonad and
the one NixOS puts in your PATH.
2018-11-28 22:08:20 +00:00
'';
example = ''
import XMonad
2020-10-12 10:18:26 +00:00
import XMonad.Util.EZConfig (additionalKeys)
XMonad: configured recompile (#107696) * nixos/xmonad: xmonad config w/ghc+xmessage When the "config" option isn't set, we use xmonad-with-packages to provide xmonad with runtime access to an isolated ghc, ensuring it can recompile and exec a user's local config (e.g. $HOME/.xmonad/xmonad.hs) regardless of which ghc (if any) is on PATH. When the "config" option is set, however, we compile a configured xmonad executable upfront (during nixos-rebuild), and prior to this commit, it was not provided with runtime access to an isolated ghc. As a result, with the "config" option set, it was not possible to recompile and exec a user's local config unless there was a compatible version of ghc on PATH with the necessary packages (xmonad, xmonad-contrib, etc.) in its package database. Adding such a ghc to environment.systemPackages, e.g. (haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib])) is problematic because it adds both ghc and an unconfigured xmonad to PATH, e.g. $ ls -l $(which xmonad ghc) lrwxrwxrwx ... /run/current-system/sw/bin/ghc -> /nix/store/...-ghc-8.10.2-with-packages/bin/ghc lrwxrwxrwx ... /run/current-system/sw/bin/xmonad -> /nix/store/...-ghc-8.10.2-with-packages/bin/xmonad Having the unconfigured xmonad on PATH is particularly bad because restarting xmonad will dump the user into the unconfigured version, and if no local config exists (e.g. in $HOME/.xmonad/xmonad.hs), they'll be left in this unconfigured state. In this commmit, we give the configured xmonad runtime access to ghc like xmonad-with-packages does for the unconfigured version. The aim is to allow the user to switch between the nixos module's config and a local config (e.g. $HOME/.xmonad/xmonad.hs) at will, so they can try out config changes without performing a nixos-rebuild. Since the xmonad on PATH is the configured executable, there's no danger a user could unwittingly restart into the unconfigured version, and because xmonad will refuse to recompile when no local config exists, there's no danger a user could unwittingly recompile into an unconfigured version. Given that a local config exists, the recompile/restart behavior depends on two factors: - which entry point is used * 'XMonad.xmonad' (default) * 'XMonad.launch' (recommended in "config" option description) - what operation is triggered (i.e. via mod+q) * `spawn "xmonad --recompile && xmonad --restart"` (default) * `restart "xmonad" True` * custom function If the default 'XMonad.xmonad' entrypoint and default mod+q operation are used, hitting mod+q will compile and exec the local config, which will remain in use until next time the display manager is restarted. If the entrypoint is changed to 'XMonad.launch' but mod+q left with its default operation, hitting mod+q will have no visible effect. The logs (as seen by running `journalctl --identifier xmonad --follow`) will show an error, X Error of failed request: BadAccess (attempt to access private resource denied) which indicates that the shell was unable to start xmonad because another window manager is already running (namely, the nixos-configured xmonad). https://wiki.haskell.org/Xmonad/Frequently_asked_questions#X_Error_of_failed_request:_BadAccess_.28attempt_to_access_private_resource_denied.29 Changing the mod+q operation to `restart "xmonad" True` (as recommended in the "config" option's description) will allow a restart of the nixos-configured xmonad to be triggeredy by hitting mod+q. Finally, if the entrypoint is 'XMonad.launch', mod+q has been bound to `restart "xmonad" True` and another key bound to a custom recompile/restart function (e.g. `compileRestart` as shown in the "config" option example), the user can switch between the nixos module's config and their local config, with the custom key switching to the local config and mod+q switching back. * nixos/xmonad: refactor let binding * nixos/xmonad: refactor (eliminate duplicate code) * nixos/xmonad: install man pages Prior to this commit, man pages were not installed if the "config" option was set. * nixos/xmonad: comment grammar fixups * nixos/xmonad: writeStateToFile in example config Calling writeStateToFile prior to recompiling and restarting allows state (workspaces, etc.) to be preserved across the restart. * nixos/xmonad: add ivanbrennan to maintainers * nixos/xmonad: adjust compileRestart example * nixos/xmonad: add missing import to example config
2020-12-28 16:27:36 +00:00
import Control.Monad (when)
2020-10-12 10:18:26 +00:00
import Text.Printf (printf)
import System.Posix.Process (executeFile)
import System.Info (arch,os)
import System.Environment (getArgs)
import System.FilePath ((</>))
compiledConfig = printf "xmonad-%s-%s" arch os
myConfig = defaultConfig
{ modMask = mod4Mask -- Use Super instead of Alt
, terminal = "urxvt" }
`additionalKeys`
[ ( (mod4Mask,xK_r), compileRestart True)
, ( (mod4Mask,xK_q), restart "xmonad" True ) ]
compileRestart resume = do
dirs <- asks directories
whenX (recompile dirs True) $ do
when resume writeStateToFile
catchIO
( do
args <- getArgs
executeFile (cacheDir dirs </> compiledConfig) False args Nothing
)
main = getDirectories >>= launch myConfig
--------------------------------------------
{- For versions before 0.17.0 use this instead -}
--------------------------------------------
-- compileRestart resume =
-- whenX (recompile True) $
-- when resume writeStateToFile
-- *> catchIO
-- ( do
-- dir <- getXMonadDataDir
-- args <- getArgs
-- executeFile (dir </> compiledConfig) False args Nothing
-- )
--
-- main = launch myConfig
--------------------------------------------
2018-11-28 22:08:20 +00:00
'';
};
enableConfiguredRecompile = mkOption {
default = false;
type = lib.types.bool;
description = lib.mdDoc ''
Enable recompilation even if {option}`config` is set to a
non-null value. This adds the necessary Haskell dependencies (GHC with
packages) to the xmonad binary's environment.
'';
};
xmonadCliArgs = mkOption {
default = [];
type = with lib.types; listOf str;
description = lib.mdDoc ''
Command line arguments passed to the xmonad binary.
'';
};
ghcArgs = mkOption {
default = [];
type = with lib.types; listOf str;
description = lib.mdDoc ''
Command line arguments passed to the compiler (ghc)
invocation when xmonad.config is set.
'';
};
};
};
config = mkIf cfg.enable {
services.xserver.windowManager = {
session = [{
name = "xmonad";
start = ''
systemd-cat -t xmonad -- ${xmonad}/bin/xmonad ${lib.escapeShellArgs cfg.xmonadCliArgs} &
waitPID=$!
'';
}];
};
environment.systemPackages = [ xmonad ];
};
}