News for hackers. Stuff that matters.
Re:XWayland in XOrg by mjg59 on Sunday April 06, 2014 @02:32PM (#7542007)
The basic idea is that most applications using popular toolkits (GTK and Qt) should work with very little modification - in a lot of cases it should just be a matter of an environment variable being set to tell the toolkit to use Wayland support code instead of X. The application itself shouldn't even need to be recompiled.

That covers most cases, but there are others. Some toolkits won't be ported immediately. Some applications use functionality that's tied to X even if they use a toolkit that supports Wayland. The compatibility solution is XWayland. This is a simple X server that can be launched on demand, allocates a Wayland buffer per X window and then renders into that buffer (this is similar to how XQuartz works on OS X, except with more on-demand activation).

So, other than bugs, things should be pretty transparent. There'll probably be some slight awkwardness in cross-X/Wayland interactions (clipboard semantics may not be identical, drag and drop behaviour may vary, that kind of thing) but nothing that most people will notice.

Mir ought to be in the same state, but right now XMir doesn't support the same kind of rootless behaviour as XWayland - instead, X applications all run inside one separate window. I'd expect that to be fixed before Mir is used as the default environment anywhere. Mir is also lagging behind Wayland in terms of getting upstream toolkit support - again I'd expect this to be something that's sorted out in future.

There are no comments on this comment yet.