You can directly support multiple mice and other input devices by talking to the USB driver directly instead of using the single system cursor and mouse event input queue, and drawing your own cursors manually. (And DirectX / Direct Input lets you do stuff like that on Windows.) But you have to forsake all the high level stuff that assumes only one cursor, like the user interface toolkit. That is what Bret Victor meant by "bolted-on hack that doesn't alter the single-user design of our present computers".
That's ok for games that implement their own toolkit, or use one you can easily bolt on and hack, but not for anything that needs to depend on normal built-in system widgets like text editors, drop-down menus, etc. (And if you roll your own text fields instead of using the system ones, you end up having to reimplement all kinds input methods, copy/paste/drag/drop, and internationalization stuff, which is super-tricky, or just do without it.)
I implemented multi-player cursors in SimCityNet for X11 (which opened multiple X11 displays at once), but I had to fix some bugs in TCL/Tk for tracking menus and buttons, and implemented my own pie menus that could handle being popped up and tracking on multiple screens at once. TCL menus and buttons were originally using global variables for tracking and highlighting that worked fine on one X11 display at once, but that caused conflicts when more than one user was using a menu or button at the same time, so it needed to store all tracking data in per-display maps. It doesn't make sense to have a global "currently highlighted button" or a "current menu item" since two different ones might be highlighted or selected at once by different people's cursors.
And I implemented special multi-user "voting" buttons that required unanimous consent to trigger (for causing disasters, changing the tax rate, etc).
I had to implement multi-user cursors in "software" by drawing them on the map manually, instead of using X11 cursors.
I wrote about that earlier in a discussion about Wayland and X-Windows:
And it's in the direction of multi-user collaboration that X-Windows falls woefully short. Just to take the first step, it would have to support separate multi-user cursors and multiple keyboards and other input devices, which is antithetical to its singleminded "input focus" pointer event driven model. Most X toolkits and applications will break or behave erratically when faced with multiple streams of input events from different users.
For the multi-player X11/TCL/Tk version of SimCity, I had to fix bugs in TCL/Tk to support multiple users, add another layer of abstraction to support multi-user tracking, and emulate the multi-user features like separate cursors in "software".
Although the feature wasn't widely used at the time, TCL/Tk supported opening connections to multiple X11 servers at once. But since it was using global variables for tracking pop-up menus and widget tracking state, it never expected two menus to be popped up at once or two people dragging a slider or scrolling a window at once, so it would glitch and crash whenever that happened. All the tracking code (and some of the colormap related code) assumed there was only one X11 server connected.
So I had to rewrite all the menu and dialog tracking code to explicitly and carefully handle the case of multiple users interacting at once, and refactor the window creation and event handling code so everything's name was parameterized by the user's screen id (that's how you fake data structures in TCL and make pointers back and forth between windows, by using clever naming schemes for global variables and strings), and implement separate multi-user cursors in "software" by drawing them over the map.
That's ok for games that implement their own toolkit, or use one you can easily bolt on and hack, but not for anything that needs to depend on normal built-in system widgets like text editors, drop-down menus, etc. (And if you roll your own text fields instead of using the system ones, you end up having to reimplement all kinds input methods, copy/paste/drag/drop, and internationalization stuff, which is super-tricky, or just do without it.)
I implemented multi-player cursors in SimCityNet for X11 (which opened multiple X11 displays at once), but I had to fix some bugs in TCL/Tk for tracking menus and buttons, and implemented my own pie menus that could handle being popped up and tracking on multiple screens at once. TCL menus and buttons were originally using global variables for tracking and highlighting that worked fine on one X11 display at once, but that caused conflicts when more than one user was using a menu or button at the same time, so it needed to store all tracking data in per-display maps. It doesn't make sense to have a global "currently highlighted button" or a "current menu item" since two different ones might be highlighted or selected at once by different people's cursors.
And I implemented special multi-user "voting" buttons that required unanimous consent to trigger (for causing disasters, changing the tax rate, etc).
I had to implement multi-user cursors in "software" by drawing them on the map manually, instead of using X11 cursors.
I wrote about that earlier in a discussion about Wayland and X-Windows:
https://news.ycombinator.com/item?id=19732733
And it's in the direction of multi-user collaboration that X-Windows falls woefully short. Just to take the first step, it would have to support separate multi-user cursors and multiple keyboards and other input devices, which is antithetical to its singleminded "input focus" pointer event driven model. Most X toolkits and applications will break or behave erratically when faced with multiple streams of input events from different users.
>https://tronche.com/gui/x/xlib/input/XGrabPointer.html
For the multi-player X11/TCL/Tk version of SimCity, I had to fix bugs in TCL/Tk to support multiple users, add another layer of abstraction to support multi-user tracking, and emulate the multi-user features like separate cursors in "software".
Although the feature wasn't widely used at the time, TCL/Tk supported opening connections to multiple X11 servers at once. But since it was using global variables for tracking pop-up menus and widget tracking state, it never expected two menus to be popped up at once or two people dragging a slider or scrolling a window at once, so it would glitch and crash whenever that happened. All the tracking code (and some of the colormap related code) assumed there was only one X11 server connected.
So I had to rewrite all the menu and dialog tracking code to explicitly and carefully handle the case of multiple users interacting at once, and refactor the window creation and event handling code so everything's name was parameterized by the user's screen id (that's how you fake data structures in TCL and make pointers back and forth between windows, by using clever naming schemes for global variables and strings), and implement separate multi-user cursors in "software" by drawing them over the map.
Multi Player SimCityNet for X11 on Linux:
https://www.youtube.com/watch?v=_fVl4dGwUrA
>Demo of the latest optimized Linux version of Multi Player SimCity for X11. Ported to Unix, optimized for Linux and demonstrated by Don Hopkins.
X11 SimCity Pie Menus:
https://www.youtube.com/watch?v=Jvi98wVUmQA
Multi-user menu tracking (added "@$screen" parameterizations):
https://github.com/SimHacker/micropolis/blob/master/micropol...
Opening multiple X11 displays (multiple toplevel "head" windows per screen, each with a unique id, using $win parameterization):
https://github.com/SimHacker/micropolis/blob/master/micropol...