If one GUI's not enough for your SPARC workstation, try four
oldvcr.blogspot.com
oldvcr.blogspot.com
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?
• http://toastytech.com/guis/indexunix.html
• https://guidebookgallery.org/ads/magazines/openlook/deadline...
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.
Here's a basic pomodoro clock written in bash: https://gist.github.com/lelanthran/bbbcf5c8b6b26c9bc0263384a...
The best things I've found for simple GUI programs these days are Tk and HTML+JS.
It does GUI, according to most common understandings of the term. From https://en.wikipedia.org/wiki/Graphical_user_interface:
> 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.
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?
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.
μ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.
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.
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.
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.
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.
Sun also had a nice add-on graphics library for XView called Slingshot. It might have my first-ever open source contribution (just a bug fix).
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.
That’s literally never caused me a problem
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.
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.
I hope you get around to writing up your thoughts! I'd be interested in providing feedback on drafts if that would be useful.
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)
Definitely an interesting path-not-taken.
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.
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.
FWIW, this was SUNY Buffalo. Where were you?
I love the look it started and that culminated with XViews: check 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.
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.