Using HTML means I can start off with plain HTML and no style (except user-agent) and keep building on it (change font, center it in the page, etc.). I can keep HTML, JS, CSS on the same page, add AlpineJS if I need a reactive UI and so on.
how come? doesn't window.close() work for you?
...take the action you wanted...
<button onclick="(event) => save(event)">
> This method can only be called on windows that were opened by a script using the Window.open() method.
I was unable to get `window.close()` to work on root windows, but your comment prompted me research it again. This seems to work:
Edit: If I need GUI in my scripts, I'd probablyjust use dialog and other curses stuff.
The OpenBSD installer follows it, for example, and makes for a very simple interaction. When SSHing to a remote host, it's quite snappy , and has no drawing overhead.
dialog is an option but is quite limited in what you can do.
There are many alternatives, and this is just another one to choose from.
Depending on where your script is required to run, a Rust tool might not be a problem. Not all shell scripts need to be super portable.
I don't believe Cargo install is meant to be used as a general purpose distribution tool; though I know it's tempting to bypass the package manager especially when it's so easy.
From what I understand cargo install is supposed to help around rust ecosystem tooling such as installing clippy, xargo and rls, where cargo has much more context than the package manager.
From the RFC the motivations for `cargo install` existing:
> Simple tasks like installing a new cargo subcommand, installing an editor plugin, etc,
It's not perfect though, and I think we're going to try to create binaries for download alternatively.
Zenity is also an option.
But the system UI that is also linked in there is something that goes beyond what you can do with e.g. zenity.
This kind of puts (almost) all the power of a modern UI description language in reach of shell scripts.
There's not really much to it; it's just an example of extending ksh with more builtins, which is simple by design. (I really miss what this did for Sun's dbx debugger — instead of being inside some tool with yet another idiosyncratic command language, your shell just grew commands for interacting with the process being debugged.)
Thank you kindly.
This particular approach (.60) is not a general purpose programming language and it's strongly typed.
It's designed for the user interface, not for writing the rest of the program in it.
I feel this is rather different from the tcl/tk applications we used to see?
The problem is that current generations cannot see beyond their vi/emacs CLI setups and are too invested into HTML/CS/JS stacks to see otherwise.
Some quickly picked examples,
"Smalltalk usage for UI prototyping in Thales industrial context"
"Interface Builder's Alternative Lisp Timeline"
Which by the way, makes the binding Objective-C / Smalltalk /Lisp in UI design.
Not sure users who prefer a GUI over the command line, would be too happy about having to fix compile errors prior to running the program?
Right now there is not, but work is being done to cover the common platforms.
Pendergrast's shell was included in the CDE standard, directly accesses Motif and X11 primitives, and builds on modern systems.
The source code is in this collection:
Can communicate using nine IPC mechanisms AND as a loadable library with a small C API.
Also, if you're running a Gtk desktop, it obviously obeys your Gtk theme.
Although why you'd go for a lower level language if you don't have to for some specific reason is beyond me. GUIs specifically have been historically very friendly towards very high level languages - see Tcl/Tk.
Also, by your logic, shell scripts should never use pipes; you should always use pipes from Python or Go or Rust. But I suspect that's not how other people usually think.
Also, we're specifically talking about shell scripts.
I'd argue that if you're implementing an entire protocol into a shell script, yes, you should consider more efficient languages. If you're just dumping data into a pipe like you would to std out, sure that's fine.
The key here, at least for me, is complexity. Are you bludgeoning shell scripts into something it wasn't meant for? Is there a better alternative meant to do the thing you're doing?