4 ms·

I always thought the Motif WM window decorations were very elegant. The rest I didn't care much about but this is nice, really nice. Could have been done a de

I always thought the Motif WM window decorations were very elegant. The rest I didn't care much about but this is nice, really nice. Could have been done a decade ago, why now?

DonHopkins 7y ago
https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47#4fa8 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... >X will not run in these 4 bit overlay planes. This is because I’m using Motif, which is so sophisticated it forces you to put a 1" thick border around each window in case your mouse is so worthless you can’t hit anything you aim at, so you need widgets designed from the same style manual as the runway at Moscow International Airport. My program has a browser that actually uses different colors to distinguish different kinds of nodes. Unlike a PC Jr, however, this workstation with $150,000 worth of 28 bits-per-pixel supercharged display hardware cannot display more than 16 colors at a time. If you’re using the Motif self-abuse kit, asking for the 17th color causes your program to crash horribly. >So, thinks I to myself cleverly, I shall run X windows on the graphics plane. This means X will not use the overlay planes, which have special hardware for cursors. This also means I cannot use the super cool 3D graphics hardware either, because in order to draw a cube, I would have to “steal” the frame buffer from X, which is surly and uncooperative about that sort of thing. >What it does give me, however, is a unique pleasure. The overlay plane is used for /dev/console, which means all console messages get printed in 10 Point Troglodyte Bold, superimposed in white over whatever else is on my screen, like for example, a demo that I may be happen to be giving at the time. Every time anyone in the lab prints to the printer attached to my machine, or NFS wets its pants with a timeout, or some file server threatens to go down in only 3 hours for scheduled maintenance, another message goes onto my screen like a court reporter with Turett’s syndrome. >The usual X commands for refreshing the screen are helpless to remove this incontinence, because X has no access to the overlay planes. I had to write a program in C to be invoked from some xterm window that does nothing but wipes up after the mess on the overlay planes. >My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?” >Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
- kevin_thibedeau 7y ago
  The UI is globally configurable via .Xdefaults. This lets you do things like add scroll wheel support to 30 year old Athena apps that never envisioned such magic. Motif respects it too.
  - DonHopkins 7y ago
    What do you type into .Xdefaults to enable pie menus in Motif? Surely after 30 years that would be easy, no? It could and should have been done more than three decades ago. The criticisms I made of the X Toolkit in 1987 (33 years ago) after attending the first X-Windows conference at MIT still apply. But as it turned out, we ended up with web browsers and web servers using exactly the same extensible architecture I was advocating (now called "AJAX"), leaving X-Windows and Motif in the dustbin of history. https://donhopkins.com/home/archive/NeWS/uwm.extensions.txt https://donhopkins.com/home/archive/NeWS/uwm.extensions.txt On February 23, 1987, Don Hopkins wrote on xpert@athena: >I see just the same problem with XToolKit. I would like to see the ToolKit as a client that you would normally run on the same machine as the server, for speed. Interactive widgets would be much more interactive, you wouldn't have to have a copy of the whole library in every client, and there would be just one client to configure. The big question is how do your clients communicate with it? Are the facilities in X11 sufficient? Or would it be a good idea to adopt some other standard for communication between clients? At the X conference, it was said that the X11 server should be used by clients to rendezvous with each other, but not as a primary means of communication. Why is that? >Setting a standard on any kind of key or mouse bindings would be evil. The window manager should be as transparent as possible. It solves lots of problems for it to be able to send any event to the clients. For example, how about function to quote an event that the window manager would normally intercept, and send it on? >Perhaps the window manager is the place to put the ToolKit? > -Don The people who wrote Xt, Athena, and Motif widgets and apps were not blind-sided by these issues, which are not "magic" or "rocket science". They just purposefully chose to dismiss and ignore them. The X-Windows Disaster: https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... Recreational Bugs talk [1989] by David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS): https://blog.dshr.org/2018/05/recreational-bugs.html https://blog.dshr.org/2018/05/recreational-bugs.html >"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami. https://groups.google.com/forum/#!search/%22xpert%22$20%22don$20hopkins%22/comp.windows.x/qJO5IgI_7HU/JXwAVovn5x0J https://groups.google.com/forum/#!search/%22xpert%22$20%22do... On September 19, 1989, Don Hopkins wrote on xpert@athena: >I think it's a pretty good idea to have the window manager, or some other process running close to the server, handle all the menus. Window managment and menu managment are separate functions, but it would be a real performance win for the window and the menu manager to reside in the same process. There should be options to deactivate either type of managment, so you could run, say, a motif window manager, and an open look menu manager at the same time. But I think that in most cases you'd want the uniform user interface, and the better performance, that you'd get by having both in one process. I think it would be possible to implement something like this with the NDE window manager in X11/NeWS. It's written in object oriented PostScript, based on the tNt toolkit, and runs as a light weight processes inside the NeWS server. This way, selecting from a menu that invokes a window managment function only involves one process (the xnews server), instead of three (the x server and the two "outboard" managers), with all the associated overhead of paging, ipc, and context switching. >Here's a message on a related subject that I sent to xpert a couple years back (before I'd heard of the ICCCM). I never did get much response, except that one person pointed out that that was precisely the problem that NeWS was designed to solve. ;-) >c(-; Once were done forging the menu manager standard, how about we do text editors, huh?) > -Don On November 28, 1992, Don Hopkins wrote on xpert@athena: >piewm - Pie Window Manager >PieWM is a window manager for the X window system that supports pie menus, and is based on the "tvtwm" virtual window manger. The labels of a pie menu are arranged in a circle around the cursor, and the pie menu selection is based on the direction of cursor motion between button clicks. >Pie menus are fast and reliable because of Fitt's Law: each of the items corresponds to a large slice shaped target area adjacent to the cursor, but in a different direction. They are fast because you don't have to move the cursor far, and the target areas are large. They are reliable because the further away from the menu center you move the cursor, the finer control you have over the selection. Because the selection is based on angle, you can "mouse ahead" quickly and reliably without looking at the screen, and the pie menus don't even pop up if you're fast enough. >For many tasks, pie menus are significantly faster and have lower error rates than linear menus. PieWM integrates pie and linear menus so you can use them interchangeably, with top level and submenus of either type, as appropriate. >In addition to user definable pie menus, "piewm" supports all the features of "tvtwm" including the virtual scrolling desktop, title bars, shaped windows, linear menus, several forms of icon management, user defined macro functions, click-to-type and pointer-driven keyboard focus, and user specified key and pointer button bindings. It also features graphical pie menu labels, and comes with a default set of window management pie menus, designed to support an efficient gestural style of interaction. However, the pie menu windows aren't circular, just rectangular. >For more information about pie menus, read "The Design and Implementation of Pie Menus," by Don Hopkins, Dr. Dobb's Journal, Dec. 1991 user interface issue, and "A Comparative Analysis of Pie Menu Performance," by Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman, Proc. CHI'88 conference, Washington D.C. >PieWM is available for anonymous ftp on </ftp.uu.net:tmp/piewm.tar.Z> and </bongo.garnet.cs.cmu.edu:pub/piewm.tar.Z> >Location (for anonymous FTP): Host: bongo.garnet.cs.cmu.edu (128.2.205.150) Dir: /pub File: piewm.tar.Z Size: 948239 bytes Host: ftp.uu.net (137.39.1.9) Dir: /tmp File: piewm.tar.Z Size: 948239 bytes >Could someone "in the know" please tell me how to get this into the appropriate X contributed software collection? > -Don

