A Symbol-Oriented GUI

[cben]

@natecull

But what I want is more the idea of “copy and paste” extended to graphical interfaces. So that, as with text but differently, the user could select any widget or graph node or area of the display and reliably copy or move it to any other system.

Perhaps you’ll like document-centric environments, where active UI elements can be part of the text.

1. Research on these dates back to User-tailorable systems: pressing the issues with buttons.
2. …
3. Coda is one modern take on the genre. (Haven’t tried it but was impressed by this interview.)
4. A more compositional spinoff was Boxer. It also blurs the line between document/UI/app, but adds nesting of collapsable “boxes”, reusing them for every level of structure — from variable scoping up to the level we’d call folders and apps…
   Start from their “Boxer Structures” doc; most relevant/insightful sections are “uses of doit boxes”, “uses of data boxes” & all mentions of “reconstructible interface”.

@natecull

There is nothing in fact to a window other than all its individual visible components. There are, specifically, no hidden elements: no code, no configuration, no binary files. Everything you see, you get, and only that.

I’m not sure I fully follow your meaning, but Boxer’s ideal of “naive realism” comes to my mind. As does Self’s UI e.g. The thing on the screen is supposed to be the actual thing.

@natecull

A set of symbols, with a basic sort of “visual grammar” on how they can connect (eg: left/right, up/down, inside/outside)

Getting away from text, Tangible Functional Programming (best to watch the video) does interesting things with visual “grammar” for seeing & combining functions.