Hacker News new | ask | show | jobs
by K0SM0S 1470 days ago
Maybe it's because I've discovered it recently enough and I'm quite amazed at the possibilities, but I really think this is a great project for (using) Nix (even NixOS itself in desktop mode).

Here's my rough intuition.

1. Nix brings immutable packages (static, read-only), versioned as you wish to target various dependencies. (the `/nix` folder)

2. This means the goal is to create once and for all a GUI for each command, a static view.

3. Meanwhile, the Nix ecosystem is heavily curated yet quite expansive (some 60k+ pkgs IIRC), and a decentralized part is evolving towards an AUR-like mindset (the NUR, Nix User Repository). These are the people you want to polish a good-enough-but-not-perfect GUI automation tool. Remember, it's a one-off, since each version is static, forever in Nix (thus presumably shared by all users).

4. An intuitively natural design to me seems to split the auto-GUI tool process in 3 steps:

- Parse and encode some `man` or `--help` output (probably needs a well-defined sub-spec to make perfect parsing predictable by devs targeting Nix). Generate some .gui_spec file.

- Read a .gui_conf file that overrides defaults (empty = defaults). This is where maintainers, designers and curators can rectify the auto-gui tool once and for all on a need-to basis. End-users may override this vendor-provided config in their home environment (notably to auto-apply DE theming parameters, etc).

- Generate final GUI executable for target env (should work in X/Wayland but also as a barebones terminal app with optional mouse support).

Basically, heavy lifting is done upstream by following a standardized auto-GUI specification (some DSL to call it bluntly, that happens to look like `man` + descriptors), and there is one layer of "good steward" curation before the recipe gets properly rendered by end-users' DE (+ optional local customization).

The point is to add as little extra work as possible every step of the way (if possible, none) by leveraging existing structures (man, nix, term/X/DE conventions, …) to apply "great defaults" automagically enough.

I'm pretty sure this is the next-level tldr and a killer feature at the tip of a shortcut for <insert cool shell>.

1 comments

If I'm not mistaken, that's basically how shell completions work in Nix. At least for fish. Package derivations can include completion scripts at a special location. Users can override the provided completions either in their shell init file or using an overlay over the package. And in lieu of a manually written completion, at least fish can parse man pages and turn that into completions.