Hacker News new | ask | show | jobs
by astine 4757 days ago
I was sold on Wayland in terms of technology a while ago. Where Wayland is losing people is when is it going to be ready to use? Sure, you can install Wayland now, but there are no applications that target it. Yes, XWayland is meant to solve this problem. But, XWayland is not ready yet (or is it?) and Wayland is still "just around the corner." That may be for legitimate reasons, but it's what the article really should address.
4 comments

According to https://live.gnome.org/Wayland Gnome 3.12 will be fully ported to Wayland at Spring 2014. Hopefully others will pick up soon as well.

I am not sure if "smaller" window managers such as XMonad would benefit but hearing about XMonad being ported to Wayland would be cool.

Sure, but I assume this would mean Haskell bindings for Wayland first, which as far as I know don't exist yet.
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.

http://donhopkins.com/home/movies/TabWindowDemo.mov

I do like the idea of NeWS, but,

Then you aren't fucked by synchronization issues.

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.

Can't one produce effectively the same setup as X11 with a compositor that has a plugin system dedicated to surface positioning?
"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 ;).
Realistically I would expect people to reuse as much Weston code as they can.
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.

The cynic in me wonders if at that point there'll be any users still using vanilla Gnome in order to be affected by the switch...
Raspberry Pi seem to be aiming to switch in the coming months:

http://www.raspberrypi.org/archives/4053

See http://trac.enlightenment.org/e/wiki/Wayland and the linked info on building a version of EFL that uses Wayland.