What a flippant cliché. Why don't you put as much time and effort and thought into your comments and money into supporting open source developers as you demand other people to put into forking code bases and rearchitecting enormous monolithic socially and economically entrenched pieces of software without getting paid for their time?
If you're going to criticize, then at least make some constructive comments about how you think they SHOULD do it instead of just telling them to fork off.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
https://donhopkins.com/home/archive/NeWS/uwm.extensions.txt
Date: Mon, 23 Feb 87 18:31:00 EST
From: Don Hopkins <brillig.umd.edu!don@harvard>
To: cartan!weyl.Berkeley.EDU!rusty@ucbvax.berkeley.edu
Cc: xpert@athena.mit.edu
Subject: Uwm extensions, perhaps?
[...] 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
https://groups.google.com/g/comp.windows.x/c/qJO5IgI_7HU/m/J...
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. [...]
