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

167 lines
5.9 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 literalExample;
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 ];
} ''
install -D ${xmonadEnv}/share/man/man1/xmonad.1.gz $out/share/man/man1/xmonad.1.gz
makeWrapper ${configured}/bin/xmonad $out/bin/xmonad \
--set NIX_GHC "${xmonadEnv}/bin/ghc" \
--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 {
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
meta.maintainers = with maintainers; [ lassulus xaverdh ivanbrennan ];
options = {
services.xserver.windowManager.xmonad = {
enable = mkEnableOption "xmonad";
haskellPackages = mkOption {
default = pkgs.haskellPackages;
defaultText = "pkgs.haskellPackages";
example = literalExample "pkgs.haskell.packages.ghc784";
description = ''
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
<varname>extraPackages</varname>.
'';
};
extraPackages = mkOption {
default = self: [];
defaultText = "self: []";
example = literalExample ''
haskellPackages: [
haskellPackages.xmonad-contrib
haskellPackages.monad-logger
]
'';
description = ''
Extra packages available to ghc when rebuilding Xmonad. The
value must be a function which receives the attrset defined
in <varname>haskellPackages</varname> as the sole argument.
'';
};
enableContribAndExtras = mkOption {
default = false;
type = lib.types.bool;
description = "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 = ''
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
<literal>(restart "xmonad" True)</literal> 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.
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, you will have to implement that yourself
using something like "compileRestart" from the example.
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
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
compileRestart resume =
whenX (recompile True) $
when resume writeStateToFile
*> catchIO
( do
dir <- getXMonadDataDir
args <- getArgs
executeFile (dir </> compiledConfig) False args Nothing
)
2018-11-28 22:08:20 +00:00
main = launch defaultConfig
2020-10-12 10:18:26 +00:00
{ modMask = mod4Mask -- Use Super instead of Alt
, terminal = "urxvt" }
`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
[ ( (mod4Mask,xK_r), compileRestart True)
2020-10-12 10:18:26 +00:00
, ( (mod4Mask,xK_q), restart "xmonad" True ) ]
2018-11-28 22:08:20 +00:00
'';
};
xmonadCliArgs = mkOption {
default = [];
type = with lib.types; listOf str;
description = ''
Command line arguments passed to the xmonad binary.
'';
};
ghcArgs = mkOption {
default = [];
type = with lib.types; listOf str;
description = ''
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 ];
};
}