Wayland

http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.h
http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-server.h
http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-egl.h

That's it. Those three tiny header files is all you need to be able to host or interface with a Wayland server, create and manipulate windows, get input device events, or get an EGL context for use with OpenGL or OpenGL ES (your choice). There are no configuration files (everything is autodetected and/or delegated to the kernel, enumerating display adapters, adapter outputs, input devices, etc. is done by traversing the mounted devfs file system tree).

You can use this as your starting point to implement a full blown DWM or X Windows layer, or you can use it write client applications that integrate nicely with any active Wayland server including Wayland-based DWM.

Why are you still using X Windows?

I WANT TO BELIEVE

Drivers.

>>3
``Build it and they will come.''

In addition to Ubuntu, RedHat has announced that Fedora will move towards the Wayland stack over the next few releases.

http://www.jonboy60.com/2010/12/12/fedora-to-eventually-move-to-wayland-too/

Wow not heard about this before. Thank fuck. I look forward to the day this becomes standard and X dies forever.

Why are you still using X Windows?
Because some of the over-engineered features from X are ones I use every day.

X's arch isn't bad because people were lazy or stupid, it's "bad" (i.e. slow) because it was required to support features your windows-fed ubanto brain can't comprehend.

X's interface does suck pretty hard though. No argument there.

Don't kids these days comment their header files?
Anyway, is Wayland still at the ``lol, let's have the GUI toolkits draw their own window decoration'' stage, or did someone actually test that so they could see what a massively retarded idea that is?

>>7
What makes you think that's a bad idea?

>>6
X's arch isn't bad because people were lazy or stupid, it's "bad" (i.e. slow) because it was required to support features your windows-fed ubanto brain can't comprehend.
That isn't even true. The official nVidia drivers patches various function tables such that you don't have to pay the performance price of features you don't use.

>>9
You're still stuck with poor performance. I don't think it's as effective as they make it out to be. OTOH I don't care, everything I do is realtime-responsive, and more importantly: implemented.

>>8
• It relies on the cooperation of the authors of every app running on your desktop to get an even remotely consistent interface. We've seen how well this works with UI widgets, now we're taking the fun to the windows! Is the close button on the left or right side? Top or bottom?

• Now every program has to link to a GUI toolkit, even games and the likes which would be happy to just get the default window decoration.

• The window manager can no longer force window resizing and closing to work for programs that stop responding to messages.

• It clashes with the current system, which is sure to make it harder to write something that works with both. Expect plenty of problems with missing decorations on one side and double decorations on the other.

I can't fathom why anyone would even think it would be a good idea.
``This function needs to be reliable, consistent, and heavily user customizable.  I know, let's let every developer implement their own!''
Maybe someone who has their head so far up KDE or Gnome's ass that they think everybody should just rewrite their programs in Qt/GTK.
Hearing Wayland supporters talk about how everyone will just use libraries and that will solve everything is like hearing libertarians talk about the Invisible Hand of the Free Market.

>>6
ubanto

sweet lord this guy literally shits autism

>>11
It relies on the cooperation of the authors of every app running on your desktop to get an even remotely consistent interface.
I'm not concerned there. Many applications provide their own decorations already. It's not like you can stop people from being assholes. This is the one valid concern you have, even if it is already a problem today.

Now every program has to link to a GUI toolkit
The vast majority already do. Games tend to have in-game menus and don't need the toolkit anyway—part of the design of Wayland is to permit windows to exist framelessly. The toolkits don't even work in fullscreen.

The window manager can no longer force window resizing
That has nothing to do with decorations unless maybe you don't have an alt key. My windows have no borders BTW.

and closing to work for programs that stop responding to messages.
Programs can refuse to close as it is.

It clashes with the current system, which is sure to make it harder to write something that works with both.
This is sort of true. X apps are supposed to run in an X-server as a Wayland client. That might sound terrible, but it fits perfectly with X mentality. And it works.

Hearing Wayland supporters talk about how everyone will just use libraries and that will solve everything is like hearing libertarians talk about the Invisible Hand of the Free Market.
It's not though. Those libraries exist and they're not invisible. The challenges are being taken up by real people doing real work.

>>13
Games tend to have in-game menus and don't need the toolkit anyway—part of the design of Wayland is to permit windows to exist framelessly
Games should always offer you the choice between running in fullscreen or a window. When they run windowed, they should of course have the standard window controls.

My windows have no borders BTW.
They will once application developers start hardcoding them in.

That has nothing to do with decorations unless maybe you don't have an alt key.
The vast majority of users resize their windows by dragging the window borders, in ultraclassic WIMP style.

Programs can refuse to close as it is.
Modern window managers will offer to force close the program if it does not respond to the close message. With Wayland the system doesn't even have a clue that you wanted to close it, because that's now the application's job to figure out.

