Wayland Clients Within A Normal X11 Window Manager

[phoronix]

Phoronix: Wayland Clients Within A Normal X11 Window Manager

Martin Gräßlin, the lead developer of KDE's KWin compositing window manager, has yet another interesting blog post that's worth reading. The blog post details a "rather historic event" for KDE, X11, and Wayland...

http://www.phoronix.com/vr.php?view=OTU0OA

[89c51]

we had X running in Wayland and now we have Wayland running on X

Exactly what we needed

[dnebdal]

we had X running in Wayland and now we have Wayland running on X

Exactly what we needed

Perhaps surprisingly, I think it is.

X on Wayland: Necessary if Wayland is to become the main server at some point, since there will be a huge amount of X apps around for a long time.
Wayland on X: Useful if you're using (or writing) a Wayland app but otherwise have a normal X desktop. Also nice if you're using something with better driver support for X than Wayland, I guess.

In the long term, it means that you can go X → X with Wayland apps → Wayland with X apps → Wayland , for a very gentle transition.

[89c51]

Perhaps surprisingly, I think it is.

X on Wayland: Necessary if Wayland is to become the main server at some point, since there will be a huge amount of X apps around for a long time.
Wayland on X: Useful if you're using (or writing) a Wayland app but otherwise have a normal X desktop. Also nice if you're using something with better driver support for X than Wayland, I guess.

In the long term, it means that you can go X → X with Wayland apps → Wayland with X apps → Wayland , for a very gentle transition.

First you must understand that there are NO wayland apps. Apps are written in toolkits (gtk qt etc) which most of them have backends for wayland. This means you just have to recompile some stuff and they will work. (there are screenshots floating around of gtk and qt apps). Those few apps that use "pure" X parts can still be displayed with X on wayland.

There are ways now to run wayland in an X environment for testing purposes. Not the way that Martin did but you can.

As for drivers you can use the open stack and it works.

There are many things missing in wayland but this is not the most usefull thing in the world

[dnebdal]

First you must understand that there are NO wayland apps. Apps are written in toolkits (gtk qt etc) which most of them have backends for wayland. This means you just have to recompile some stuff and they will work. (there are screenshots floating around of gtk and qt apps). Those few apps that use "pure" X parts can still be displayed with X on wayland.

There are ways now to run wayland in an X environment for testing purposes. Not the way that Martin did but you can.

As for drivers you can use the open stack and it works.

There are many things missing in wayland but this is not the most useful thing in the world

At some point we might (should?) get to a state where some things prefer, or only officially support, their Wayland backend. Apps using that backend are then effectively Wayland apps, wouldn't you agree?
While getting there, it'll certainly be interesting to test the Wayland backend to see if your program still looks fine - because you never know when odd bugs sneak in. Again, you'll effectively be running a Wayland app in an X setting - unless you start a pure Wayland environment to test it, ofc.


As for drivers, the open stack is not always the best alternative ... and even when it is, Wayland support isn't always around. I'm on FreeBSD, which has quite decent X support - but as of today, there's no Wayland port. Being able to test Wayland clients easily won't hurt.

And, hell ... what's so wrong with this? Handling it in the kwin compositor seems very sensible.

[yesterday]

At some point we might (should?) get to a state where some things prefer, or only officially support, their Wayland backend. Apps using that backend are then effectively Wayland apps, wouldn't you agree?
While getting there, it'll certainly be interesting to test the Wayland backend to see if your program still looks fine - because you never know when odd bugs sneak in. Again, you'll effectively be running a Wayland app in an X setting - unless you start a pure Wayland environment to test it, ofc.

I think the point is that applications don't write against the display server, they write against the toolkit. Apps don't have an X or Wayland backend, they use whatever the toolkit library has been built to use. Maybe games and other 3D apps might actually directly call X functions, but I'm guessing most of them actually utilise and enigine or layer that handles that for them.

[srg_13]

First you must understand that there are NO wayland apps. Apps are written in toolkits (gtk qt etc) which most of them have backends for wayland. This means you just have to recompile some stuff and they will work. (there are screenshots floating around of gtk and qt apps).

I can't speak for Qt apps, but with GTK's pluggable backend support in 3.0, you will be able to switch and app from X to Wayland by closing it and then opening it with a different command line switch (as soon as the Wayland backend goes into a GTK release)

[yesterday]

I can't speak for Qt apps, but with GTK's pluggable backend support in 3.0, you will be able to switch and app from X to Wayland by closing it and then opening it with a different command line switch (as soon as the Wayland backend goes into a GTK release)

yeah, once again that's a feature of the toolkit, not the app. The app isn't written to run against X or Wayland, it is written against GTK, and you can pass parameters that ANY GTK app will accept.

Qt apps have the same thing. For example, you can pass in the render method (OpenGL, Xrender). Any app built with Qt automatically get's this functionality