Boxer

Boxer was an innovative low-floor programming environment & language, with a goal no less than bringing computational literacy to the masses. It gave names to some interesting ideas:

Naive realism

What the computational model manipulates is what you can see and manipulate on the screen. Things such as variables, scopes, stack frames all could be seen (and modified)! [Well, under the hood things were optimized but invisibly to the user]

"Detuning"

You know how Python, Lua, JS etc. proved arrays + hashes are enough for 99% needs? They might not be perfectly tuned for any task but there is value in few constructs serving wide needs.

Boxer made small variations on a single structure — "box" that may contain text and other boxes — play so many roles:

from "programming" concepts: - procedure - variable - scope - module (same thing as scope, I'm listing it separately because most other languages do make a distinction between in-file scopes and cross-file modularity) - data structures - record with named sub-boxes - horizontal/vertical/2D arrangement of boxes etc... - OOP object — just `ask` a scope with variables and named procedures to eval some command in that context - call stack — during execution, procedures are inlined at the place they were called to "everyday use" functionality (Boxer is all about eroding this user/programmer boundary, I'm splitting them like this to emphasize it _is_ surprising the "box" structure spans this range :clap:): - collapsible outline element - document - folder - application - There is no difference between OOP object and application! If a box contains state & procedures, you can double-click the procedures (or individual code lines) to execute them. - BUT, the interface is "reconstructible". Any event (key press, click etc) is looked up according to regular scoping rules outward from the event location, so a box may re-define the interface in that area of Boxer (and all its sub-boxes), thus becoming a "distinct application".

grapher app

=> I want to a boxer-like window manager

I love this tight design, and I want Boxer's spatial organization, but Boxer is an isolated world, and I don't know how to evolve it into something that integrates much with external things without losing its everything-is-a-visible-box nature...
(The main direction I can imagine is Emacs, but we already have Emacs.)

Unix CLI as basis for "computational literacy"

People love critisizing the Unix terminal as outdated, but it has a unique precious quality — it's the only major ecosystem, widely used by professionals, where the main mode of interactions with "apps" is textual. Any¹ action you can take, you can put in a text "script" and automate. So the barrier between everyday use and programming is minimal.

¹ not true for full-screen terminal apps like less, top or tmux, and obviously not for GUI X apps. Still, there is rich tradition of those apps exposing some level of CLI control. More to the point, people keep developing pure CLI commands whose interface is the shell!

So, let's apply naive realism to Unix! Instead of asking how to extend boxer's language to interact with external applications, I'll take the existing glue between programs — file system and shell commands — as the reality of the system. Instead of Boxer's low-floor-but-powerful direction, I'm coming from the high-ceiling-but-distilled direction. And there is huge gap for sure, so the system will NOT address the same audience of computing newbies.

Unix is inherently polyglot. The need to serialize everything to the "narrow waist" of byte streams makes it legit to write apps in a mix of languages. So the dream of Smalltalk / Lisp Machines / Boxer that a user may deal with only one language is unattainable.
Existing shells has tons of accidental complexity. But in last decaded there is a renaissance in shell design so things are improving... See Why Create a New Unix Shell? (2021).
Existing shells have very bad debugger tooling. But with Oil's headless mode a stepper might become possible.

Rant: Spatial metaphor in file managers is NOT metaphor for file systems?!? :exploding_head:

A lot of ink has been spilled on dispute between "spatial" vs "navigational" file managers.

[BTW, OsFirstTimer youtube channel is a treasure trove for comparing old desktop environments]

Spatial	Navigational

Both show icons inside folders, but what happens when you click them? Well either they replace the current window, or open a new window, but they don't expand inside the existing folder.

So it's a metaphor of what? The "space" alluded to, where every icon/folder has a persistent location, is that of the PARC desktop with overlapping windows.
It is NOT a metaphor for folders being inside folders inside folders.
AFAICT, none of the major OSes / file managers, ever, presented file system hierarchy as folders literally containing their content :exploding_head:
The containment only goes 1 level deep, but each icon is sort-of a link, a launcher button for opening it elsewhere.

Yes, the hierarchy is conveyed but indirectly, by: (1) the chain of icon-within-folder containments (2) opening/closing animation, and open- vs closed-folder icon linked to presence of open window (3) displaying the path/breadcrumbs [esp. in navigational managers] (4) tree, with collapsible nodes! (5) Miller columns which are a close relative of nested menus.

### honorary mention: [Windows 3.1 Program Manager](https://en.wikipedia.org/wiki/Program_Manager)

