The focus of this update is to support a number of new features that are useful for applications and games, and which have also been considered potential integration pain points for the Wayland driver. These are copy/paste, drag-and-drop and support for changing the display mode.
Getting Wine properly supported on Wayland is a hugely important step in the move to Wayland, because thanks to Wine/Proton, gaming on Linux is massively viable. Having to use XWayland for games is not something I’m looking forward to.
Shouldn’t the title be “Wine on Wayland” ?
mail4asim,
Yeah, doing it backwards reminds me of “windows subsystem for linux”, haha.
I may not be behind the KDE 4.0-esque push by distros to get everyone on Wayland before it’s ready, but the more upstreams can be prepared for a day when your average random application operates under the principle of least privilege, the better.
Also, given that Wine already provides its own versions of the Windows common dialogs, it’d be nice to have Wine support the XDG open/save portals on that front so that you can Flatpak-sandbox Wine applications and have the option of using KDE/GNOME Open/Save dialogs in Windows applications.
Why? I’m all for Wayland, but it should all happen automatically in the background, so you never need to interact with it.
Wine is probably the single biggest innovation that allowed me to switch to Linux fulltime over 15 years ago and continue using it now. So I greatly appreciate its devs, and I’m a Codeweavers customer to help support the project. But I really think this huge drive to implement Wayland everywhere is unfortunate, it’s not like Xorg doesn’t work. Now the Wine project has to dedicate resources to fix Linux compatibility instead of focusing on its core purpose of implementing Windows compatibility.
Really read closer. The wayland version of wine has scaling of windows this is not in fact easy to-do under X11. You can see this from valve making gamescope that is a scaler that is a wayland compositor that sits on top of X11 then runs XWayland inside.
Wine virtual desktop exists because different windows functionality does not align to how X11 does things.
There are reasons to implement Wayland.
1) X.org X11 server for bare metal does not have anyone willing to put in the money to fund a developer to maintain it. This is a generic problem.
2) Wine has different features that needs to be implemented that don’t match up to what the X11 protocol can provide.
Yes the arguments that Wayland could not do particular things are really reducing with wine on wayland as a lot of the claimed impossible the wine developer has made work for wine applications.
A lot of features that don’t work in GTK/Qt/Enlightenment toolkits when on wayland already work when wine is on wayland. There is such thing as toolkit makers taking the easy way out claiming that something cannot be done when really all it requires is more effort and bit deeper thinking.
@oiaohm
Can we have that in English?