Hacker News Reader

Comment by sprash | Hacker News Reader

I find the concept of MGR is very intriguing. Imagine creating GUIs simply by writing escape codes to stdout. No need to deal with C-libraries, the GUI can be completely language agnostic and all applications work instantly over network as well (file descriptors for frame buffers of e.g. OpenGL applications running locally could simply be exchanged via pidfd_getfd syscall but that wouldn't work over the network obviously). Maybe something like MGR2 should replace X11 instead of Wayland.

View on HN

Fun fact. I've been resurrecting MGR against modern DRM graphics on an openBSD machine. I have the animated splash screen rendering, and the terminal working mostly. There are some bugs with some of the programs, and menus, that I haven't figured out yet, and some of the programs crash. It's been quite an interesting experience. Hopefully when I get it working I will post it somewhere. a DRM based graphics stack should work on linux as well, which is pretty cool.

Please let me give you some encouragement about that - it would be fantastic to be able to easily create simple GUIs using MGR; and to use on older laptops etc.!

Cool. Putting MGR up on a Raspberry Pi would be cool. The MGR model was awesome, but the ergonomics of move and resize could perhaps be modernized a bit. Do you have a github repo or somewhere we can follow the progress?

This sounds fantastic! Is there anything to see anywhere yet?

this is pretty much the current state: https://youtu.be/LYhs9E2W5MI I'm still struggling with quite a few of the boolean operations, because I don't actually understand how they were supposed to work on color bitmaps. This is basically just the regular MGR source with some tweaks so that it compiles on a modern compiler and a display driver targeting a libdrm framebuffer.

Neat! Good work.

Please do post it, that would be sweet to play with:)

Mostly what has replaced X11 and Wayland is HTML, where you create GUIs in a completely language-agnostic way by writing angle-bracket-delimited <tags> to stdout, with no need to deal with C libraries. The main difference is that the escape codes are introduced by '<', ASCII 60, instead of ESC, ASCII 27.

For some good reasons and some bad ones, the HTML escape-code language was coupled to a shift from the time-sharing interactive terminal applications of MGR or the VT100 to a revival of the 3270 block-mode interaction model, which later got formalized as REST.

Paul Graham wrote some essays about the advantages of doing things this way late last millennium; they're worth reading if you haven't read them. It really took off about 20 years ago.

More recently spitting out HTML on stdout has largely been replaced by JS and the DOM because you can get lower interaction latency and higher bandwidth by running the app on the client, sending mostly just database calls and actions to a backend server.

Tk had this language agnostic way of placing widgets and interface elements and the library took care of the layout. It was somewhat successful, but not as much as HTML, which is slow and clunky in comparison.