I always thought the Motif WM window decorations were very elegant. The rest I didn't care much about but this is nice, really nice. Could have been done a decade ago, why now?

DonHopkins 7y ago

https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47#4fa8 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... >X will not run in these 4 bit overlay planes. This is because I’m using Motif, which is so sophisticated it forces you to put a 1" thick border around each window in case your mouse is so worthless you can’t hit anything you aim at, so you need widgets designed from the same style manual as the runway at Moscow International Airport. My program has a browser that actually uses different colors to distinguish different kinds of nodes. Unlike a PC Jr, however, this workstation with $150,000 worth of 28 bits-per-pixel supercharged display hardware cannot display more than 16 colors at a time. If you’re using the Motif self-abuse kit, asking for the 17th color causes your program to crash horribly. >So, thinks I to myself cleverly, I shall run X windows on the graphics plane. This means X will not use the overlay planes, which have special hardware for cursors. This also means I cannot use the super cool 3D graphics hardware either, because in order to draw a cube, I would have to “steal” the frame buffer from X, which is surly and uncooperative about that sort of thing. >What it does give me, however, is a unique pleasure. The overlay plane is used for /dev/console, which means all console messages get printed in 10 Point Troglodyte Bold, superimposed in white over whatever else is on my screen, like for example, a demo that I may be happen to be giving at the time. Every time anyone in the lab prints to the printer attached to my machine, or NFS wets its pants with a timeout, or some file server threatens to go down in only 3 hours for scheduled maintenance, another message goes onto my screen like a court reporter with Turett’s syndrome. >The usual X commands for refreshing the screen are helpless to remove this incontinence, because X has no access to the overlay planes. I had to write a program in C to be invoked from some xterm window that does nothing but wipes up after the mess on the overlay planes. >My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?” >Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.

