Global Options

[minikN]

Introduction

The idea would be to change the way how ordenada modules interact with each other.

Currently, if module x is enabled, it may add configuration to module y. An example would be how the password-store module adds some emacs configuration if that feature is also enabled. I think this approach is totally fine in most cases and I wouldn't change it for those.

However there are also cases where a module defines "something", that could be considered "global". A couple of examples would be:

• sway module sets the windowManager
• password-store module sets the passwordManager
• bemenu module sets the applicationLauncher
• bash/zsh modules set the shell (we don't have these modules yet, but same idea)
• waybar module sets the bar
• ...

windowManager, shell, applicationLauncher, ect. are things that I'd consider global. For these cases, instead of the module (e.g. bemenu) directly adding configuration to another module (e.g. sway), I think ordenada should do that itself. It should provide the binding between these " global" modules and the ones they'll affect.

The reason is that this would minimize implicit inter-module dependencies as well as giving us the opportunity to mix and match these modules according to the current configuration state.

Examples

Let's say we maintain these options under the ordenada.globals namespace (which should never be set by the user directly)

Window Managers

If sway module is enabled, it'll set

• wayland: true,
• wm: <sway exec cmd>
• If ordenada.globals.applicationLauncher is set by anothet module, it'll add the value to its config with a key binding.

If i3 module is enabled (don't have it yet) it'll set

• wayland: false,
• wm: <i3 exec cmd>
• If ordenada.globals.applicationLauncher is set by anothet module, it'll add the value to its config with a key binding

Bars

If bemenu module is enabled, it'll set

• applicationLauncher: <bemenu exec cmd>
• (It'll not set sway config directly as it does now)

If wofi (wayland port of rofi) module (don't have it yet) is enabled, it'll set

• applicationLauncher: <wofi exec cmd>
• (It'll not set sway config directly)

If rofi module (don't have it yet) is enabled, it'll set

• applicationLauncher: <rofi exec cmd>
• (It'll not set i3 config directly)

Use Cases

Now with these (hypothetical) modules in place, a couple of scenarios:

• We can get rid of autoStartTty option in sway module, and maybe move it to home module(as autoStartWmOnTty), it can simply execute whatever ordenada.globals.wm is

• If user enables sway and bemenu modules, bemenu module will set ordenada globals.applicationLauncher, sway will read its value and creates keybinding

• If user enables sway and wofi, same as above

• If user enables i3 and bemenu, same as above since bmenu works for both x11 and wayland

• If user enables sway and rofi, we'll error out, because sway module set wayland to true, but rofi only works on x11

• If user enables to modules that both set the same global, we'll also error out, that's not allowed (we can set default value of the option to null and check for thay from the modules that set it, if it's not null we can use builtins.abort I believe.

You can see that with a setup like this, if we develop a new module, like lets say one for hyprland, it'll integrate seemlessly as long as it takes the same globals into consideration.

[migalmoreno]

Really like the idea overall! This is something we're currently missing from RDE, which exposes these kinds of "globals" via feature values. I hadn't gotten around it yet, as most of the "globals" currently have only one feature available (except for pass/age which are rarely used together), but I fully agree in that it will make feature interdependence much simpler.

Does this implementation take into consideration having many tools with conflicting utilities installed at once? Let's say I want to use Rofi as an application launcher and keep bemenu for pinentry input, how would we signal to Ordenada that we want to "activate" certain globals from the former (e.g. ordenada.globals.applicationLauncher but not pinentry) while others (ordenada.globals.pinentry but not application launcher) from the latter? Perhaps in those cases we wouldn't want to forbid users from setting them manually, or we could try to use NixOS options priorities to give certain globals some particular priority.

[minikN]

First implementation as part of #9 .