|
|
|
|
|
|
by LeoPanthera
3346 days ago
|
|
|
RISC OS solved the "file open/close dialogues are a different view on the same objects" problem. In RISC OS, a save dialog is just an icon in a box. You pick up the icon and drag it into a folder window to save. Done. You could even do simple OLE by dragging the icon into another app, instead of a folder. I so wish other OSes would copy that model. |
|
|
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.)