kevin_thibedeau 7y ago
The UI is globally configurable via .Xdefaults. This lets you do things like add scroll wheel support to 30 year old Athena apps that never envisioned such magic. Motif respects it too.
- DonHopkins 7y ago
  What do you type into .Xdefaults to enable pie menus in Motif? Surely after 30 years that would be easy, no? It could and should have been done more than three decades ago. The criticisms I made of the X Toolkit in 1987 (33 years ago) after attending the first X-Windows conference at MIT still apply. But as it turned out, we ended up with web browsers and web servers using exactly the same extensible architecture I was advocating (now called "AJAX"), leaving X-Windows and Motif in the dustbin of history. https://donhopkins.com/home/archive/NeWS/uwm.extensions.txt https://donhopkins.com/home/archive/NeWS/uwm.extensions.txt On February 23, 1987, Don Hopkins wrote on xpert@athena: >I see just the same problem with XToolKit. I would like to see the ToolKit as a client that you would normally run on the same machine as the server, for speed. Interactive widgets would be much more interactive, you wouldn't have to have a copy of the whole library in every client, and there would be just one client to configure. The big question is how do your clients communicate with it? Are the facilities in X11 sufficient? Or would it be a good idea to adopt some other standard for communication between clients? At the X conference, it was said that the X11 server should be used by clients to rendezvous with each other, but not as a primary means of communication. Why is that? >Setting a standard on any kind of key or mouse bindings would be evil. The window manager should be as transparent as possible. It solves lots of problems for it to be able to send any event to the clients. For example, how about function to quote an event that the window manager would normally intercept, and send it on? >Perhaps the window manager is the place to put the ToolKit? > -Don The people who wrote Xt, Athena, and Motif widgets and apps were not blind-sided by these issues, which are not "magic" or "rocket science". They just purposefully chose to dismiss and ignore them. The X-Windows Disaster: https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... Recreational Bugs talk [1989] by David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS): https://blog.dshr.org/2018/05/recreational-bugs.html https://blog.dshr.org/2018/05/recreational-bugs.html >"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami. https://groups.google.com/forum/#!search/%22xpert%22$20%22don$20hopkins%22/comp.windows.x/qJO5IgI_7HU/JXwAVovn5x0J https://groups.google.com/forum/#!search/%22xpert%22$20%22do... On September 19, 1989, Don Hopkins wrote on xpert@athena: >I think it's a pretty good idea to have the window manager, or some other process running close to the server, handle all the menus. Window managment and menu managment are separate functions, but it would be a real performance win for the window and the menu manager to reside in the same process. There should be options to deactivate either type of managment, so you could run, say, a motif window manager, and an open look menu manager at the same time. But I think that in most cases you'd want the uniform user interface, and the better performance, that you'd get by having both in one process. I think it would be possible to implement something like this with the NDE window manager in X11/NeWS. It's written in object oriented PostScript, based on the tNt toolkit, and runs as a light weight processes inside the NeWS server. This way, selecting from a menu that invokes a window managment function only involves one process (the xnews server), instead of three (the x server and the two "outboard" managers), with all the associated overhead of paging, ipc, and context switching. >Here's a message on a related subject that I sent to xpert a couple years back (before I'd heard of the ICCCM). I never did get much response, except that one person pointed out that that was precisely the problem that NeWS was designed to solve. ;-) >c(-; Once were done forging the menu manager standard, how about we do text editors, huh?) > -Don On November 28, 1992, Don Hopkins wrote on xpert@athena: >piewm - Pie Window Manager >PieWM is a window manager for the X window system that supports pie menus, and is based on the "tvtwm" virtual window manger. The labels of a pie menu are arranged in a circle around the cursor, and the pie menu selection is based on the direction of cursor motion between button clicks. >Pie menus are fast and reliable because of Fitt's Law: each of the items corresponds to a large slice shaped target area adjacent to the cursor, but in a different direction. They are fast because you don't have to move the cursor far, and the target areas are large. They are reliable because the further away from the menu center you move the cursor, the finer control you have over the selection. Because the selection is based on angle, you can "mouse ahead" quickly and reliably without looking at the screen, and the pie menus don't even pop up if you're fast enough. >For many tasks, pie menus are significantly faster and have lower error rates than linear menus. PieWM integrates pie and linear menus so you can use them interchangeably, with top level and submenus of either type, as appropriate. >In addition to user definable pie menus, "piewm" supports all the features of "tvtwm" including the virtual scrolling desktop, title bars, shaped windows, linear menus, several forms of icon management, user defined macro functions, click-to-type and pointer-driven keyboard focus, and user specified key and pointer button bindings. It also features graphical pie menu labels, and comes with a default set of window management pie menus, designed to support an efficient gestural style of interaction. However, the pie menu windows aren't circular, just rectangular. >For more information about pie menus, read "The Design and Implementation of Pie Menus," by Don Hopkins, Dr. Dobb's Journal, Dec. 1991 user interface issue, and "A Comparative Analysis of Pie Menu Performance," by Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman, Proc. CHI'88 conference, Washington D.C. >PieWM is available for anonymous ftp on </ftp.uu.net:tmp/piewm.tar.Z> and </bongo.garnet.cs.cmu.edu:pub/piewm.tar.Z> >Location (for anonymous FTP): Host: bongo.garnet.cs.cmu.edu (128.2.205.150) Dir: /pub File: piewm.tar.Z Size: 948239 bytes Host: ftp.uu.net (137.39.1.9) Dir: /tmp File: piewm.tar.Z Size: 948239 bytes >Could someone "in the know" please tell me how to get this into the appropriate X contributed software collection? > -Don