| HN Mirror

Heck, Windows 3.1 had the start of something even more interesting: there was no real distinction between an icon and an iconified (minimized) window.

If we had carried through with that metaphor, and kept a 1:1 document:window relationship, we could have evolved a modern OS where a generic WIMP "document" icon was just the representation of a portable, disk-hibernated GUI process holding the memory-state of that document, rather than having a 1:1 mapping to a POSIX-filesystem file containing a custom-serialized representation of said state. (Sure, we could also have those, but maybe only "for interchange." Like how computers have directories/folders locally, but use archive files for interchange.)

Most of the time, when you were done with something, you wouldn't close it; you'd iconify it. Either it'd return to where you previously un-iconified it from; or it'd land on your Desktop; or it'd get stuck to your cursor as if you were dragging, and you'd have to drop it somewhere. It'd be sleeping at first (so, basically a minimized window); and then hibernated later. It'd just be a difference in restore-time: events, like chat-notifications from a chat-client window, would still appear even under hibernation (i.e. background services would still run for hibernated documents, unless you right-clicked and "froze" or "muted" the document or something.)

Imagine if bookmarks were just... iconified browser windows. Or if git repos were iconified IDE/text-editor sessions (which would then contain further icons for things like shell sessions spawned inside the repo.) Or—remember old MacOS?—"folders" would literally be iconified file-manager windows, separate from the underlying file-system concept of a directory (which might not be exposed in the GUI at all.)