💾 Archived View for park-city.club › ~invis › phlog › 030-guis-are-better.txt captured on 2022-07-16 at 14:48:28.
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
# GUIs are Better hello it is literally three in the morning and i cannot sleep so i am gonna complain about linux and terminals and that sorta stuff some. this might be a full article, maybe not, i just need to get these thoughts down. ## Overview of a console application Command-line interfaces have been around since the teletype. You know, when "print" in your programming language literally caused text to come out of a glorified typewriter. Teletypewriters are very bad at doing any sort of graphics since, ya know, it's a freaking typewriter. So all the input and output is in text, typically English or whatever the local language of the computer is. UNIX, an early time-sharing operating system that kinda became the basis of every single modern computing environment besides Windows, took this and ran with it. Every single program took text in, and returned text out. (At least, on paper. Lots of programs read or wrote separate files, then there's daemons and X11 applications and a whole load of hairy edge-cases but let's ignore that for now.) So, let's take `sort` as an example. You get a file from the disk, probably with `cat` (concatenate), then you "pipe" it into `sort` to sort the file, and then you "redirect" that to a new file. So that would look like `cat file.txt | sort > sorted.txt' (yes, this is an useless use of cat. no, i don't care.) And, you see, this works, assuming that you are only ever working with plain text in neatly separate lines. Sometimes you get files with columns, representing tables of numerical data. CSVs, fixed-field formats, etc. To wrangle those around, you get tools like `sed` and `awk`. These are almost incomprehensible unless you're a computer programmer, because they're literally stripped-down programming languages. And if you're dealing with JSON or XML or binary files, you can just forget that. You see, one of the fundamental issues with a standard UNIX-like command line interface is that the inputs and outputs don't have *types* associated with them. It's just text. But that text can be in any shape, and that text can't easily be turned into commandline flags (that requires xargs, i think) or restructured without awk or sed or perl. But of course, that also assumes that piping data between programs is a normal usage. That's the UNIX philosphy, or at least the part everyone quotes. Small, simple programs that do one thing and can be chained together. Over in MS-DOS or CP/M land, they had *some* of the piping and redirection tools, but largely people used large software suites that did everything. Turns out, something like WordStar is a much more effective word processor than `vi` and `sed`. But fine, GUIs and TUIs are the big monolithic things. CLI programs are the small or at least constrained things that you chain together. They're the best tool for that job. ...right? ## A very, very quick primer on GUI programming So GUIs are interesting to program. (This is largely coming from a Win32 perspective, as I have the most familiarity with that API, although this is pretty universal for non-JS GUI toolkits.) Let's start with the example of a simple form. It's filled with a bunch of "controls" or "widgets". You input data into them, and they can be validated against known bounds or contraints on the fly. When everything is okay, you press the "OK" button which does some action. This is a very interesting model because it's doing EXACTLY what a command-line application is, but with more information given to the user on WHAT arguments can be given. In fact, there's some libraries like "Gooey" for Python that automate this process for you. What's really neat is that the controls can be displayed in various formats to convey the expected purpose of the argument. (ex: sliders vs. number boxes for loose / precise control of numerical values.) And, because each individual control can validate its contents, it's fairly easy to catch and pinpoint errors in data entry before the main action even starts. But that's kind of a snoozefest. It doesn't really matter, we're not doing anything yet that `--help` can't do. But there's more than meets the eye here. You see, that "OK" button or those input validators aren't just calling functions. They're firing EVENTS. And that's exactly what makes a GUI tick. For example, a grapical Windows program, after initialization stuff, enters what's known as a "message loop". Here, the program waits until the application has received some event, like "key pressed" or "window closed". Then it dispatches to the correct subroutine to handle that case. This may start a procedure in a new thread, which allows for the application to continue receiving event messages while work is done in the background. No command-line application does that, aside from maybe REPL environments like `python` or `perl`. Command-line applications are very much a data-in, data-out deal. Long-running server processes are a bit of a hack on UNIX, involving some weird variation of `nohup` or crontabs or systemd services or the like. Meanwhile, GUI applications are always designed to run on an event-driven model. This, obviously, is great for interactive purposes. But wait, there's more. It doesn't necessarily have to be the user that fires these events. It can be scripts! The best example of this is AppleScript, the scripting language that Apple introduced with System 7 and still supports. That can interact with standard windows and the built-in control types without a hitch using something resembling natural language. Some applications can even provide support for interacting with custom object types, like graphics or words on a page. So, in a properly designed application, the "bold" button on the toolbar and the AppleScript command to make a word bold are just two ways to call the same internal function. And using this event-driven object model, it's possible to script things at a much, much greater and more sophisticated level than you ever could with a CLI. This is especially true when you use other standards like OLE or whatever Apple's equivalent was to pass data between applications, as opposed to raw text for everything. You could in theory resize an image in one application and then copy that to a desktop publishing document for placement just with scripts. ...that said, in practice nobody actually did most of these things. The cost of making these events public was too much until the Cocoa API in Mac OS X. Windows never had a good equivalent to this. Linux is actually mildly intersting, in that these sorts of things can (and sometimes are) exposed via D-Bus. (The Kalligra suite is a very good example of this, I've noticed.) so, uh, yeah. GUIs. They let you have strict definitions for inputs, run multiple tasks asynchronusly on one document, and let you script on a finer-grained and level with better support for specific features of specific file formats than the CLI. CLIs really should be replaced, imo, with a programming interface for these scriptable actions. Something like PowerShell, actually. That's super interesting, because it runs on top of .NET, has input/output types like tables and JSON, and integrates well with other applications. it's four in the morning i really should try to sleep now.