For a long while now, what seems to me a reasonably simple project (re-creating the UI of a drawing program and making it straight-forward to re-create program state with annotations/highlighting) has been stalled because I can't find a design tool which works better than just placing the screen grabs in a vector drawing program and annotating by hand....
I'm about at the point where I'm going to just code everything up in METAPOST....
What made display postscript so great? I have only seen it mentioned in frothy marketing terms, not an in depth discussion of its approach, why it worked well, and how that compares to other alternatives.
You have to understand or have experienced how fragile the early graphics programs were --- basically a .eps file would be a black box of PostScript code, and would have a pixel image preview used on-screen (a classic gag was to use a resource editor to change the pixel preview) --- whether or no it would actually print/image correctly was something one wasn't certain of until holding the actual output in hand, and even then, it only held for a specific PostScript rasterizer/job setting. Sure, it was okay 99.99% of the time, but that 0.01% could be disastrous.
Display PostScript meant that the system used for on-screen display was the same as for actual printed output --- I _never_ had a job on my NeXT Cube fail to print to match the on-screen version. Moreover, one could do cool DPS programming such as custom strokes and fills in Altsys Virtuoso.
These days, PDF and Quartz (née Display PDF) mostly address the reliability (and presumably it's gotten even better since I left the industry), but I miss the programmability. Hopefully, using METAPOST will let me get some of that back.
Thanks, I'm starting to understand. So Display Postscript was useful because it let you know that what you put on the screen as a programmer would be what's printed?
And it allowed for cool graphics effects like custom strokes and fills.
So that primarily matters for stuff you want to print. It wouldn't matter as much for assembling a UI.
Windows uses (used?) WMF and pixels for on-screen display which would then either be used for printout via some conversion process, or a parallel construction would be maintained for output and the need to keep that in synch would often result in slight differences in output --- maybe there were other approaches.
One of the neat things in Display PostScript was one could use Interface Builder to add a print button to any window to get the underlying PS code.
In practice that's what you could do with HyperLook on NeWS:
SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS))
HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!
I've written lots and lots of user interfaces in PostScript. Just not Display PostScript. NeWS was a lot better for making interactive user interfaces than Display PostScript, and it came out a lot earlier.
Then I used HyperLook to implemented the user interface for SimCity, programming the entire interactive user interface in NeWS PostScript -- Display PostScript couldn't do anything like that:
Several years before that, I worked on the NeWS version of Gosling Emacs at UniPress, with multiple tabbed windows and pie menus. (Gosling also wrote NeWS, and much later Java.):
HCIL Demo - HyperTIES Authoring with UniPress Emacs on NeWS:
I used UniPress Emacs to develop an authoring tool for the NeWS version of HyperTIES, an early hypermedia browser, which we developed at the University of Maryland Human Computer Interaction Lab.
Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser:
I'd like to find a nicer development environment which made use of such options.
Apple killed off HyperCard, Runtime Revolution became LiveCode which when opensource, then closed source and now is only available for monthly license fees.
PythonCard never got to 1.0 and hasn't been updated in almost two decades...
(Python-enabled version of OpenSCAD) but the only user-facing options are the Customizer which is quite limited, and a repository of files which users can access --- unfortunately, trying to bring up a canvas or UI window crashes the app.
Since you already seem to be a fan of Python, how about CardStock? https://cardstock.run
There's also Decker, which by default is tightly sandboxed but has opt-in APIs for filesystem IO, invoking external processes, etc: http://beyondloom.com/decker/
You'll need a SparcStation emulator to run it, if not a real SparcStation. I've resisted the temptation because there's so much new code to write that I don't have much time to run old code. ;) Although it would be fun to run it in an emulator 1000 times faster than it ever ran on real hardware!
Here are some links I've found:
Unix & Linux: How to emulate the NeWS window system?
These are some screenshots of NeWS 1.1 running on SunOS 4.1.4 on QEMU that I took time ago.
Unfortunately QEMU SPARC decided to break again. Also, keyboard doesn't work yet (forcing me to use the SunView terminal emulator), but probably it's due to the keyboard script.
In any case, SunOS 4.1.4 comes with OpenWindows out of the box.
I'm about at the point where I'm going to just code everything up in METAPOST....
Makes me wish for Display PostScript again....