Hacker News new | ask | show | jobs
by SoSoRoCoCo 1982 days ago
> Everything is a Command Line

This is a really controversial pattern for GUIs. In one camp, the GUI is really a skin over the CLI that acts like a virtual user, translating GUI inputs into underlying CLI. In the other camp, the GUI is all there is (e.g., Windows) and there is no underlying OS that can be accessed via CLI: in fact, the CLI is a "fake GUI" (win32 apps written without a Window). I can't say which is better, but it is fascinating to see that this was an "original pattern".
2 comments
barrkel 1981 days ago
Windows CLI apps aren't "fake GUI". There's a flag in the executable header that tells the loader (and from there the rest of the OS) whether to ensure a console is allocated for it and wire up stdin/out/err if they're not already wired up, but that's it.

An executable won't have its own window unless it calls CreateWindowEx one way or another, and any such window won't be very functional until the app starts pumping messages, which is work it needs to actively do, with GetMessage and DispatchMessage. Obviously a CLI-only app won't do these things, but it doesn't need to go out of its way to not do them; it doesn't need to fake anything, or hide or otherwise resort to subterfuge to conceal GUI elements.

There's a stronger argument to be made in some COM scenarios; e.g. single threaded apartment threading model creates a hidden window so it can use the message pump as a communication and serialization mechanism. But even here it's mostly just repurposing existing Windows stuff in ways which work well with existing GUI apps.

link
remexre 1981 days ago
I'm (slowly!) working towards an OS where every user-invoked application is a GUI, most applications are many processes (more like Erlang than Unix), and every interprocess interaction, including GUI programs asking the OS to be drawn, is message-passing of data.

My theory is that if applications are written as servers that do message-passing, one can have a shell language that orchestrates the passing of messages between servers instead of the flow of bytes between CLI programs; the semantics of the shell language still need to worked out, though. e.g. does it need session types, or can one get reasonable behavior by structuring data specially to indicate "this is only part of a response that's being streamed."

On the GUI side, the idea of describing a UI in pure data (like HTML) seems very reasonable, and seems like it would make it much easier to quickly throw together small GUI programs. So the drawing part of an application would just be a process that sends the screen/compositor process a message describing the state of its window as a tree, and receives messages for events in response.

A big advantage is it makes the semantics of composing GUIs a lot more reasonable "replace this leaf of my tree with this other process' tree" is a simple-to-implement and simple-to-understand operation, but seems like it'd make sharing widgets way easier: widgets are just processes that render without the "this is a window" flag set, and you ask the compositor to put them into your window's tree. Events flow back to the widget, and each side can send the other messages easily. An application could also "proxy" for a widget, including over a network link, so you get fairly simple network transparency this way too.

link
sriku 1981 days ago
At some point, this would be come close to the AppleScript protocol or Symbian OS.

> So the drawing part of an application would just be a process that sends the screen/compositor process a message describing the state of its window as a tree, and receives messages for events in response.

I've been toying with an interpretation of this here - https://github.com/Imaginea/inai - and kind of having fun with it .. and even built a prototype internal app using it. Super early stage and so stuff won't necessarily make sense at the outset .. or possibly ever. Thoughts welcome though.

> A big advantage is it makes the semantics of composing GUIs a lot more reasonable "replace this leaf of my tree with this other process' tree" ...

The "dom" service in Inai pretty much feels like that. I felt like an idiot to try and (for lack of a better expression) REST-ify the DOM, but it seemed to work to my surprise.

> An application could also "proxy" for a widget, including over a network link, so you get fairly simple network transparency this way too.

.. yeah due to the "REST" nature, this becomes pretty straightforward.

link
protomyth 1981 days ago
At some point, this would be come close to the AppleScript protocol or Symbian OS.

The Amiga had an interesting scripting model with ARexx and the ARexx port.

link
alexisread 1981 days ago
This is the basis for Composita ie. Every component has it's own message stack which allows a formal interface to the component to a) reference count b) allow static analysis for deterministic memory allocation (max stack depth required).

Performance is great, managed memory with no GC, multithreaded GUIs are possible etc.

Composita is a further development of A2. I think that it was a real missed chance that A2 wasn't chosen instead of Android as the ZUI and compiled modules would have been a great fit for mobile.

http://concurrency.ch/Content/publications/Blaeser_Component...

link
pjmlp 1981 days ago
Basically this is also the base of ToolTalk, RMI, .NET Remoting, Taligent, Plan 9/Inferno, DCOM, D-BUS, and so on.
link