In Wayland architecture, the window manager is the display server. To provide wayland-XMonad, you don't need Haskell bindings, you need an implementation of the protocol in Haskell.
This isn't as horrible as it sounds, because unlike X, the display server in Wayland is pretty tiny. The current implementation is like ~10k lines. I expect it to fit in sub 3k lines of Haskell. :)
And this is my primary issue with Wayland. I cannot fathom why anyone would think it's a sound design decision to bundle a hardware-independent component (the window manager) with a hardware-dependent component (the compositor).
This hearkens back to the days of DOS video games – what fun it was to implement support for everyone's sound card! Instead now we'll get to support KMS, Quartz, whatever-the-heck *BSD uses, etc.
Just put a JavaScript (or whatever) interpreter in the window server, and program the window manager locally in that. Then you aren't fucked by synchronization issues. James Gosling did something like that with PostScript many years ago, an alternative to X11, which was then merged with X11, and it was called NeWS (and later X11/NeWS or OpenWindows): http://en.wikipedia.org/wiki/NeWS
I've written several window managers / user interface toolkits / tabbed window frames / menu system in PostScript for NeWS. We even wrote an X11 window manager in PostScript, complete with rooms, scrolling virtual desktop, tabbed windows, pie menus, and seamless integration of X11 and NeWS windows.
I don't know what you mean by this. The EWMH specifies policy for using the Sync extension to synchronize updates between the window manager and the clients.
It's much harder (and less efficient) to synchronize code running in two different address spaces, communicating via an asynchronous protocol.
NeWS had "synchronous event handlers" that when triggered would block the distribution of all other events (i.e. taking them off of the global event queue, figuring out their target, and putting them on a local event queue), until the synchronous event was handled (typically very quickly by code running in the window server, without any context switches -- but potentially it could send synchronos events to asynchronous network clients and continue to block the distribution of events until the client replied, which is what X11 window managers have to do all the time).
So if a mouse click would remove a window from the screen, the following keyboard events would not get distributed (to the wrong window, and lost) until after the window was removed.
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.
X11 has always suffered from flakey keyboard input focus tracking, just for this very reason. Of course now that computers are 1.0e+6 times faster than they were when it was developed, it's not as noticeable, and people have been trained (browbeaten) to let things "settle down" before expecting their keyboard events to go to the right window.
But believe me, on a 4 meg diskless Sun 3/50 running X11, Emacs and a C compiler, with expensive context switching and paging over the network, it took a very perceptible (in fact terribly dreadful) amount of time for events to be delivered when you clicked, typed, and moved windows around, and it was a big issue.
Strict guarantees on synchronous event distribution are necessary to implement reliable "mouse ahead", for gestural user interfaces like pie menus, and reliable window management and keyboard input focus tracking.
Having the window manager running as an outboard process, communicating via an asynchronous protocol, is a terrible idea, but is baked into X11 at a very low level -- with the ICCCM thrown in as a kludgy afterthought. The X11 protocol has hacks and band-aids like "mouse button grabs" and "server grabs" to mitigate the problems, but they cause a lot of other problems, complexity and inefficiencies on their own.
Like the view system in most GUIs, NeWS included the concept of a tree of embedded views along which events were passed. For instance, a mouse click would generate an event that would be passed to the object directly under the mouse pointer, say a button. If this object did not respond to the event, the object "under" the button would then receive the message, and so on. NeWS included a complete model for these events, including timers and other automatic events, input queues for devices such as mice and keyboards, and other functionality required for full interaction. The input handling system was designed to provide strong event synchronization guarantees that were not possible with asynchronous protocols like X.
[sugar] Re: Zoomable tracking protocol for non-windowed Cairo based objects.
The ScriptX tracking service was based on The NeWS Toolkit 2.0's tracking service (written in PostScript), which I adapted for ScriptX. Credit for the design goes to Don Woods, Owen Densmore, Brian Raymor, and other people on the NeWS team, whose goal was to redesign the old NeWS tracking service and toolkit to be smaller and faster.
TNT 2.0 tried to minimize the number of objects, inter-object sends, event manager threads, coordinate transformations, share event interests (patterns to receive events), and centralize event processing in the global event manager.
It also had "safe" input handling, because NeWS threads (like the global event manager) could use synchronous event handlers (when appropriate, but not always), which were guaranteed to block the input queue and run the event handler before any more events were delivered. Synchronous event handlers enabled the window manager to perfectly track and synchronize mouse clicks, input focus and key distribution changes, without losing any events that slip between the cracks from changes in the window hierarchy, event handler registrations, and delays due to paging and network response. Safe input handling is especially important for slow networked computers (like a diskless Sun 3/50 or an OLPC) that need to respond quickly and reliably to user input!
Here is James Gosling's original paper about what was eventually called NeWS: SunDew - A Distributed and Extensible Window System, from Methodology of Window Management (extremely interesting and required reading for anyone interested in window management and the history of user interface management system architecture): http://www.chilton-computing.org.uk/inf/literature/books/wm/...
This idea has very powerful implications within the context of window systems: it provides a graceful way to make the system much more flexible, and it provides some interesting solutions to performance and synchronization problems. SunDew contains a complete implementation of PostScript. The messages that client programs send to SunDew are really PostScript programs. [...]
5.3.3 User Interaction - Input
The key word in the design of the user interaction facilities is flexibility. Almost anything done by the window system preempts a decision about user interaction that a client might want to decide differently. The window system therefore defines almost nothing concrete. It is just a loose collection of facilities bound together by the extension mechanism.
Each possible input action is an event. Events are a general notion that includes buttons going up and down (where buttons can be on keyboards, mice, tablets, or whatever else) and locator motion.
Events are distinguished by where they occur, what happened, and to what. The objects spoken about here are physical, they are the things that a person can manipulate. An example of an event is the E key going down while window 3 is current. This might trigger the transmission of the ASCII code for E to the process that created the window. These bindings between events and actions are very loose, they are easy to change.
The actions to be executed when an event occurs can be specified in a general way, via PostScript. The triggering of an action by the striking of the E key in the previous example invokes a PostScript routine which is responsible for deciding what to do with it. It can do something as simple as sending it in a message to a Unix process, or as complicated as inserting it into a locally maintained document. PostScript procedures control much more than just the interpretation of keystrokes: they can be involved in cursor tracking, constructing the borders around windows, doing window layout, and implementing menus.
Synchronization of input events: we believe that it is necessary to synchronize input events within a user process, and to a certain extent across user processes. For example, the user ought to be able to invoke an operation that causes a window on top to disappear, then begin typing, and be confident about the identity of the recipient of the keystrokes. By having a centralized arbitration point, many of these problems disappear. [...]
Hopgood [Bob Hopgood, Rutherford Appleton Laboratory]:
How do you handle input?
Gosling [James Gosling, CMU (Andrew, X10), Sun (SunDew/NeWS, Java)]:
Input is also handled completely within PostScript. There are data objects which can provide you with connections to the input devices and what comes along are streams of events and these events can be sent to PostScript processes. A PostScript process can register its interest in an event and specify which canvas (a data object on which a client can draw) and what the region within the canvas is (and that region is specified by a path which is one of these arbitrarily curve-bounded regions) so you can grab events that just cover one circle, for example. In the registration of interest is the event that you are interested in and also a magic tag which is passed in and not interpreted by PostScript, but can be used by the application that handles the event. So you can have processes all over the place handling input events for different windows. There are strong synchronization guarantees for the delivery of events even among multiple processes. There is nothing at all specified about what the protocol is that the client program sees. The idea being that these PostScript processes are responsible for providing whatever the application wants to see. So one set of protocol conversion procedures that you can provide are ones that simply emulate the keyboard and all you will ever get is keyboard events and you will never see the mouse. Quite often mouse events can be handled within PostScript processes for things like moving a window. [...]
Teitelman [Warren Teitelman, Xerox PARC (Smalltalk, DLisp (Interlisp), Interlisp-D, Tajo (Mesa Development Environment), Docs (Cedar), Viewers), Sun (SunView, SunDew/NeWS)]:
The innovation here is not that we are using PostScript. The reason we chose PostScript is due to a lot of historical connections and proximity to the people who are doing it.
The interesting thing is that all these processes look as though they are executing in one of those old single address environments. It is a single user process that James has been able to implement lightweight processes in. You don't have lightweight processes in Unix systems, which you really need to implement realistic user interfaces.
Gosling:
There is really nothing new here. It's just putting it together in a different way.
Rosenthal [David S. H. Rosenthal, CMU (Andrew, X10), Sun (one of the architects of NeWS, and developers of X10 and X11, who wrote the ICCCM)]:
It is worth bringing out a number of points about this style of window manager. There are some real limitations, though I think this is the way we should go.
Some help from the kernel is needed. This is easy in 4.2 which has a sensible IPC. It could be done in System V through shared resources etc.
A reliable signal mechanism is essential. The window manager has to stay up. It is the only routine for talking to the system and hence must stay alive. We have 100 systems running and only experience 1 - 2 crashes per week. This is good by Unix standards!
Applications cannot read pixels back - this is just too slow.
There must be a way to make the client think it has a real terminal, such as the 4.2BSD PTY device, otherwise all old programs misbehave.
There must be a mechanism for downloading application code into the window manager process, for example, rubber band line mouse tracking is done by a user level process.
There must be off-screen space in the window manager.
Examples of systems built in this way are:
BLIT [50];
Andrew (CMU)(see Chapter 13);
VGTS (Stanford) [36];
X (MIT).
The BLIT system is successful - people wrote programs for it. I believe it is the only successful window manager for a Unix system.
Myers [Brad Myers, University of Toronto (Peridot), CMU (Garnet, Amulet)]:
Maybe that is because BLIT doesn't run a Unix operating system.
Rosenthal:
Overall, it is a Unix software environment.
Williams [Tony Williams, Rutherford Appleton Laboratory]:
We should bear in mind that Rob Pike says that to do anything sensible using the BLIT, you need to write two processes which communicate: one running in the Unix host and one running in the BUT, and this must be harder to do than, say, writing two programs which don't communicate.
> 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.
"Surface positioning" -- especially when you want a USER INTERFACE to let human beings position the "surfaces" instead of automatically positioning them algorithmically -- is an extremely complex, open-ended problem that's too general to write a "plug-in" interface to cover. The best you can do is to "plug in" an extension language like JavaScript (or PostScript ;).
The only part that's big enough and self-contained enough to be worth reusing in a Haskell project would probably be the cursor handling. For all the rest, writing the wrappers necessary to deal with them from Haskell would probably be a bigger job than just re-implementing.
The whole point of Wayland/Weston is that the display server is miniscule. All the complex parts are reimplemented in other parts of the stack already, so just let them deal with them and hand over pointers. It's so small that if there ever is a Haskell version of it, I expect it to be formally proven to be bug-free.
