Steve turning in his grave

▲ InsideOutSanta 6 hours ago | parent | next [-]

Relevant quote from https://www.folklore.org/Shut_Up.html:

We showed [Gates] how the Macintosh mouse cursor moved smoothly, in a flicker-free fashion.

"What kind of hardware do you use to draw the cursor?", he asked. Many current personal computers had special hardware to draw small bitmaps called "sprites", and he thought we might be doing something similar.

▲ Stitch4223 5 hours ago | parent | next [-]

This quote from 1981 stresses that taking away a responsive cursor is the most arrogant and disrespectful bug.

The audacity of developers to restart the discussion whether the mouse should follow user input induces rage on so many levels.

▲

InsideOutSanta 5 hours ago | parent [-]

Yeah, the cursor is your most direct embodiment in the computer. Messing with it is like somebody pushing your arm when you're trying to cut tomatoes. It's a major determinant in how good it feels to use a computer (and whether you cut your fingers).

But there were a lot of things we learned in the 80s and 90s that we have largely forgotten today, like "make clickable things look clickable" and "don't use Yes and No as button labels" and "active windows should look different from inactive windows."

▲

DonHopkins 3 hours ago | parent [-]

Alan Dye would disagree.

https://daringfireball.net/2025/12/bad_dye_job

	▲	pmontra 31 minutes ago \| parent [-]
		I think you forgot the /s Anyway, interesting story. I didn't know what a key window is. I googled. It's the active window.

▲ DonHopkins 3 hours ago | parent | prev [-]

SGIs and Suns had overlay planes just for that. In fact SGI 4Sight would draw the popup menus in the overlay plane, too, since reading back the color framebuffer to draw cursors or perform xor highlighting or restoring the background after popping down menus was extremely expensive with that hardware.

Sun's framebuffers with 8 bit color + 1 bit monochrome + 1 bit enable (like the cgfour / GX aka Lego graphics accelerator) put the cursor in the monochrome layer, and NeWS supported it as an overlay plane, an optimization of xor drawing and undrawing. The enable layer would switch between the color and monochrome layers on a per-pixel basis.

With NeWS, I could open up the enable and monochrome layers directly and draw into them with PostScript to perform temporary non-destructive highlighting, and make monochrome overlay windows that didn't damage the color windows underneath. But it was a bit of a hack (much uglier than this cursor lag fix). Here is a window subclass that lifts a monochrome window into the overlay plane so it doesn't damage color windows behind it:

https://donhopkins.com/home/archive/psiber/cyber/overlay.ps

  % Overlay plane compatibility hack for cg4 frame buffer.
  % This is a nebulous layer abstracted from a messy program, to make it run 
  % on generic NeWS servers. It should be rethought and rewritten. Repent!
  % 
  % Requires the devices /dev/cgfour0, /dev/cgfour0_ovl, and /dev/cgfour0_ove
  % (which can all be major 39 minor 0, or whatever), and the following patch 
  % to the NeWS 1.1 server sources (but X11/NeWS doesn't need to be patched!),
  % in order to take advantage of a cg4 under NeWS 1.1 (Otherwise it falls back
  % to using exclusive-or).

[...]

  % Damn damn damn! X11/NeWS Version 1.0 FCS on a cg4 can open up the
  % enable plane, but there's a bug that trashes the enable plane color map,
  % so we can draw in gray scales but we can't draw in white (black?).

The "Pseudo Scientific Visualizer" used it by making a PSVisualizerWindow subclass of OverlayWindow:

https://donhopkins.com/home/archive/psiber/cyber/mics.ps

And the popup pointing hand shaped callout window also used it so it didn't have to repaint the color window underneath when you moved or dismissed it:

https://donhopkins.com/home/archive/psiber/cyber/pointer.ps

▲ flukas88 7 hours ago | parent | prev [-]

[flagged]