10 ms·

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 c

by sprash 4y ago

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.

classichasclass 4y ago
(author) I really found it fascinating myself. I really should sit down and bang out a proof of concept.
- drewg123 4y ago
  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?
  - classichasclass 4y ago
    UC San Diego. Not too nearby. ;)
- db48x 4y ago
  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 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/ https://saitoha.github.io/libsixel/> for more information and tools, along with lots of screenshots.
MobiusHorizons 4y ago
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.
- yjftsjthsd-h 4y ago
  Please do post it, that would be sweet to play with:)
- FullyFunctional 4y ago
  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?
- shrubble 4y ago
  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.!
- lproven 4y ago
  This sounds fantastic! Is there anything to see anywhere yet?
  - MobiusHorizons 4y ago
    this is pretty much the current state: https://youtu.be/LYhs9E2W5MI 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.
cmrdporcupine 4y ago
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.
- classichasclass 4y ago
  (author) I assume this was MiNT. Did it have the same limitation this implementation does about no offscreen or partially offscreen windows?
  - cmrdporcupine 4y ago
    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.
yjftsjthsd-h 4y ago
> 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)
- rjsw 4y ago
  The Common Lisp bindings to X11 [1] don't use C libraries. [1] https://en.wikipedia.org/wiki/CLX_(Common_Lisp) https://en.wikipedia.org/wiki/CLX_(Common_Lisp)
- amelius 4y ago
  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.
kragen 4y ago
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.
- sprash 4y ago
  I know you are trying to be funny. But it's a rather sad story after all.
  - kragen 4y ago
    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.
- ivlad 4y ago
  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.
  - kragen 4y ago
    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.
raphlinus 4y ago
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) https://en.wikipedia.org/wiki/Blit_(computer_terminal)
- kragen 4y ago
  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.html 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.
  - raphlinus 4y ago
    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.
    - kragen 4y ago
      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"?

by sprash 4y ago

classichasclass 4y ago

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

drewg123 4y ago
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?
- classichasclass 4y ago
  UC San Diego. Not too nearby. ;)
db48x 4y ago
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 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/ https://saitoha.github.io/libsixel/> for more information and tools, along with lots of screenshots.

MobiusHorizons 4y ago

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.

yjftsjthsd-h 4y ago
Please do post it, that would be sweet to play with:)
FullyFunctional 4y ago
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?
shrubble 4y ago
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.!
lproven 4y ago
This sounds fantastic! Is there anything to see anywhere yet?
- MobiusHorizons 4y ago
  this is pretty much the current state: https://youtu.be/LYhs9E2W5MI 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.

cmrdporcupine 4y ago

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.

classichasclass 4y ago
(author) I assume this was MiNT. Did it have the same limitation this implementation does about no offscreen or partially offscreen windows?
- cmrdporcupine 4y ago
  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.

yjftsjthsd-h 4y ago

> 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)

rjsw 4y ago
The Common Lisp bindings to X11 [1] don't use C libraries. [1] https://en.wikipedia.org/wiki/CLX_(Common_Lisp) https://en.wikipedia.org/wiki/CLX_(Common_Lisp)
amelius 4y ago
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.

kragen 4y ago

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.

sprash 4y ago
I know you are trying to be funny. But it's a rather sad story after all.
- kragen 4y ago
  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.
ivlad 4y ago
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.
- kragen 4y ago
  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.

raphlinus 4y ago

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) https://en.wikipedia.org/wiki/Blit_(computer_terminal)

kragen 4y ago
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.html 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.
- raphlinus 4y ago
  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.
  - kragen 4y ago
    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"?