3 ms·

Thank you, that was entirely new history for me. From Wikipedia: > MGR featured overlapped [...] windows and [...]. Took a while to see the strength of tiling

Thank you, that was entirely new history for me. From Wikipedia: > MGR featured overlapped [...] windows and [...]. Took a while to see the strength of tiling window managers.

rwmj 5y ago
MGR was an interesting non-X window system. I ran it for a while (on Minix IIRC) although unfortunately it wasn't free software. One thing about it was that you created windows, drew lines etc entirely by printing special escape sequences to stdout. It was possible to write small graphical C programs using basically printf. This also made it network independent. https://en.wikipedia.org/wiki/ManaGeR https://en.wikipedia.org/wiki/ManaGeR
- 20after4 5y ago
  Reminds me of rip graphics, a format which briefly existed as a way to add vector graphics to bulletin board systems. It was useable over a telnet or dialup modem connection if you had a terminal that supported the rip escape codes. https://en.wikipedia.org/wiki/Remote_Imaging_Protocol https://en.wikipedia.org/wiki/Remote_Imaging_Protocol
  - swills 5y ago
    There was also NeWS: https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS which had the interesting idea of using PostScript to drive the display.
    - ck45 5y ago
      Which was then also used in another successor (name wise) , W => X, S => T: NeXT
- kristov 5y ago
  Fascinating!! What an interesting idea!
  - ncmncm 5y ago
    That was how all graphics terminals were operated, back then. Tektronix had one with a "storage" scope that would retain (for a while, fading) a picture drawn once with a vector-steered electron beam. There was a graphics board to plug into a DEC VT100. HP had such a terminal. I think the VT100 card took the same codes as the Tek, but the picture would stay until erased. Programs to draw graphics would need a driver layer to work on different terminals. If you were clever, the same code could drive an X-Y pen plotter, typically from HP. Good times! You could buy a knife-pen and put rubylith in the plotter, and cut out circuit board optical masks, usually at 4x or more magnification. Rubylith was two layers of plastic, dark red and soft on clear and hard. The knife would cut just through the red layer. Peel off the stretchy red stuff where you didn't want traces, and send the rest to the PC board shop.
Someone 5y ago
Might have been technical limitations. When you allow overlap, you can’t use the screen as _the_ backing store for pixels anymore, and either memory usage goes up (a lot, if you’ve several large windows open), or you have to invent redraw events (which may be slow even for relatively simple content, if you have to swap in the drawing code). If you keep the screen buffer as (part of) the backing store for the pixels of windows, you also have to make drawing code clip to any overlapping windows. If you don’t, memory usage goes up again. And memory could be tight. As an extreme example, the screen memory on an original Mac was about the same size as the amount of memory available to the running application.
- ncmncm 5y ago
  For reference, the original Mac was 512x342, monochrome: 21,888 bytes. It had 128K RAM total, including that. It was essential for programs to rely on code in the ROM so as not to waste precious RAM. Running your program and also the "Finder" (desktop) at the same time was novel. It did overlapping windows, and the program was expected to re-draw the part exposed if you moved one. The 512k version, or "Fat Mac" came out soon after, and was actually useful.
mavhc 5y ago
Overlapped windows are great, until someone invented raise-on-click

Thank you, that was entirely new history for me. From Wikipedia: > MGR featured overlapped [...] windows and [...]. Took a while to see the strength of tiling window managers.

rwmj 5y ago

MGR was an interesting non-X window system. I ran it for a while (on Minix IIRC) although unfortunately it wasn't free software. One thing about it was that you created windows, drew lines etc entirely by printing special escape sequences to stdout. It was possible to write small graphical C programs using basically printf. This also made it network independent. https://en.wikipedia.org/wiki/ManaGeR https://en.wikipedia.org/wiki/ManaGeR

20after4 5y ago
Reminds me of rip graphics, a format which briefly existed as a way to add vector graphics to bulletin board systems. It was useable over a telnet or dialup modem connection if you had a terminal that supported the rip escape codes. https://en.wikipedia.org/wiki/Remote_Imaging_Protocol https://en.wikipedia.org/wiki/Remote_Imaging_Protocol
- swills 5y ago
  There was also NeWS: https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS which had the interesting idea of using PostScript to drive the display.
  - ck45 5y ago
    Which was then also used in another successor (name wise) , W => X, S => T: NeXT
kristov 5y ago
Fascinating!! What an interesting idea!
- ncmncm 5y ago
  That was how all graphics terminals were operated, back then. Tektronix had one with a "storage" scope that would retain (for a while, fading) a picture drawn once with a vector-steered electron beam. There was a graphics board to plug into a DEC VT100. HP had such a terminal. I think the VT100 card took the same codes as the Tek, but the picture would stay until erased. Programs to draw graphics would need a driver layer to work on different terminals. If you were clever, the same code could drive an X-Y pen plotter, typically from HP. Good times! You could buy a knife-pen and put rubylith in the plotter, and cut out circuit board optical masks, usually at 4x or more magnification. Rubylith was two layers of plastic, dark red and soft on clear and hard. The knife would cut just through the red layer. Peel off the stretchy red stuff where you didn't want traces, and send the rest to the PC board shop.

Someone 5y ago

Might have been technical limitations. When you allow overlap, you can’t use the screen as _the_ backing store for pixels anymore, and either memory usage goes up (a lot, if you’ve several large windows open), or you have to invent redraw events (which may be slow even for relatively simple content, if you have to swap in the drawing code). If you keep the screen buffer as (part of) the backing store for the pixels of windows, you also have to make drawing code clip to any overlapping windows. If you don’t, memory usage goes up again. And memory could be tight. As an extreme example, the screen memory on an original Mac was about the same size as the amount of memory available to the running application.

ncmncm 5y ago
For reference, the original Mac was 512x342, monochrome: 21,888 bytes. It had 128K RAM total, including that. It was essential for programs to rely on code in the ROM so as not to waste precious RAM. Running your program and also the "Finder" (desktop) at the same time was novel. It did overlapping windows, and the program was expected to re-draw the part exposed if you moved one. The 512k version, or "Fat Mac" came out soon after, and was actually useful.

mavhc 5y ago

Overlapped windows are great, until someone invented raise-on-click