I'd like to see some code to understand what it takes to write a functioning Wayland application, a bit like David Rosenthal did in his paper "A Simple X11 Client Program -or- How hard can it really be to write ‘Hello, World’?" (USENIX 1988 Winter Proceedings).
Anyway, if I was persuaded that Wayland has a rather backwards design (here my reasons: https://news.ycombinator.com/item?id=47477083), now I have the confirmation that its philosophy is something like "put surfaces on the screen and distribute events to the clients, all the other stuff is not my business", and that exploring alternative approaches to window management is still worth it.
Having applications that manage all their resources (canvases, events, decorations) is not bad per se (for example video games), but not all of them need to.
So far this is one of the most interesting approaches to Wayland compositor implementation.
I always felt that the "monolithic design" (compositor + window manager) is a step backwards, and that many compositors neglected features like server side decorations (which make easier to have a consistent look & feel).
The NeWS book at page 35 has a picture explaining the structure of the CMU Andrew Window System: the window manager on top of the "base window system" (assuming protocol and logic), which sat on the graphic library, and applications connected to it through sockets.
A limit was that the window manager was fixed, so you couldn't change its policy/look and feel without having the sources and recompiling it (and here I wish the source code was available).
Wayland it's kinda similar, but most of the graphic layer is moved from the server into each application (where each one use its own).
Unless you have a compositor that is designed to be extensible out of the box, a set of widgets will be needed if you don't ship a desktop environment, and each one is a separate system process (for example: toolbar, clipboard manager, status bar, wallpaper).
Another limitation is its "static" protocol, in the sense that you cannot extend the compositor at runtime loading extensions (you have the XML which is used to generate the stubs for the implementation in the compositor AFAIK). This can prevent applications that use them to run on compositors that don't implement them.
On the other hand, systems like NeWS, GMW (a window system from Kyoto University, ASTEC and Omron) and the one described by Rob Pike in "A concurrent window system" are interesting for these reasons:
- runtime extension loading code: new functionalities to the server can be added when needed
- code as a protocol: instead of sending "raw data" and requests, equivalent pieces of code are sent, allowing for compression and to offload a portion of the logic to the server (or even have applications that run inside the server). This can also allow to have applications that run on remote machines, which download the code for the interface to the server.
- concurrency: their programming model is structured around "lightweight processes" (or equivalent), which allow to decompose the interaction in independent tasks, which can eventually interact by sending messages/events or sharing resources.
I think it's worth re-investigating this kind of design, considering also the technological advancement (like the evolution of graphic hardware, multicore CPUs, touchscreens, ecc) and challenges (including security).
It would be interesting something like NeWS but a bit more abstract and capable of supporting whatever graphic model you wish.
These are some screenshots of NeWS 1.1 running on SunOS 4.1.4 on QEMU that I took time ago.
Unfortunately QEMU SPARC decided to break again. Also, keyboard doesn't work yet (forcing me to use the SunView terminal emulator), but probably it's due to the keyboard script.
In any case, SunOS 4.1.4 comes with OpenWindows out of the box.
> Does it build today
In this form it won't, since that is missing the Sun PixRect library. And you also need the "operators.h"
file (which is in another directory...) and the "acceptconnect" function.
On comp.windows.news Usenet group and on the NeWS book is reported that a portable codebase (called REF) exists, and Sun ported it on Ultrix (on thr VAXstation) and System V. I read it included a version of PixRect called "Generic PixRect", which should be more portable.
BitSavers put on the net a tape dump of X/NeWS 2.0, and there are some differences: a different graphics library called SHAPES replacing CScript (and it needs the Ace preprocessor to build the device dependent portion of the library), a different memory allocator, support for X11 protocol, support for Folio F3 fonts, and other things.
Fortunately I found a copy of PixRect in the leaked sources of SunOS 4.1.4 , but it's not enough, since that device dependent routines must be rewritten.
I'm slowly porting NeWS 1.1 to NetBSD (since that wscons is easier to work with) as a proof of concept. I managed to execute code and grt my screen turn blue, but the current obstacle is decoding binary fonts: the OG routines fail completely on 64 bit machines, since that the original format assumes 32 bit machine words and big endian order. More work will be needed.
Weeks ago, while I was searching for NeWS related papers/material, I stumbled upon some japanese papers about a window system called GMW (Give More Windows).
It is pretty much obscure, and all I found is that was made at Kyoto University (who also made Kyoto Common LISP), and it used a virtual machine.
NeWS wasn't based on DPS. It's a full display server based on the PostScript Red Book with some extensions (canvases, lightweight processes and sync primitives, events, classes, garbage collection). This allows to write applications in this extended PostScript or in other programming languages, using a preprocessor, such as cps for C or lps for Scheme-48 and Allegro LISP, that generates PS snippets that get sent to the server.
Yes, it comes in bundle with SunOS, since that one part of it it's implemented in the kernel IIRC.
I've also been able to run NeWS 1.1 (which was before the X/NeWS merg) inside QEMU, although the keyboard input is not working (and for some reason the patch to add the Sun Type 4 breaks everything).
Anyway, if I was persuaded that Wayland has a rather backwards design (here my reasons: https://news.ycombinator.com/item?id=47477083), now I have the confirmation that its philosophy is something like "put surfaces on the screen and distribute events to the clients, all the other stuff is not my business", and that exploring alternative approaches to window management is still worth it. Having applications that manage all their resources (canvases, events, decorations) is not bad per se (for example video games), but not all of them need to.
reply