Wayland Continues To Excite Linux Users

[uid313]

Hmm, isn't the old Win32 API what we'd call a "full GUI framework" (among other things)?

You can create GUIs with raw Win32 API calls, but nobody does because it is very low-level and very cumbersome to do.
So people used to use stuff like MFC (Microsoft Foundation Classes), and other libraries. But now they use Windows Forms in the .NET framework.

[renox]

Of course, it's a research project, not a polished product from the Apple marketing brigade. The engineers there are more interested in the foundations than the bling.

Yes but what I was pointing out is that one of the reason for Wayland's creation is that X isn't well suited to "the bling" (smooth animations, resizing, etc), and rio doesn't have any bling so the question is: does-rio support well the bling?
If no, then comparing Wayland and rio makes no sense.

Wayland looks pretty ugly too at the moment, but once all the bling is ported on it, it will look very different.

Uh? Wayland's support is incomplete but once done, it'll look mostly the same as current application, the only added "bling" that Wayland will provide are smoother animation and resizing and the possibility to interact with "transformed"(rotated, etc) windows.

[pingufunkybeat]

Novel yes, but from screenshot I remember that it looked ugly

Of course, it's a research project, not a polished product from the Apple marketing brigade. The engineers there are more interested in the foundations than the bling.

Wayland looks pretty ugly too at the moment, but once all the bling is ported on it, it will look very different.

[renox]

It seems Plan 9 from Bell Labs have a pretty novel display system, rio.

Novel yes, but from screenshot I remember that it looked ugly, and one motivation for Wayland is that X is not well adapted to "modern looking GUI", I'm not sure that rio is well suited to this task.

• (cut)rio is network transparent even if it doesn't include any network-aware code.
• Windows are treated as completely editable text.

Wayland can be network transparent too (there has been demo made), what is not know is how well it will work in a WAN, in a LAN it should be ok.
And for your second point, I don't see how you can make GUI animations if you describe Windows as "editable text".

I am not sure client-side decorations is the right approach.
If client-side decorations is the right approach, then maybe toolkits shouldn't be responsible for drawing them, maybe they should all go through something like Xwayland so all tookits are drawn using the same window decorator.

This is a display server issue, not a Wayland issue, client-side decorations were chosen for Weston but KDE developers currently plans to go with server side decorations.
Also note that this is not a new issue a Gnome application to appear well integrated in a KDE desktop (or vice versa) has font, alignment, colors issues, so adding decoration to the list is just one more item to the list.

[jessioward]

The X to Wayland transition, we have one try to get it right.

[Pseus]

It's a little-known fact (amongst Linux users, anyway) that Windows has no standard widely-used full GUI framework, and yet it has consistent client-side window decorations. It achieves this by providing a very thin, light-weight control library (which you could use as a standard toolkit, albeit only with great difficulty and a lot of hacks) that all the different larger GUI toolkits can make use of (if they want) to gain consistent look-and-feel.

Hmm, isn't the old Win32 API what we'd call a "full GUI framework" (among other things)?

[elanthis]

But what scares me is that the Wayland developers seem not to be familiar with the inner workings of the display systems of Windows, OS X and Plan 9 from Bell Labs.

I think that's true of the graphics stack in general (obviously not all developers have said weakness; we've got a number of very very bright, educated, well-informed people working on Linux graphics... just not enough of them). I'm seeing a lot of repeating of a lot of the same mistakes that Microsoft and Apple fixed several (or more) OS releases ago. Still, they're moving away from the old X setup, which was just straight up terrible for modern rendering techniques and current hardware, and any improvement is better than no improvement.

It seems Plan 9 from Bell Labs have a pretty novel display system, rio.

• Each window runs in its own private namespace.
• It exports a file system interface to running applications. This interface is the same rio receives from the operating system, so rio can run inside a rio window without any special arrangements. Because the interface uses 9P, rio is network transparent even if it doesn't include any network-aware code.
• Windows are treated as completely editable text.

While certainly novel, that doesn't necessarily mean better or useful. The network transparency thing is dead easy if you work like X11 was originally designed to do and don't have today's high-quality high-speed low-latency GPU drivers, for which you need very thin IPC and as much shared memory or direct driver access as possible (without going too far and destabilizing the system or making it insecure, which Mesa/DRI/DRM kinda do). Likewise, all windows as editable text just doesn't make sense with how all modern 2D rendering is done, and must be done in order to make efficient use of hardware (which is not just about speed, but also making your mobile device have a long-lasting battery!).

I am not sure client-side decorations is the right approach.
If client-side decorations is the right approach, then maybe toolkits shouldn't be responsible for drawing them, maybe they should all go through something like Xwayland so all tookits are drawn using the same window decorator.

It's a little-known fact (amongst Linux users, anyway) that Windows has no standard widely-used full GUI framework, and yet it has consistent client-side window decorations. It achieves this by providing a very thin, light-weight control library (which you could use as a standard toolkit, albeit only with great difficulty and a lot of hacks) that all the different larger GUI toolkits can make use of (if they want) to gain consistent look-and-feel. It's worked there since Win95; there's no reason a similar approach can't be done on Linux+Wayland. It probably won't happen, because half the damn toolkits and desktops exist purely out of NIH Syndrome and the hobbyist "it's way more fun to rewrite this all from scratch" mentality, but that's entirely a community problem and not a technical one.

[uid313]

Unsure

The X to Wayland transition, we have one try to get it right.
Wayland must not fail, else we will be stuck with X.

The good thing about Wayland is that many of the authors are X developers so they hopefully should be intimately familiar with X and know the good and bad about X and use that knowledge to design Wayland good.

But what scares me is that the Wayland developers seem not to be familiar with the inner workings of the display systems of Windows, OS X and Plan 9 from Bell Labs.

I just hope they don't design it in a suboptimal way.

It seems Plan 9 from Bell Labs have a pretty novel display system, rio.

• Each window runs in its own private namespace.
• It exports a file system interface to running applications. This interface is the same rio receives from the operating system, so rio can run inside a rio window without any special arrangements. Because the interface uses 9P, rio is network transparent even if it doesn't include any network-aware code.
• Windows are treated as completely editable text.

I am not sure client-side decorations is the right approach.
If client-side decorations is the right approach, then maybe toolkits shouldn't be responsible for drawing them, maybe they should all go through something like Xwayland so all tookits are drawn using the same window decorator.

[pingufunkybeat]

When is Wayland going to be ready as a daily-driver for machines?

Depends on what you expect and what you're willing to put up with.

Early adopters will probably be able to put together something resembling a modern desktop end of next year or in early 2014.

For regular users who don't care what's under the bonnet, and who want an experience as good, or better, than they have with X right now, probably quite a bit longer than that.

Keep in mind, for example, that all of KDE first has to be ported to Qt5. Qt4 does not work on Wayland, and that's what KDE uses right now. Same goes for popular programs like Scribus, vlc, etc. Window managers will take longer than most stuff, because they are so heavily based on X. Same goes for GTK apps, where Wayland support is still experimental and in the master branch. I expect people will have to port to GTK3 to work on Wayland.

There's lots of work remaining, but it could be really nice once all that is through.

[89c51]

When is Wayland going to be ready as a daily-driver for machines?

When the DEs are ready. Plus we need some "really important" apps to work natively.