6 ms·

If one GUI's not enough for your SPARC workstation, try four

142 points by zdw 4y ago

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"?
agumonkey 4y ago
I'd love to have more demos of NeWS or details about the interpreter. Don..
- csdvrx 4y ago
  Same. I love the look it started and that culminated with XViews: check http://www.martin-graefe.homepage.t-online.de/xview_en.html http://www.martin-graefe.homepage.t-online.de/xview_en.html for a simple example (and working code) Scrollbars that can carry your mouse around when you click (so you don't have to do a gesture), and pin button for menus (so you see what can be pinned) are innovation we seem to have lost. Also notice how some windows have special corners: you know immediately which window can be resized, and what you should grab to do that.
kragen 4y ago
Hey, this is fantastic! I've been looking for one-bit-deep screenshots of SunView, OpenWindows, or Open Look for a while — I don't remember if I ever used it on a one-bit display, but a lot of the graphic design in Open Look seems like it's intended to work well on a one-bit display. Unfortunately, all the SunView/OpenWindows/OpenLook screenshots I could find were 256-color screenshots. This version of SunView looks pretty different from the Open Look I used to use. There are no pushpins on menus, no rounded ends on menu items, no arrow-buttons on the scrollbar slider, and scrollbars on the left (usually) instead of the right. Action buttons are beveled instead of having rounded ends. Default action buttons are indicated with a thick border instead of a double border. Instead of popups being connected to their parent window with a tower converging on a vanishing point, they're connected with a curvy arrow (though with a little vanishing-point action). Instead of picture-frame corners to resize windows with, you have a mega thick double line border around the entire window. Cascading menu items are indicated with a double-line right arrow instead of a right-pointing triangle. There are clearly some elements in common. The file browser has the same ugly folder tree view with awkwardly wrapped filenames. The cursor in text fields (including "cmdtool", a name shared with Open Look) is a caret shaped like a diamond or triangle, instead of a vertical line, a flashing block, or an underline. The "file properties" dialog in fileview still has checkboxes for permission bits. And the pushpin also shows up in that dialog despite its unfortunate absence from menus. The OpenWindows section following seems to have one-bit-deep versions of most of the Open Look stuff I'm familiar with, though! You have the picture-frame corners, buttons on the scrollbar slider (which is on the right), downward-pointing triangles for the titlebar button and menu buttons, a non-shitty mouse pointer graphic, circular ends on menu entry highlights and action buttons, right-pointing triangles for submenus, pushpins on menus (now with lines inside the silhouette), underlined text fields, checkboxes with a little more panache, dropshadows on buttons by way of thickening the border on the bottom and right, rectangular radio buttons (which highlight the selected option with a thicker border), the same slider and gauge widget from the OLIT sampler demo, double-lined borders for default buttons and the goofy perspective tower thing for popup dialogues. All of this looks perfectly comprehensible despite the one-bit-deep display, and not only is it less ugly than SunView and GEOS, it's even less ugly than Motif or Windows 3.1, on par with the one-bit-deep UIs on the Macintosh and the Palm Pilot. The highlighting of the hyperlinks in the Help Viewer leaves something to be desired. Does anyone know how these graphical idioms changed so radically from this version of SunView to OpenWindows?
neilv 4y ago
This article includes nice tours of SunView and OpenWindows. Note that all screenshots are in monochrome. SunView on color monitors looks the same except for spot colors. But Open Look on color monitors switched from the crisp monochome line art here, to using shades of gray for more of a 3D bevel look. It might bear mention that most of the OpenWindows tools seem to be done using the XView toolkit for the GUI controls, which was pixel-based, and crisp. PostScript of course could do vector drawing, but the vector-rendered Open Look controls didn't match that. When you only have a million pixels to play with, and and it also has to work on a monochrome monitor, pixel control is important for some things. So you might have the pixel-based usual GUI controls, but a subwindow in which you did vector rendering. One noteworthy OpenWindows thing not mentioned here is that it started to support drag&drop. Tools (programs) had explicit visual drop targets, to indicate that they could receive a drag&drop. The pinnable menus were an Open Look thing. The idea is that you'd have something like a Mac or Windows menu bar, and user could pin a pull-down/pop-up menu, and drag it to anywhere on their screen, to be like a flexible what later became called a toolbar. (We later saw things like that evolve into dockable toolbars, sometimes including in a return of MDI interfaces (one big window for an application program on the host desktop, and that program manages multiple "document" windows within it and dockable and customizable toolbars and persistent property sheets).) It's sad that NeWS didn't become bigger. I heard a rumor in the early/mid '90s that Frame had invested in a NeWS-based implementation of FrameMaker, and got the rug pulled out from under them. But at least, as Sun was later dying, Linux and the open source around it (a different beast, but good) arose in its place.
- mhalle 4y ago
  One interesting thing about the XView toolkit: it built the entire UI out of fonts (bitmap fonts at the time). It supposedly allowed faster rendering because the fonts were loaded and were server side. I actually used the low layer display layer under XView for some UI projects. Worked great! While I'm here, the other nice thing about programming in SunView (and later XView) was the use of varargs call patterns to build UI elements. Early X development, as I recall, was significantly more verbose than the Sun equivalent, though probably more type safe. The *View APIs felt a little more like today's high level languages.
