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?
(author) You can get the source/binaries from the gopher server; they're part of the MGR source tree. gopher://gopher.floodgap.com:70/1/archive/sunos-4-solbourne-os-mp
Oh hey, I thought I'd checked the first of these, but evidently they have a lot of exactly what I'm looking for. The second one doesn't seem to have any, though?
You appear to have a lot of experience with this equipment and interfaces like this, I have to say what has been lost, in terms of usability between this and the more usable versions of Mac OS? (The modern versions of Mac OS and the unix desktops of Gnome and KDE leave much to be desired)
Not the person you’re responding to, but I spent a ton of time using SunView and peers too. I don’t see much lost in terms of usability: I’m pretty happy with modern interfaces compared to the old ones. My biggest complaint about new systems is that I can’t quickly throw together a GUI based program with the ease I could on those systems. It wasn’t a big deal to just write a simple C program to make a program with a GUI, even if it was a bit ugly and crude. These days the few times I’ve tried I just give up: too many abstraction layers, too much complexity, too high of a learning curve wading through poor documentation. The closest I’ve found that feels as easy as those old UI systems are libraries like FLTK, but that adds a dependency versus just writing something that targets the UI that the system provides and has zero third party dependencies.
> It wasn’t a big deal to just write a simple C program to make a program with a GUI, even if it was a bit ugly and crude. These days the few times I’ve tried I just give up: too many abstraction layers, too much complexity, too high of a learning curve wading through poor documentation.
That is correct, if you want to write your program using C (or similar), but if you want to do simple GUI programs, there's enough support in existing c/line programs. Use zenity, wmctrl, etc.
All those examples require a canvas. For simple GUI applications that mostly just take input from the user and produce output in a non-canvas form, zenity usually works.
I would argue that if your "graphical user interface" doesn't involve any actual graphics, you shouldn't call it a "graphical user interface" ("GUI"). Zenity can't do any actual graphics, just text you can point at with a mouse.
> The GUI (/ˌdʒiːjuːˈaɪ/ JEE-yoo-EYE[1][Note 1] or /ˈɡuːi/[2] GOO-ee), graphical user interface, is a form of user interface that allows users to interact with electronic devices through graphical icons and audio indicator such as primary notation, instead of text-based UIs, typed command labels or text navigation.
Unless you want to argue that being capable of rendering images isn't "graphical".
> Zenity can't do any actual graphics, just text you can point at with a mouse.
It does scrollbars, progress sliders (also animated if you want), buttons, images, lines, boxes, maybe more stuff.
None of those are plain text.
TBH, I'm confused by your complaint - you wanted an easy way to produce simple GUI applications. Hardly anyone would consider a paint program a simple application, nor do most people consider a file open dialog as a text interface.
> TBH, I'm confused by your complaint - you wanted an easy way to produce simple GUI applications.
In this thread, that was porcoda, not me, but it is also true that "an easy way to produce simple GUI applications" is a good summary of why I wrote Yeso in the first place.
> Hardly anyone would consider a paint program a simple application
Seriously? It's 19 fucking lines of C. Including the fucking curly braces. What would you consider a simple application?
> Seriously? It's 19 fucking lines of C. Including the fucking curly braces. What would you consider a simple application?
We don't consider programs to be simple or complex based on the number of lines of code used to write them, otherwise the linux kernel is even simpler than your paint program because a single-line grub script calls it.
Hell, I can make an even simpler program than your 19 line paint program, by writing a shell script that calls open-office in 1 line.
You still think number of lines of the calling program matters to determine complexity?
Simplicity (or complexity) is, for most, determined by what functions are available to the user. A program that does 20 different things is more complex than a program that does a single thing, even if those 20 different things are actually done by a library.
Your implicit claim seems to be that Yeso is a paint program being called by a 19-line C wrapper. Despite its name, this is not the case. The paint-program logic is all in μpaint.c.
μpaint has very few functions available to the user: draw a black pixel, draw a white pixel, and that's it. Such a simple paint program should not require dozens of lines of code, much less hundreds. (Even 19 is pushing it.) But with X-Windows or Win32 it does.
Yeso is just a minimal GUI library that removes the accidental complexity inflicted by X-Windows, which is what porcoda was wishing for, allowing simple GUIs to be written simply. It doesn't really help with complex GUIs because it doesn't have widgets.
I'm not the OP, but I was around for this stuff at the time (my first exposure to ~Unix was Andrew at CMU in like '88) and while I definitely look back at some of it nostalgically, most of my nostalgia is for the contemporaneous Mac OS. Open Look and the various X11 systems were pretty primitive, in comparison. And slow, for the most part, at least with the class of workstation I got to use.
A lot of the idiom of what we see today was actually developed by Microsoft, for Windows 95. That's fine, but it's also pretty monocultural. The classic Mac OS had a different set of assumptions than Windows did, but the industry has chased that Cairo dream.
I appreciate the flattery, but I'm not really an HCI expert. To my taste, GNOME, KDE, and modern versions of MacOS are all significantly easier to use than X-Windows in the 01990s, most of the time, as well as capable of doing a wider range of things. But, because their implementation is much more complex, they are often more difficult to debug when things go wrong, even though the available debugging tools are also better.
However, I don't think it's usable for my purposes. The one on p. 4 (figure 1-2) is fake, but there seem to be others that are real, like figure 1-6 on p. 13. Some of the others look wrong: the Edit dialog in figure 2-3 on p. 26 is pixelated as it should be, but seems to have resize corners of the wrong shape, extending not quite far enough along each edge. And in figure 2-6 on p. 28, there's what appears to be a real screenshot, but it's been edited to include a broken line. The curiously symmetric-looking pushpin in figure 4-7 on p. 69 seems to be missing its right edge; was that a bug in some version of XView or in the manual? The screenshots in figure 5.4 on p. 92 are totally fake and contain many errors, such as window borders that are the same thickness as resize-corner borders rather than twice as thick, scrollbar arrows that are not vertically centered in the scrollbar slider, solid black scrollbar cables (missing the proportion indicators), and missing cursors in the text windows.
Overall I don't feel like this manual is a reliable source for what XView widgets did or didn't look like. So when I see anomalies like, for example, the "Quit" command button in figure 3-1 (p. 45) which has a roundrect shape but with a corner-radius less than half the button's height, instead of exactly the button's height like other command buttons, I don't know whether that's a distinction between regular command buttons and "panel buttons" or just an error.
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.
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.
I really liked the XView toolkit. For a while it had a second life on Linux after Sun dropped it as it later was released as open source. But it had a lot of things in it that assumed a 32-bit system and so basically died when everyone went to 64-bit. In theory it could be patched, but I don't think anyone cares enough about it to do that these days.
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).
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.
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).
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
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.
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.
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 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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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?