Did you find my criticism of how X-Windows sucks in the Unix Haters Handbook as unfair and un-credible and lazy as you found the book's criticism of NFS? Or my criticism of OLWM and XBugTool, which also both sucked?
https://web.archive.org/web/20000423081727/http://www.art.ne...
Did you ever fix those high priority OLWM bugs I reported with XBugTool that OLWM unnecessarily grabbed the X11/NeWS server all the time and caused the input queue to lock up so you couldn't do anything for minutes at a time? And that related bug caused by the same grab problem that the window system would freeze if you pressed the Help key while resizing a window? Or manage to get OLWM's showcase Open Look menus to pin up without disappearing for an instant then reappearing in a different place, with a totally different looking frame around it, and completely different mouse tracking behavior? That unnecessary song and dance completely ruined the "pinned menu" user experience and pinned menu metaphor's illusion that it was the same menu before and after pinning. While TNT menus simply worked and looked perfectly and instantly when you pinned them, because it WAS the same menu after you pinned it, so it didn't have to flicker and change size and location and how it looked and behaved. Ironically, the NeWS Toolkit was MUCH better at managing X11 windows than the OLWM X11 window manager ever was, because our NeWS based X11 window manager "OWM" was deeply customizable and had a lot more advanced features like multiple rooms, scrolling virtual desktops, tabbed windows supporting draggable tabs on all four edges, resize edges, custom resize rubber banding animation, and pie menus, as well. It also never grabbed and froze the window server, and it took a hell of a lot less time and resources to develop than OLWM, which never lifted a finger to support TNT the way TNT bent over backwards to support X11.
NeWS Tab Window Demo -- Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0. Developed and demonstrated by Don Hopkins:
https://www.youtube.com/watch?v=tMcmQk-q0k4
https://web.archive.org/web/19981203002306/http://www.art.ne...
>I39L window management complicates pinned menus enormously. TNT menus pin correctly, so that when you push the pin in, the menu window simply stays up on the screen, just like you'd expect. This is not the case with XView or even OLWM. Under an I39L window manager, the Open Look pinned menu metaphor completely breaks down. When you pin an X menu, it dissappears from the screen for an instant, then comes back at a different place, at a different size, with a different look and feel. If you're not running just the right window manager, pinned menus don't even have pins! There is no need for such "ICCCM compliant" behavior with TNT menus. When they're pinned, they can just stay there and manage themselves. But were TNT windows managed by an external I39L window manager, they would have to degenerate to the level of X menus.
https://web.archive.org/web/20000602215640/http://www.art.ne...
>I could go on and on, but I just lost my wonderful xbugtool, because I was having too much fun way too fast with those zany scrolling lists, so elmer the bug server freaked out and went off to la-la land, causing xbugtool to lock the windows and start "channeling", at the same time not responding to any events, so when I clicked on the scrolling list, the entire window system froze up and I had to wait for the input queue lock to break, but by the time the lock finally broke (it must have been a kryptonite), xbugtool had made up its mind, decided to meet its maker, finished core dumping, and exited with an astoundingly graceful thrash, which was a totally "dwim" thing for it to do at the time, if you think about it with the right attitude, since I had forgotten what I wanted to file a bug against in the first place anyway, and totally given up the idea of ever using bugtool to file a bug against itself, because bugtool must be perfect to have performed so splendidly!
From the news-makers archive:
>From: Skip Montanaro <crdgw1!montnaro@uunet.uu.net> Date: Feb 16, 1990
>Charles Hedrick writes concerning XNeWS problems. I have a couple of comments on the XNeWS situation.
>The olwm/pswm interface appears (unfortunately) to be stable as far as Sun is concerned. During XNeWS beta testing I complained about the lack of function key support, but was told it was an OpenLook design issue. (NeWS1.1 supported function keys, and you could do it in PostScript if you like.) Sun likes to tout how OpenLook is standard, and was designed by human factors types. As far as I'm concerned, nobody has had enough experience with good user interfaces to sit down and write a (horribly large, hard-to-read) spec from which a window manager with a "good" look-and-feel will be created. I'm convinced you still have to experiment with most user interfaces to get them right.
>As a simple example, consider Don Hopkins' recent tabframes posting. An extra goody added in tabframes is the edge-stretch thingies in the window borders. You can now stretch one edge easily, without inadvertently stretching the other edge connected to your corner-stretch thingie. Why did the OpenLook designers never think of this? SunView had that basic capability, albeit without visible window gadgetry. It wasn't like the idea was completely unheard of.
>I agree that running the XNeWS server with an alternate window manager is a viable option. Before I got my SPARCStation I used XNeWS in X11ONLY mode with gwm, which was the only ICCCM-compliant window manager I had available to me at the time. If you choose to use twm with XNeWS, I recommend you at least try the X11R4 version.
>From: William McSorland - Sun UK - Tech Support <will@willy.uk> Date: May 14, 1991 Subject: 1059370: Please evaluate
>Bug Id: 1059370 Category: x11news Subcategory: olwm Bug/Rfe: rfe Synopsis: OLWM does a Server Grab while the root menu is being displayed. Keywords: select, frame_busy, presses, left, mouse, server, grabbed Severity: 5 Priority: 5 Description:
>Customer inisisted on having this logged as a RFE and so:-
>When bringing up the root menu inside OW2.0 the window manager does a Server Grab hence forcing all its client applications output to be queued by the server, but not displayed.
>The customer recommends that this should be changed to make olwm more friendly.
>Apparently a number of other window managers don't do a server grab while the root menu is being displayed.
>From: Don Hopkins <hopkins@sun.com> Subject: 1059974: Bug report created
>Bug Id: 1059974 Category: x11news Subcategory: server Bug/Rfe: bug Synopsis: I have no mouse motion and my input focus is stuck in xbugtool!!! Keywords: I have no mouth and I must scream [Harlan Ellison] Severity: 1 Priority: 1 Description:
>This is my worst nightmare! None of my TNT or XView applications are getting any mouse motion events, just clicks. And my input focus is stuck in xbugtool, of all places!!! When I click in cmdtool, it gets sucked back into xbugtool when I release the button! And I'm not using click-to-type! I can make selections from menus (tnt, olwm, and xview) if I click them up instead of dragging, but nobody's receiving any mouse motion!
>I just started up a fresh server, ran two jets and a cmdtool, fired up a bugtool from one of the jets (so input focus must have been working then), and after xbugtool had throbbed and grunted around for a while and finally put up its big dumb busy window, I first noticed something was wrong when I could not drag windows around!
>Lucky thing my input focus ended up stuck in xbugtool!
>The scrollbar does not warp my cursor either... I can switch the input focus to any of xbugtool's windows, but I can't ... -- oomph errrgh aaaaahhh! There, yes!
>Aaaaah! What a relief! It stopped! I can move my mouse again!! Hurray!!! It started working when I opened a "jet" window, found I could type into it, so I moved the mouse around, the cursor disappeared, I typed, there were a couple of beeps, I still couldn't find the cursor, so I hit the "Open" key, the jet closed to an icon, and I could type to xbugtool again! And lo and behold now I can type into the cmdtool, too! Just by moving my cursor into it! What a technological wonder! Now I can start filing bug reports against cmdtool, which was the only reason I had the damn thing on my screen in the first place!!! I am amazed at the way the window system seems to read my mind and predict my every move, seeming to carry out elaborate practical jokes to prevent me from filing bugs against it. I had no idea the Open Windows desktop had such sophisticated and well integrated interclient communication!
>From: Don Hopkins <hopkins@sun.com> Subject: 1059976: Bug report created Date: May 21, 1991
>Bug Id: 1059976 Category: x11news Subcategory: olwm Bug/Rfe: bug Synopsis: OLWM menus are inconsistant with the rest of the desktop, Keywords: pinned menus, defaults, tracking, inconsistant look and feel, yet another open look toolkit Severity: 2 Priority: 2 Description:
>You can't set the default of a pinned menu by holding down the control key and clicking over an item.
>Pressing the middle button over the default of a pinned menu erases the default ring.
>You can't set the default of a unpinned menu by pressing the control key then the popping it up by pressing the MENU button on the mouse.
>When you're tracking a menu, and press the control key, the highlighting changes properly, from depressed to undepressed with a default ring, but when you release the control key before releasing the MENU button on the mouse, the highlighting does not change back to depressed without a default ring. Instead it stays the same, then changes to un-depressed without a default ring at the next mouse movement, and you have to move out and back into the menu item to see it depressed again.
>When you're dragging over a menu, then press the control key to set the default, then release the mouse button to make a selection, without releasing the control key, OLWM menus are stuck in default-setting mode, until the next time it sees a control key up transition while it is tracking a menu.
>Clicking the SELECT button on the abbreviated menu button on the upper left corner of the window frame (aka the close box or shine mark) should select the frame menu default, instead of always closing the window.
>The tracking when you press and release the control key over a menu pin is strange, as well. Push-pins as menu defaults are a dubious concept, and the HIT people should be consulted for an explaination or a correction.
>When you press the menu button in a submenu, it does not set the default of the menu that popped up the submenu, the way XView and TNT menus do. This behaviour also needs clarification from the HIT team.
>Pinned OLWM menus do not track the same way as unpinned menus. When you press down over an item, and drag to another item, the highlighting does not follow the mouse, instead the original item stays highlighted. The item un-highlights when the mouse exits it, but the menu highlighting should track the item underneath the cursor when the user is holding the mouse button down, just like they do with a non-pinned menu. The current behavior misleads you that the item would be selected if the button were released even though the cursor is not over the menu item, and is very annoying when you press down over a pinned menu item and miss the one you want, and expect to be able to simply drag over to the one you meant to hit.
>If we are crippling our menus this way on purpose, because we are afraid Apple is going to sue us, then Apple Computer has already done damage to Sun Microsystems without even paying their lawyers to go to court. We licensed the technology directly from Xerox, and we should not make our users suffer with an inferior interface because we are afraid of boogey-men.
>In general, OLWM is yet another OpenLook toolkit, and its menus are unlike any other menus on the desktop. This is a pity because the user interacts so closely with OLWM, and the conspicuous inconsistancy between the window manager and the Open Look applications that it frames leads people to expect inconsistancy and gives the whole system a very unreliable, unpredictable feel.
Other email about OLWM server grabs:
>1056853 x11news/x11: >OW Exit notice hangs system causing input queue lock brokens
>Status: Desktop integration issue. Marked in bug traq as evaluated.
>This is an X-and-NeWS integration issue and is a terribly complicated problem. X11 does not expect that server-internal locking will ever time out. X11 has similar situations to the one mentioned in the bug report where a client grabs the server and then a passive grab triggers. And it works fine. The difference is that the effect of the passive grab doesn't time-out, thereby causing an inconsistent state.
>One possibility cited for a fix is to change the server to stop distributing events to synchronous NeWS interests while an X client has the server grabbed. But this might only result in moving the problem around and not in solving the real problem.
>According to Stuart Marks, olwm could grab the keyboard and mouse before grabbing the server and that might get around this particular problem.
>ACTION: Stuart Marks should be supported in making this change.
Stewart, is any of that lazy unfair criticism?
That's an impressively long time for anyone born and working professionally for Sun Microsystems before The Early Years of NFS to hold the incorrect opinion that NFS doesn't suck. ;) So when smarks makes the provably false claim that NFS doesn't suck, and accuses me of being "lazy" for disagreeing with that, I'm glad I was diligent enough to keep the receipts, and generous enough to share them.
I just don't like being called "lazy" for saying "NFS Sucks" by the same guy whose window manager was so lazy it unnecessarily grabbed the X11 server all the time and locked up the window system for minutes at a time, and whose menus flickered and moved and resized and drew and tracked differently when you pinned them, since I've fairly and un-lazily written in great detail about NFS and other Sun security issues numerous times, and un-lazily implemented OPEN LOOK menus and a TNT X11/NeWS window manager that didn't suffer from all those usability problems.
Speaking of lazy menus: Correctly implemented Open Look pinned menus actually had to support two identical hot-synced menus existing and updating at the same time, in case you pinned a menu, then popped the same menu up again from the original location. The TNT menus would lazily create a second popup menu clone only when necessary (when it was already pinned and you popped it up again), and correctly supported tracking and redrawing either menu, setting the menu default item with the control key and programmatically changing other properties by delegating messages to both menus, so it would redraw the default item ring highlighting on both menus when you changed the default, or any other property.
Object oriented programming in The NeWS Toolkit was a lot more like playing with a dynamic Smalltalk interpreter, than pulling teeth with low level X11 programming in C with a compiler and linker plowing through mountains of include files and frameworks, so it was actually interactively FUN, instead of excruciatingly painful, and we could get a lot more work done in the same amount of time than X11 programmers.
Consequently, TNT had a much more thorough and spec-consistent implementation of pinned menus than OLWM, XView, OLIT, or MOOLIT, because NeWS was simply a much better window system that X11, and we were not lazy and didn't choose to selectively ignore or reinterpret the more challenging parts of the Open Look spec, like the other toolkits did because X-Windows and C made life so difficult.
See the comments in the "Clone" method and refs to the "PinnedCopy" instance variable in the PostScript TNT menu source code:
https://donhopkins.com/home/code/menu.ps
% Copy this menu for pinning. Factored out to keep the pinning code
% easier to read. The clone has a few important differences, such as
% no pin or label regardless of the pin/label of the original, but is
% otherwise as close a copy as we can manage.
https://donhopkins.com/home/archive/HyperLook/tnt-menu-desig...
Funnily enough I've been writing a pure-Smalltalk X11 protocol implementation recently, for Squeak, and it starts to have some of the feel you describe. It generates Smalltalk code from the XML xcbproto definitions. It's at the point now where you can send X11 requests interactively in a Workspace, etc., which is fun ("playing with a dynamic Smalltalk interpreter"), and I'm working on integrating it with Morphic. Anyway, thought you might enjoy the idea.