amelius 4y ago
I remember my SPARC workstation had Copy and Paste keys. So much better than the awkward Ctrl+C and Ctrl+V combinations (especially considering that Ctrl+C stops a program when used on a terminal).
- girvo 4y ago
  My 75% keyboard (a customised RK84) in front of me has Copy/Paste keys! I swapped the Print/Pause key-caps out for the copy/paste icons that came with the IBM-grey inspired key-cap set that I got for it (and a small macro to make them output Ctrl-C and Ctrl-V). Not the best placement, but is pretty excellent nonetheless: I can totally see why some people would prefer having dedicated keys for those. Genuinely handy
  - yjftsjthsd-h 4y ago
    Okay, but if the "copy" button just inputs ctrl-c we're not getting the full benefit; I do not want to be in a terminal, select a block of text, hit "copy", and have the program be killed.
    - girvo 4y ago
      shrugs That’s literally never caused me a problem
anigbrowl 4y ago
Somewhat off topic but it's hard to explain how pleasant an orange gas plasma screen was to someone who hasn't used one. I had a Compaq portable 386 for a while and it was so nice, not to mention much easier to lug around than the cast-iron sewing machine models that preceded it (depicted in the header image). https://www.retropaq.com/the-beginning/ https://www.retropaq.com/the-beginning/
- jfb 4y ago
  I always wanted a Toshiba 3200. That sexy screen!
- mixmastamyk 4y ago
  I don't think I ever saw one of these, but was a fan of amber monochrome. It was great for night-time work thirty years before redshift, et al.
