I will consider a display server, if ports to at least two other operating systems have been demonstrated. I won't use a windowing system, which only works exclusively on Linux. What these "desktop environment" guys are doing on their playgrounds doesn't interest me, it's irrelevant for the IT industry anyway.

The main issue will be for the users that use one of the zillion available WMs (or, in a certain extent, the Gnome 2.x/KDE 3.x heirs). They won't work with Wayland, which requires to write a composer to talk to it (it goes without saying that it's far more complex than writing a WM). Plus, whereas X, Wayland does not draw, which also means you will have to bind to a toolkit to create taskbars, window decorations, menus and so.

To simplify things, it is question to implements them as plugins for the existing composers (Weston/Kwin). But all is still to do.

Wayland also does less things than X, which may mean the bugs will just be highter in the "graphic stack" (it's saner, but does not imply the global solution will be more stable). Plus, it does not currently run in the wide wild world, where crazy things that were not meant to happen tend to find imperious reasons to finally happen.

So, I don't claim here Wayland will fail nor that the raised problems won't find some elegant solutions, but it's IMHO too soon to discuss the opportunity of a switch.

For my first statement, I can only apologize and say that it was a knee-jerk reaction. I unreservedly withdraw said statement.

As for my second statement, I will do more research.

I assume applications built on XLib will not work in Wayland. That will be an obstacle for adoption. And people are very addicted to their window managers.

Still, Høgsberg sounds like a Norwegian or Dane, and it's well known that all things Scandinavian are good (except for surströmming and C++), so it's at least very likely that Wayland is vastly superior to X.

Vølund is also Norse for Wayland, and although I don't know how Wayland MA got its name, it's definitely etymologically related. From Völundskvädet:

Sounds promising. I see Debian Wheezy already has it. At the moment I don't see a reason to replace X though.

Not me. When I think of Wayland I remember getting lost buzzing around between Bedford and Framington searching in vain for a route that wasn't completely traffic clogged (Thoreau must be turning over in his grave) trying to visit an ex-gf. Bad associations all around.

Aside from that, by the time it's viable I'm hoping I've finally figured out how to get OpenBSD working on this laptop. Nothing against Slackware -- it's nice too -- but that's my home O/S, and I'll eventually return to it. I don't see OpenBSD ever supporting Wayland, particularly since one of their developers is a senior X person, on the board if I recall.

Actually, that's a good reason that OpenBSD WILL *eventually* support Wayland. Wayland is being devloped by many of the same x.org developers. As discussed earlier in the thread, the developers of x.org don't see a way to fix various security issues because of how x.org is designed, so they're designing wayland as a replacement for x.org.

Well, perhaps I should not speculate. I don't know what Matthieu Herrb's mind is, exactly, on the issue. There is this paraphrase of a small portion of his Feb 2013 fosdem talk that makes it sound like it may be a long time coming (or longer, as in infinite?) and that perhaps it's a headache for him and the very few others that do X server work in OpenBSD (anyone, anyone... Bueller?):
"Wayland will also be a mess for BSD and Solaris operating systems due to its dependence on kernel mode-setting, kernel input drivers, and Weston being designed with solely Linux in mind. " http://www.phoronix.com/scan.php?pag...tem&px=MTI5Njk

They will work with XWayland, but indeed, a better way would be to write a native plugin with the same functionality.
Again: XWayland.
It is planned as an option in Fedora 20 and as default in Fedora 21. Several phones are planned with it, using Sailfish and Tizen as OS, for example the Jolla phone. So having it running in the wild is coming in the near future.Kernel mode-setting is coming at least to the BSDs.
Sorry, don't know about that.Irrelevant. Weston is only the reference implementation of a Wayland compositor and not meant to be actually used (although it is possible).

Wayland needs to prove itself before it should be used.

I'd suggest offering it as a /testing package ONLY. After the code has been stabilized for at least a 6-12 months time frame following the initial release date for adequate testing. This way the developers have worked out the bugs, security issues, etc.

I don't see Wayland taking over for X.Org for some time until all the UNICES out there can get a full port of Wayland created and stabilized. With Weston being possibly Linux only, chances are X.Org could be still co-developed alongside Wayland until Weston gets a successful port, clone, or ability to be commented out in favor of a BSD friendly compositor that is Wayland friendly, which remains to be seen.

They won't. X applications like xterm will work, because each will run in its own Xserver where it will fit the root window. It's explained there (§VI).

A WM is an application which filters the events between the X server and the root window's children (which means all the windows the different applications create in the same X session). So, the only thing you can expect with XWayland is an Xserver running a WM with nothing to manage. The window management in Wayland can't be anything but a component of a compositor.

There are currently 2 major components in active development that is changing the whole DE's.
Wayland in combination with systemd is very powerfull for the desktop experience, and would bring linux desktops closer to apple and microsoft desktops in the way of user experience.

Both these components are still in their child shoes (wayland being more mature imo)
Both these components are developed with different parts of the system.
Kernel additions, glibc changes, dbus changes, probably alot more.

When it comes to BSD, they are just saying it doesn't work on BSD.
Instead they should be working with wayland to make this work.
Also systemd is here an option, as they have their own kernel the can work with the devs of systemd to make this work.

PS. I see systemd having only benefits in a desktop enviremont at the moment.
wayland can be used also as a remote desktop server. (No more seperate VT's for each user)

Hey, I didn't choose Slackware to have the worse Apple and Microsoft "user experience".

Does wayland need to be everywhere? At least on OpenBSD mailing lists, I've never seen any sign of anyone with plans to work on wayland support. The people doing real work there already have long TODO lists, I suspect. If the toolkits support both Wayland and X11, is there a need for BSD application porters to care about what's going on in the GNU/Linux display server world?

Well said. Whenever someone says something about wanting the M$ or OS-X gui experience, I have no idea what they are wanting, unless it is (useless to my needs) eye candy.

I second this sentiment, and then some. Every time I've had to touch a windows machine at work, or my wife's Macbook at home, it really impresses upon me that X11-based UI is more sophisticated, and more powerful.

Compare and contrast copy-and-pasting text segments from an almost-screen-sized window to another window:

Under Windows or MacOSX, the source window's text is not always selectable (also true under X11, but less frequently), the destination window is not always capable of taking the paste, the destination window has to be brought to the foreground for the paste to happen, and sent back to the background to make the source window entirely visible again, and highlighting text is insufficient to actually copy the text (a control-key sequence is necessary, or clicking on a menu).

Under X11, the destination window remains behind the source window, and it's just left-button to copy + middle-button to paste. zip zip zip, all done.

I know there are WM's which emulate the click-to-focus behavior of Windows and MacOSX, but these are broken. Do not use them.