Hacker News Reader

Hacker News

Comment by ngetchell | Hacker News Reader

Parent Full thread

ngetchell

PowerShell has a Show-Command cmdlet that dynamically generates a GUI based on the cmdlet parameters.

Quick and dirty GUIs

https://ngetchell.com/poor-mans-gui/

View on HN

Amazing! Does anyone know of a comparable toolkit for quick UI’s (gui or tui) in the linux/bash ecosystem?

There's zenity, but I think it's not as featureful (I may be wrong there)

If Zenity is not featureful enough for whatever you're trying to do, there's always Gtk-server (https://www.gtk-server.org/intro.html) as well.

I'd imagine power shell has some way to pull the available parameters out of cmdlets (they probably all inherit from some cmdlet class or something.) On bash you have to get this from somewhere else.

I think it also helps that PowerShell treats everything as objects and can pass them in pipes.

If bash had some way to specify that a command is "pure" (doesn't mutate anything) you could do this there (among other nice things.)

Apple's A/UX had "commando" - but I think these were manually-defined instead of dynamically generated (whereas PowerShell cmds all export their own parameter definitions so PowerShell can dynamically generate UIs): http://toastytech.com/guis/aux3.html

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>.

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.

Uhm… would that work using powershell in gnu/linux?

Docs say it's Windows only, sadly. Shouldn't be too hard to implement the same on another toolkit, although maybe upstream isn't interested in maintaining it.

Reply on news.ycombinator.com