FullyFunctional 4y ago
I've used all of those when they came out. SunView was presented to me as the default and was all I used until X11 took over. MGR was awesome and almost certainly the easiest to develop for. I really regret MGR didn't get more traction. Note, MGR worked over terminal connections like rsh, unlike the rest of them (X11's hackish DISPLAY not withstanding). OpenLook (and NeWS) were dog slow on the humble hardware (IIRC) so I never used those in anger. X11 is such a kludge, but a useful one, so it took the market I guess. I suppose Wayland is the future but AFAICT, it's even harder to develop for than X11.
joshu 4y ago
I remember using some MS-DOS program for circuit simulation that used a clone of OpenWindows as the GUI/window manager. Pretty strange.
mhalle 4y ago
A couple of historical points I seem to remember. There were X10 versions running on SunOS (3.5?), Though I don't know if it was officially supported. X11 early releases were significantly slower than X10 on Sun hardware. SunView was originally Suntools. The change to SunView brought some improvements in the UI, but mostly in the API. I can still remember the days of the Sun 1 with the VT100-like keyboard. To a freshman at MIT who had only seen a Radio Shack TRS-80 Color Computer and an Apple II, it was almost undescribable. It was the days of 1MB of RAM on a "personal" machine and a lab-wide pair of 500MB Seagate Eagle hard drives being all you could possibly need.

142 points by zdw 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"?

agumonkey 4y ago

I'd love to have more demos of NeWS or details about the interpreter. Don..

csdvrx 4y ago
Same. I love the look it started and that culminated with XViews: check http://www.martin-graefe.homepage.t-online.de/xview_en.html http://www.martin-graefe.homepage.t-online.de/xview_en.html for a simple example (and working code) Scrollbars that can carry your mouse around when you click (so you don't have to do a gesture), and pin button for menus (so you see what can be pinned) are innovation we seem to have lost. Also notice how some windows have special corners: you know immediately which window can be resized, and what you should grab to do that.

kragen 4y ago

Hey, this is fantastic! I've been looking for one-bit-deep screenshots of SunView, OpenWindows, or Open Look for a while — I don't remember if I ever used it on a one-bit display, but a lot of the graphic design in Open Look seems like it's intended to work well on a one-bit display. Unfortunately, all the SunView/OpenWindows/OpenLook screenshots I could find were 256-color screenshots. This version of SunView looks pretty different from the Open Look I used to use. There are no pushpins on menus, no rounded ends on menu items, no arrow-buttons on the scrollbar slider, and scrollbars on the left (usually) instead of the right. Action buttons are beveled instead of having rounded ends. Default action buttons are indicated with a thick border instead of a double border. Instead of popups being connected to their parent window with a tower converging on a vanishing point, they're connected with a curvy arrow (though with a little vanishing-point action). Instead of picture-frame corners to resize windows with, you have a mega thick double line border around the entire window. Cascading menu items are indicated with a double-line right arrow instead of a right-pointing triangle. There are clearly some elements in common. The file browser has the same ugly folder tree view with awkwardly wrapped filenames. The cursor in text fields (including "cmdtool", a name shared with Open Look) is a caret shaped like a diamond or triangle, instead of a vertical line, a flashing block, or an underline. The "file properties" dialog in fileview still has checkboxes for permission bits. And the pushpin also shows up in that dialog despite its unfortunate absence from menus. The OpenWindows section following seems to have one-bit-deep versions of most of the Open Look stuff I'm familiar with, though! You have the picture-frame corners, buttons on the scrollbar slider (which is on the right), downward-pointing triangles for the titlebar button and menu buttons, a non-shitty mouse pointer graphic, circular ends on menu entry highlights and action buttons, right-pointing triangles for submenus, pushpins on menus (now with lines inside the silhouette), underlined text fields, checkboxes with a little more panache, dropshadows on buttons by way of thickening the border on the bottom and right, rectangular radio buttons (which highlight the selected option with a thicker border), the same slider and gauge widget from the OLIT sampler demo, double-lined borders for default buttons and the goofy perspective tower thing for popup dialogues. All of this looks perfectly comprehensible despite the one-bit-deep display, and not only is it less ugly than SunView and GEOS, it's even less ugly than Motif or Windows 3.1, on par with the one-bit-deep UIs on the Macintosh and the Palm Pilot. The highlighting of the hyperlinks in the Help Viewer leaves something to be desired. Does anyone know how these graphical idioms changed so radically from this version of SunView to OpenWindows?

neilv 4y ago

This article includes nice tours of SunView and OpenWindows. Note that all screenshots are in monochrome. SunView on color monitors looks the same except for spot colors. But Open Look on color monitors switched from the crisp monochome line art here, to using shades of gray for more of a 3D bevel look. It might bear mention that most of the OpenWindows tools seem to be done using the XView toolkit for the GUI controls, which was pixel-based, and crisp. PostScript of course could do vector drawing, but the vector-rendered Open Look controls didn't match that. When you only have a million pixels to play with, and and it also has to work on a monochrome monitor, pixel control is important for some things. So you might have the pixel-based usual GUI controls, but a subwindow in which you did vector rendering. One noteworthy OpenWindows thing not mentioned here is that it started to support drag&drop. Tools (programs) had explicit visual drop targets, to indicate that they could receive a drag&drop. The pinnable menus were an Open Look thing. The idea is that you'd have something like a Mac or Windows menu bar, and user could pin a pull-down/pop-up menu, and drag it to anywhere on their screen, to be like a flexible what later became called a toolbar. (We later saw things like that evolve into dockable toolbars, sometimes including in a return of MDI interfaces (one big window for an application program on the host desktop, and that program manages multiple "document" windows within it and dockable and customizable toolbars and persistent property sheets).) It's sad that NeWS didn't become bigger. I heard a rumor in the early/mid '90s that Frame had invested in a NeWS-based implementation of FrameMaker, and got the rug pulled out from under them. But at least, as Sun was later dying, Linux and the open source around it (a different beast, but good) arose in its place.

mhalle 4y ago
One interesting thing about the XView toolkit: it built the entire UI out of fonts (bitmap fonts at the time). It supposedly allowed faster rendering because the fonts were loaded and were server side. I actually used the low layer display layer under XView for some UI projects. Worked great! While I'm here, the other nice thing about programming in SunView (and later XView) was the use of varargs call patterns to build UI elements. Early X development, as I recall, was significantly more verbose than the Sun equivalent, though probably more type safe. The *View APIs felt a little more like today's high level languages.

amelius 4y ago

I remember my SPARC workstation had Copy and Paste keys. So much better than the awkward Ctrl+C and Ctrl+V combinations (especially considering that Ctrl+C stops a program when used on a terminal).

girvo 4y ago
My 75% keyboard (a customised RK84) in front of me has Copy/Paste keys! I swapped the Print/Pause key-caps out for the copy/paste icons that came with the IBM-grey inspired key-cap set that I got for it (and a small macro to make them output Ctrl-C and Ctrl-V). Not the best placement, but is pretty excellent nonetheless: I can totally see why some people would prefer having dedicated keys for those. Genuinely handy
- yjftsjthsd-h 4y ago
  Okay, but if the "copy" button just inputs ctrl-c we're not getting the full benefit; I do not want to be in a terminal, select a block of text, hit "copy", and have the program be killed.
  - girvo 4y ago
    shrugs That’s literally never caused me a problem

anigbrowl 4y ago

Somewhat off topic but it's hard to explain how pleasant an orange gas plasma screen was to someone who hasn't used one. I had a Compaq portable 386 for a while and it was so nice, not to mention much easier to lug around than the cast-iron sewing machine models that preceded it (depicted in the header image). https://www.retropaq.com/the-beginning/ https://www.retropaq.com/the-beginning/

jfb 4y ago
I always wanted a Toshiba 3200. That sexy screen!
mixmastamyk 4y ago
I don't think I ever saw one of these, but was a fan of amber monochrome. It was great for night-time work thirty years before redshift, et al.

FullyFunctional 4y ago

I've used all of those when they came out. SunView was presented to me as the default and was all I used until X11 took over. MGR was awesome and almost certainly the easiest to develop for. I really regret MGR didn't get more traction. Note, MGR worked over terminal connections like rsh, unlike the rest of them (X11's hackish DISPLAY not withstanding). OpenLook (and NeWS) were dog slow on the humble hardware (IIRC) so I never used those in anger. X11 is such a kludge, but a useful one, so it took the market I guess. I suppose Wayland is the future but AFAICT, it's even harder to develop for than X11.

joshu 4y ago

I remember using some MS-DOS program for circuit simulation that used a clone of OpenWindows as the GUI/window manager. Pretty strange.

mhalle 4y ago

A couple of historical points I seem to remember. There were X10 versions running on SunOS (3.5?), Though I don't know if it was officially supported. X11 early releases were significantly slower than X10 on Sun hardware. SunView was originally Suntools. The change to SunView brought some improvements in the UI, but mostly in the API. I can still remember the days of the Sun 1 with the VT100-like keyboard. To a freshman at MIT who had only seen a Radio Shack TRS-80 Color Computer and an Apple II, it was almost undescribable. It was the days of 1MB of RAM on a "personal" machine and a lab-wide pair of 500MB Seagate Eagle hard drives being all you could possibly need.