It gets for showing window within window, but it's not a generic file manager (Windows 3.1 explorer was navigational with tree), I think in was only 2 levels, and the [MDI](https://en.wikipedia.org/wiki/Multiple-document_interface) was flawed in multiple frustraging ways. Overlapping windows within overlapping windows were a nightmare, and here supporting both closing and minimizing was redundant complication of the metaphor.

Real spatial containment: Eagle Mode — a zoomable UI

Well, I did find ~~exactly 1~~ 2 file managers where folders are literally inside folders, the esoteric but surprisingly polished Eagle Mode:

eaglemode3

And the similar (I think earlier?) Pad++: https://www.cs.umd.edu/hcil/pad++/tour/dir.html#a9

There are several obvious issues putting folders within folders, and this one solves them by making items fixed size but smallar, effectively forming a fractal.
Each folder/document/part of document has a fixed position on huge logical canvas representing your filesystem.

This style is known as Zooming user interface (ZUI). See Bluebottle : A Thread-safe Multimedia and GUI Framework for Active Oberon for some criticism of rigid-size ZUIs.

It's certainly an interesting start :clap: :heart:, but I do want a system where I can arrange things for the task I'm currently working on, so this rigid zoomable arrangement is not what I have in mind.

Boxer: variable-size boxes

I think Boxer's model, where individual boxes can grow and shirnk, is more promising.
It does however require a re-definition of what "spatial metaphor" means! Andrea A. DiSessa in Changing Minds, chapter 7:

Notice how absract Boxer's spatial metaphor is. Boxer are not fixed in size. Indeed, when a box is expanded, it pushes text and other boxes around to maintain the logical structuring of next to, above, below, and so on. The strict maintenance of logical structure while sizes distances, and absolute positions change is nhot like real-world boxes, but we have discovered, far beyond our initial expectations, that people find this structure highly intuitive.

... In anticipation of users getting lost, we built a little utility that would show users a map of the "world" and where they waere in it, but it turns out that no one, after a few moments with Boxer, ever gets lost. People may lose track of where they are, but it is easy to zoom out and find themselves again. Intuitive spatial knowledge is indeed abstract, flexible and powerful.

(from the edition I have. I've seen online a version with somewhat different discussion of the metaphor's abstractness; the 2nd part appears in both)

"fluid" workspace window managers

PaperWM

The window manager I've enjoyed the most so far was PaperWM. It's less rigid than tiling window managers — windows form a (mostly) horizontal row that may exceed the screen, which is a scrolling viewport:

newm

A 2D-zoomable wayland WM (compositor) where you arrange windows on infinite 2D grid, and shift/resize the viewport as a rectangle on that grid. This way, you don't have a fixed division into "desktops" but can dynamically aggregate several sub-areas for an overview / focus onto a few or 1 window. Note that it's not just temporary zooming out as in Expose — the windows actually get resized and re-render for smaller/bigger part of the screen, so you can work at every viewport.

Filesystem <-> Workspace mappings

TabFS

TabFS represents browser tabs as directories in file system. It is certainly an influence, and once I build the basic window-as-file representation, I'll want to mix it in some way... TBD

Structured shell

Tons of people who used terminals want to experiment with something where separate commands run in separate terminals, in some kind of structure. It's surprisingly hard to build a prototype.

Something more notebook-like e.g. Warp.
Something where intermediate data in pipelines can be viewed & modified e.g. Userland or Arcan-based Pipeworld.
Something spreadsheet-like (again like Userland).
Something where commands can have graphic output — from old attempts like XMLTerm, to Arcan-based Cat9 shell.

It's sane to prototype this in Emacs or tmux. Adding graphics is much harder... Arcan replaces the X display server protocol entirely, which is insanely brave :exploding_head:. Userland was prototyped in a lua 2d graphics lib, but required custom "rich" commands e.g. a cat replacement (so did many previous attempts that wanted cat image.jpg to work — each, alas, with its own protocol of what "rich" commands can do :-1:)

I hope that being a Wayland WM is a feasible road :pray:, where "rich-UI command" == any standard graphical app. More importantly, I hope that doing most of "UI structure" manipulation as file/directory creation — "the dir is the new div" — can keep "rich" scripts somewhat useful outside dirwm, at least somewhat inter-operable with regular unix, or other exotic-unix environments...

P.S. a pleasing quote from Arcan's sorta-manifesto:

For those unaware, Arcan is presented as something as uncommon as a ‘desktop engine’. The grand claim is that modifying and understanding the entirety of your desktop should be ‘patching scripts’ level easy if we rework current popular abstractions and adjust the division of labour.

dirwm / dirwm

Why? / Prior art #1