Those libraries exist and they're not invisible.
The libraries may exist but they will not solve the problem. They're taking a problem that is easily solved at the window manager, under the control of the system and the user, and distributing it to all the applications, where it will inevitably become a hodgepodge of slightly different solutions that don't quite work together.
The current GUI toolkit situation, where you have a dozen slightly different buttons, some of which don't respond to themes, isn't exactly ideal, but having the window controls in a dozen different places, each with slightly different behavior, now that is bullshit!

X apps are supposed to run in an X-server as a Wayland client.
Eventually the retards are also going to start writing things directly for Wayland. Now if you make a similar system to run those on X, you'll need to devise some stupid signalling scheme to stop the application from drawing the decorations. Instead of, you know, just not doing that because why the fuck are they even drawing those that's not the job of the appliaoeruaaaaaaaaaaaargh.

Your denials fail to actually highlight a single actual advantage of the system. It's all mitigation at best, or else faith that it will work out somehow.

They will once application developers start hardcoding them in.
Not likely. Apps can hardcode them in now but typically don't. It's reasonable to expect Qt, GTK and the like to behave the same as they do now. The lesser toolkits that treat user styles as an afterthought are going to continue to exhibit a lack of consistency.

The vast majority of users
don't use X windows and won't care if/when the time comes that Wayland replaces it. Hopefully the majority of actual X users don't go about clicking on tiny target areas when they want to resize a window.

The libraries may exist but they will not solve the problem.
They already solve the widget problem. Decorations aren't any different except with respect to whether the server or client handles them. As far as non-standard UIs go, it is a problem that exists today and we've been over it.

Now if you make a similar system to run those on X, you'll need to devise some stupid signalling scheme to stop the application from drawing the decorations
Or just run it on Wayland. You might as well bitch about the problem of running Linux on a 286, Mr Tanenbaum.

Your denials fail to actually highlight a single actual advantage of the system.
I wasn't really going for advantages. I was just curious about potential problems with letting clients render their own decorations (which they can do in X), but that turned out to be a bunch of "the sky is falling"-style BS.

But if you're curious, there is only one real advantage of Wayland and it comes down to speed. The clients are rendering their own decorations for a reason. If you're a colossal pussy and things like confounding specifications give you trouble then there's also an advantage there. A fairly huge one too, but I'm sure you'll never have to talk to X so I wouldn't worry about it.

I am a little worried about Wayland though. It has nothing to do with decorations. For example, I suspect few people use all of X's selections, but I do. There are countless little things like that which are bound to change.

I get the feeling you think I'm some big fan of Wayland and that I have something against X. I know enough about X to hate it, that much is true. Instead of hating it I rather like it because I know why those (apparently) evil decisions were made. There are some big bad warts that could stand to be changed but that's not why Wayland was created. Wayland was created because X's design does not correspond very well to its modern usage.

>>15
>one real advantage of Wayland and it comes down to speed.
ENTERPRISE PROGRAMMING ON THE DESKTOP WINDOW CONTROLS AND GARBAGE COLLECTED VIRTUAL MACHINES INSTEAD OF OPTIMIZED AND MANUALLY MANAGED MEMORY

BRILLIANT

>>15
Oh, I'm not in any way claiming that it's the problem with Wayland, it's just a stupid decision for a lot of small but valid (whatever you might say) reasons.
It annoys me because it's anti-design: they take a solved problem and break it by putting things where they don't belong.

The lesser toolkits that treat user styles as an afterthought are going to continue to exhibit a lack of consistency.
Except now the inconsistency extends to the window handling for no good reason.

letting clients render their own decorations (which they can do in X)
But most don't and really have no motivation or desire to do so. Just about every program just wants their windows to look and behave however the fuck the user is expecting. That's easily solved by having decorations be centrally handled by the window manager.

>>7
Commenting header files slows down the compilation process. External documentation is preferred. It's not like you can read the comments in Java, C#, etc. programs due to the different compilation model anyway, people there consult the external documentation.

>>18
Commenting header files slows down the compilation process.
All those extra milliseconds of parsing. Truly a heinous crime !

>>7,19
Inline documentation comments more or less get in the way for seasoned developers. They're a crutch for novices.

>>19
But parsing is O(n), so we need to cut down on BOC!

I like the network transparency built into X. That being said, Wayland is a good solution to the problem of local display service.

>>22
You can layer network transparency on top in the applications or DWMs that require that. It's not something most things need.

>>23
With Wayland, we could possibly do a modern network transparent alternative protocol to X. If not, I guess we could always run X on top of Wayland.

>>24
We could but we won't. That's another hand-waving exercise the Wayland devs do to gloss over the fact that X solves this problem almost universally (however badly), while Wayland doesn't.
Imagine SSHing into your machine, and not being able to run a program because it doesn't provide explicit support for remoting. That's worse than Windows!