Some aspects of HTML are slower than Tk (which is not all that language-agnostic — you can't write Tk apps in bash or Gambas or Prolog, which are totally capable of outputting HTML), but some aspects of Tk are slower than HTML. I feel like HTML with JS is generally a smoother and more agile development experience than Tk.

I know you are trying to be funny. But it's a rather sad story after all.

Why would you think I'm trying to be funny? Everything I wrote is literally true, though maybe it's a perspective you're unfamiliar with. I don't think it's sad either.

Did you mean RESET instead of REST as in the API ?

I meant REST, and I don't know what you might mean by "RESET". REST isn't an API; it's the architectural style describing how the WWW works. Check out Roy Fielding's dissertation, "Architectural Styles and the Design of Network-based Software Architectures": https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Thanks yes that's what I was talking about I come across it mostly as an API framework but was not aware it (the architecture;) had any link back to anything 3270 thanks for giving me something to explore.

REST is not an "API framework" as usually understood, because "API" generally means "interface based on procedure calls," while REST prohibits interfaces based on procedure calls.

Well I see a lot of systems which rely on RESTfull APIs [1] for some level of external interoperability but maybe framework is the wrong phrasing.

[1] https://restfulapi.net/

To some extent, the architecture of xi-editor was inspired by similar thoughts - not escape codes, but updates to the UI specified as JSON-RPC, and with one process handling the nitty-gritty of UI, the other (in Rust, but conceptually language agnostic, in fact Go was under serious consideration) specifying the application logic. The original implementation only stood up an editor, but making that rich enough to support a full IDE experience could conceptually support other GUI applications. I wasn't particularly familiar with MGR, but the Blit[1] had somewhat a somewhat similar flavor and was definitely on my radar. We even considered the possibility of running the protocol over the network, because at heart it's just byte streams (and already somewhat optimized, as the idea was to use intelligent diffing to minimize the work needed to be done by the UI process).

It didn't work out. It turns out to be very complex to support modern UI, and making it async upped the complexity even more. I'm not saying this couldn't be done, but these days I'm much more interested in UI architectures where everything is in process and more tightly coupled.

[1]: https://en.wikipedia.org/wiki/Blit_(computer_terminal)

Have you written up why it didn't work out? Was it mostly the async-is-a-complexity-multiplier stuff you described in https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...? Your mention of "modern UI" makes me think there's more to the story.

I've been thinking of writing more. Doing real text layout is one of the tricky bits, and one that terminals sidestep because layout calculations are trivial as long as you narrow scope down to grids of monospaced ASCII characters.

I'd be very interested in reading it! I've been thinking about the problem of performant real text layout a lot lately. I'm guessing you're not including optimization-based paragraph filling (like TeX or GNU fmt) in "real text layout"?

I think it's potentially in scope, but optional - there are other problems more urgent to solve, and then with more powerful compute and font technology, it's possible to go past TeX into microtypography (some of which was done in hz, but not really widely adopted). Either way, to do Knuth-Plass paragraph optimization, you need lots of metrics of the words to decide the line breaks, and to do the micro stuff, you need even more fine-grained information from the font. Breaking that across a process boundary is... tricky.

A thing I've been struck by when looking at medieval manuscripts is how ubiquitous "microtypography" is in them. No two copies of the same letter are ever the same width, swashes and scribal abbreviations are chosen to fit the space available, etc. If you can manage to do that kind of thing on a computer, pretty soon you're doing continuous optimization instead of discrete optimization, so maybe the optimization process becomes a lot cheaper computationally.

I hope you get around to writing up your thoughts! I'd be interested in providing feedback on drafts if that would be useful.

> No need to deal with C-libraries, the GUI can be completely language agnostic

My understanding is that X11 didn't need to be tied to the C libraries either, it's just that nobody actually bothered writing the appropriate library in anything else. But it's just connecting over a socket and speaking the protocol, so there's no reason that it has to be tied to that implementation.

(Although yes, there is something magical about just using stdout)

The Common Lisp bindings to X11 [1] don't use C libraries.

[1] https://en.wikipedia.org/wiki/CLX_(Common_Lisp)

Sending everything over a single byte stream can get ugly very quickly. Imagine sending a bunch of images progressively by multiplexing, then add out of band commands to it, etc. Before you know it, you have reinvented QUIC.

Used to play with MGR on my Atari ST way back in 1991, before I got my hands on my first 486 to run Linux.

Definitely an interesting path-not-taken.

(author) I assume this was MiNT. Did it have the same limitation this implementation does about no offscreen or partially offscreen windows?

Yeah, pretty sure it required MiNT.

I don't recall, but I'd imagine it'd be identical to the Sun version re: window mgmt.

I looked at the source a couple years ago, and the Atari framebuffer pieces were still in there. All the same source tree.

(author) I really found it fascinating myself. I really should sit down and bang out a proof of concept.

What you do is run `xterm -ti vt340`. If your xterm was compiled with SIXEL support, this will enable it. (You can test it by running something simple like `gnuplot -e "set terminal sixelgd; set key bmargin center horizontal; plot [-5pi:5pi] [-5:5] real(tan(x)/atan(x)), 1/x"`.)

Now run Xsixel (from <https://github.com/saitoha/xserver-sixel>) to run an X server that outputs to sixel graphics. In that X server you can run any program you would like, and its graphical output will be converted to sixels, printed to stdout, given to xterm, and then xterm will draw them.

Job done!

See <https://saitoha.github.io/libsixel/> for more information and tools, along with lots of screenshots.

I had the same experience as you -- my first Unix account was in the late 80s on a Solbourne running OS/MP. I recall the load average hovering around 150 and simple C programs taking minutes to compile as hundreds of undergrads on vt-220 terminals all worked late into the night before project deadlines. I never physically saw the machine (it was owned by the campus-wide IT folks), and I was thankful when I got an account on the much less crowded CS systems the next semester.

FWIW, this was SUNY Buffalo. Where were you?

UC San Diego. Not too nearby. ;)

Reply on news.ycombinator.com