GTK+ Lands Experimental Backend For Mir Display Server

[blackout23]

That's difficult, because GTK2 didn't hide the underlying toolkit very well...

I thought that's the job of GDK in the GTK Toolkit.

[RahulSundaram]

I thought that's the job of GDK in the GTK Toolkit.

GDK started out as a very thin wrapper around xlib and the toolkit itself made some assumptions based on how X works which hasn't translated well into other platforms. GTK3 is much better in that regard in part because of experiences from prior porting efforts and also now because of the work done to support Wayland has resulted in better abstractions.

[scionicspectre]

I'd much rather see GTK2 ported to Wayland. Should not be impossible? The payoff would be immense since there are a metric shit ton of them around. Qt4 aswell. We would hardly need Xwayland anymore.

I can tell you from my previous work with GTK 2, it isn't going to happen. I wrote the initial GTK 2 theme for Adwaita, and I was discussing with several developers whether it would be possible to add an official patch for menubar and toolbar dragging, since it is included in the theme. However, GTK 2 is in maintenance-only mode, so no new features are going to be added, regardless of how polished the implementation is.

So if we aren't adding a 20 line patch for dragging widget backgrounds, we're sure as heck not getting a Wayland patch in. And, if someone wants to maintain a Wayland patch for GTK 2 outside of the main branch like many distros already do for this dragging functionality, good luck, but that's about the most unfeasible concept I can come up with regarding GTK 2.

Also, regarding Qt 4, although there is some initial Wayland support in the later releases, but it certainly won't be sufficient compared to Qt 5. That said, it's so easy to port from Qt 4 to 5 compared to GTK 2 to 3 that, within a year or two, I think the remaining Qt 4 applications will be few and far between. Mainly those that rely on something in the old KDE libs and are no longer maintained. Even in that case, you can still port to Qt 5 in the short term, so it really can't be made much easier than it is.

[Prescience500]

I guess this means we're going to be living with X forever in order for apps to be easily compatible with both XWayland and XMir systems.

[Luke_Wolf]

I guess this means we're going to be living with X forever in order for apps to be easily compatible with both XWayland and XMir systems.

Will people quit it with this meme? Toolkits exist, their job is to abstract away things like the display server. While Kwin and Mutter care about the Wayland protocol as they're implementing it, applications don't, and shouldn't. What applications care about is "does Qt5/GTK3/VCL/XUL/SDL support Wayland?". if so then guess what? it's gonna support Wayland.

Almost all of the major development communities that aren't Canonical on Linux have devoted themselves to Wayland at this point and so pretty much anything that is open source will run on it, in terms of proprietary software assuming a developer isn't doing something stupid there's little reason to expect an X dependency. That said there could be but it's basically up to whatever Valve chooses to do

[TheBlackCat]

Toolkits exist, their job is to abstract away things like the display server.

In theory. In practice, toolkits can't abstract away everything.

[Luke_Wolf]

In theory. In practice, toolkits can't abstract away everything.

Despite what Martin says, if a toolkit is failing to do that, it's a bug with the toolkit and needs to be fixed there rather than with a dozen ugly #ifdefs in your application code.

[Luke_Wolf]

Valve recommends Ubuntu so it looks like they will support Mir.

Valve uses Debian proper which is unlikely to adopt Mir. Realistically speaking, Valve will either:
A). Stick with X, and just hold on that until it decides otherwise <--- Likely
B). Switch to Wayland <--- Likely
C). Switch their Infrastructure over to Ubuntu and switch to Mir <--- Probably not happenening

[emblemparade]

Most Steam games that support Linux use SDL, either directly or via a library or engine that does (even DOSBox uses SDL).

And SDL already supports Mir as a backend. Honestly, it's not even that much code there to support X11 vs. Wayland vs. Mir (as well as the other non-Linux backends) -- SDL doesn't need to do that much other than open a window and get a drawing context (including an OpenGL or OpenGL ES context). It was a relatively easy patch.

And since SteamOS doesn't really need to run a desktop environment, just boot directly in the Steam client, it doesn't seem to make a big difference what it uses as the display stack. I guess in the end they'll just choose what works best for gaming: best performance and best support from the GPU drivers.

For a while, at least, it will be -- perhaps surprisingly -- X11. The promise of better performance via Wayland/Mir isn't there yet, though there is of course great potential. For now, the big advantage of these new display technologies is vastly simplifying deployments, as well as offering much-needed features, such as cohesive login screens. In the long run, Wayland/Mir will surely provide better performance for gaming, too, and I imagine SteamOS will simply pick the one that is better for gamers, or perhaps with promise that it would be better for gamers in the future.

[TheBlackCat]

Despite what Martin says, if a toolkit is failing to do that, it's a bug with the toolkit and needs to be fixed there rather than with a dozen ugly #ifdefs in your application code.

In the real world, no toolkit can ever possibly handle every possible use-case. It is a nice ideal, but in practice some use-cases are too niche or too specific.