Facts about Wayland vs X

The fact is Wayland is less capable in this area and the project refuses to admit to it. If all you want is VNC that's a win for you, but it's insulting to say it's objectively better when many of us find it strictly worse.

> Anything you do that changes the distribution of events (like moving the cursor in or out of a window changes the input focus, manipulating the window hierarchy changes the mapping from event position to window target, etc) needs to have its handler executed BEFORE any other events are distributed.

Yes, this is definitely a shortcoming of X. I have been thinking about this for some months; I believe that a solution which maintains the client-server model is to replace server grabs with transactions, which may be initiated by either the client or the server. Obviously this is not backward-compatible as it requires client support as well as server support.

You can also achieve glitch-free focus-follows mouse using active input grabs. You don't even need to continuously grab them; you need only grab for the first event of each sequence of keyboard / mouse events.

There are a lot of good reasons to have a scriptable window manager, with a scripting language tightly integrated with the window system.

When I started hacking X10, I wanted to implement pie menus for it. There was a cheezy little library called "XMenu" that was intended for other programs to use to make menus, which I adapted for pie menus, but no programs actually used it, and it was not very configurable (no menu definition language, just an api), plus its model and api was not well suited for pie menus. And once you have menus, you need a way to make selecting their items actually do something!

So I adapted the "uwm" window manager to support pie menus, so you could define your own pie menus and linear menus in your .uwmrc file. Because a window manager could really benefit from pie menus: lots of the commands are spatially oriented and can be arranged in appropriate mnemonic directions, and they have a fixed set of common window management commands that can be thoughtfully arranged into a set of efficient pie menus, as well as a menu definition language to enable users to create custom menus for running apps, connecting with remote hosts, etc.

I wanted to experiment with different styles of menu tracking, mouse ahead, display pre-emption, feedback, screen edge handling, rolling between pie menus and linear menus, invoking window management commands, and stuff like that, and uwm's C code was not very flexible in that regard.

We also wanted to perform a controlled experiment comparing the selection time and error rate of pie menus and linear menus, so I needed to program the window manager to administer the experiment, define and randomize the menus, prompt the user to select from pie and linear menus, time the menu selections, report the statistics, etc.

I had been using Mitch Bradley's "Forthmacs", which was a very nice Forth system for the 68k. (It eventually evolved into the Sun 4 Forth boot ROMS, OpenFirmware, and the OLPC boot ROMs). It was capable of dynamically linking in C code (well not dll's or shared libraries, but it would actually call the linker to relocate the code to the appropriate place in Forth's address space, read in the relocated code, and write Forth wrappers, so you could call C code from Forth, pass parameters, etc -- SunOS 4.2 didn't have relocatable shared libraries or light weight threads back then, so Forth had to do a lot of the heavy lifting to plug in C code. But Forth was a really great way to integrate a library into an interactive extension language, call it from the Forth command line, build on top of C code in Forth, call back and forth between C and Forth, play around with it from the Forth command line, etc).

So I refactored UWM a bit so I could plug it into Forth and rewrite the main loop and event tracking code in Forth, and write higher level menu tracking and window management code in Forth, and administer the experiment in Forth. For example, you could pick up a window and throw it, and it would fork off a light weight Forth task to make it bounce around on the screen! See the "fling" code: http://www.donhopkins.com/home/archive/piemenu/uwm1/hacks.f

I didn't realize it at the time, but it foreshadowed what I would later do with NeWS and PostScript.

It was very nice to have a window manager that I could program in Forth, because that was my scripting language of choice at the time, and I could integrate it with C code and Xlib. But then I learned about SunDew aka NeWS (I read the SunDew article in Methodology of Window Management: http://www.chilton-computing.org.uk/inf/literature/books/wm/... and saw Gosling give a talk about it at SUG).

I visited James Gosling, David Rosenthal, Owen Densmore and Mitch Bradley at Sun, who showed me NeWS, and gave me a beta copy to play around with. I learned to program PostScript, and switched from Forth to PostScript for programming windows managers, pie menus and user interfaces. PostScript is a much better language for that than Forth, not only because it has a nice graphics model, but because it's a lot more like Lisp or Smalltalk than Forth, and NeWS extended it with an object oriented programming system that used the dictionary stack to implement inheritance, with which we built user interface toolkits and entire apps, like a visual PostScript programming environment and debugger: http://www.donhopkins.com/drupal/?q=node/97

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

+ used PostScript code instead of JavaScript for programming.

+ used PostScript graphics instead of DHTML and CSS for rendering.

+ used PostScript data instead of XML and JSON for data representation.

Some years passed, NeWS was canceled, some other stuff happened, the web came along, the Mac stopped sucking so badly and adopted Unix and NeXT Step, the term AJAX was coined to describe what NeWS was doing all along and what X refused to do for political reasons, and JavaScript took over the world.

So back to real-time: I just recently installed and read the source code of a nice Mac tiling window manager called "Slate": https://github.com/jigish/slate . It look very clean and well designed and even simple, and I think it has a lot of potential! You can program it in JavaScript (it makes an invisible web browser and injects a JavaScript API to the application into it, and delivers events to JavaScript when windows move or change state, calling JavaScript handlers that can call back and manipulate the windows to achieve tiling window layout, and so on and so forth), and it exposes some of the Mac's accessibility API to JavaScript, which brings a lot of power to the table.

Slate is very powerful and flexible, and I'd like to teach it to support pie menus (and other user interface widgetry, maybe by simply popping a web browser up in a window), so you can define pie menus in JSON for window and application management or whatever you want, and script their behavior in JavaScript, and manipulate windows and apps via the accessibility API from JavaScript. Maybe throw in an http server so your window manager can surface web pages and interactive user interfaces in web browsers (that would be a good way to implement pie menus in JavaScript and html, instead of coding them up in Objective C).

I think that Slate takes exactly the right approach with JavaScript, and I hope to get my head around it and do some work with it, like making pie menus for window management, app launching and controlling the accessibility API.

The thing is that X's configurability sucks (.XDefaults files, and the various ad-hoc syntaxes of the various window manager configuration files, which may or may not run m4 over them so you have yet another crazy macro syntax layer).

Since the user interface toolkit and window manager in NeWS was defined as PostScript classes loaded into the window server and shared by all applications, you could subclass or patch or redefine them (usually when NeWS was starting up), and as long as they still supported the same APIs (which is a big limiting factor on what you could do of course -- pie menus emulated the linear menu api, but a linear menu api is not necessarily the best api for pie menus), then ALL applications would pick up the changes.

Of course there were some things you could change on the fly (like the default menu class, except that if apps cached instances of menus instead of recreating them, they would not change), but you could not redefine the window frames on the fly since they already were created, and reparenting the clients into new frames wasn't trivial.

There was a function to change the default menu class used by the window manager, and it knew how to create new menus with the new classes based on the old menus, for the root menu, and also the window frame menus. But any applications that created menus would have to be in on that game. It would certainly be possible to make a MenuClassChanged event to tell them to recreate all their menus, but nobody ever bothered to do that, since it wasn't something that people needed very often, and would require a lot of work for application developers.

You have to weigh how much the flexibility costs in terms of complexity and efficiency against how much people really need the flexibility, and at what time they need it (immediately at any time, app startup time, server startup time).

X pays a very heavy price in terms of complexity to be able to support changing the window manager on the fly (or rather, plugging in different window managers, without providing a turing complete extension language in the server). And it's not because they necessarily badly wanted you to be able to change window managers at any time you felt like it without restarting the server (which was nice, but not something users were clamoring for), but it was because they just didn't want to dictate any "policy" about how window managers should work.

And why just the window manager, and not switch the entire user interface toolkit -- you still want to do that don't you? I'd rather have an architecture where all applications share the same user interface toolkit that runs in one address space local to the server, and have a consistent and customizable user interface, which is how NeWS worked. That's much more important to me than being able to change the user interface on the fly, in my opinion. And it has other nice side-effects like it does not suffer from network race conditions or even context switching overhead, and all the ui code lives in one place and is not duplicated, which mattered a lot in the days before SunOS supported shared libraries -- Sun actually linked all the common SunView apps together into one gigantic monolithic app that would behave like a different app depending on the name it was invoked with on the command line, so the SunView user interface libraries were shared in memory and started up faster, by virtue of the fact that all the standard SunView apps WERE the same app (SunOS did at least support multiple instances of the same app sharing read-only code).