Hi all,
I would like to provide an update and get some feedback on the current state of the experimental Wayland driver, which was first announced two months ago [1].
The goal of this driver is to allow Windows applications to run directly on Wayland compositors, eventually removing the need for XWayland for many use cases. XWayland, like X11 in general, is receiving less and less developer attention and is unlikely to support modern features like improved fence synchronization or HDR. In addition, since it's yet another layer to go through, it's a source of complexity and potentially of inefficiency. Some more details and thoughts about XWayland vs direct Wayland in the context of Wine can be found here [2].
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.
More detailed instructions for building were included in the first announcement email, but here is a quick version:
$ git clone -b wayland https://gitlab.collabora.com/alf/wine/ $ ./configure --with-wayland $ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ...
I have uploaded a video showcasing the new features here:
Copy/paste support works well in both directions (native Wayland apps <=> Wine apps) with many common formats already supported.
Drag and drop also works in the direction of native Wayland apps to Wine apps for many common formats, but not the other way around. My understanding is that drag and drop in both the X11 and Mac drivers also works only in one direction.
Implementing the display mode change is particularly interesting since Wayland doesn't allow applications to directly change the display mode in the display hardware, but a similar effect can be achieved for particular surfaces by scaling in the compositor (typically using the GPU). In case of a Wine mode that doesn't match the current compositor mode, the driver instructs the compositor to scale the window contents so that they appear as if the hardware display mode had been changed while respecting the aspect ratio.
There are still some rough edges in the implementation of display mode changes, like proper interactions with real mode changes from the Wayland side, which are being worked on.
---
In previous discussions there were some concerns about accepting the Wayland driver into staging, unless there was more confidence that it would eventually be accepted upstream. What's the best way to get an answer to this question of (eventual) upstream acceptance? Even in this somewhat experimental state the driver is viable for many use cases. What would be required to drive this effort forward on the path to staging and, later, upstream inclusion?
Thanks, Alexandros
[1] https://www.winehq.org/pipermail/wine-devel/2020-December/178575.html [2] https://www.winehq.org/pipermail/wine-devel/2020-December/178633.html
Hello Alexandros,
On 2/19/21 9:16 AM, Alexandros Frantzis wrote:
In previous discussions there were some concerns about accepting the Wayland driver into staging, unless there was more confidence that it would eventually be accepted upstream. What's the best way to get an answer to this question of (eventual) upstream acceptance? Even in this somewhat experimental state the driver is viable for many use cases. What would be required to drive this effort forward on the path to staging and, later, upstream inclusion?
Having a positive answer from Alexandre (viz. that a Wayland driver is desirable) is one thing, and would be necessary for me to agree to maintain the driver, but I'd also like to see the following before accepting anything into wine-staging:
* The driver should be at least as feature-complete as the X11 driver. Ideally, it should be *more* feature-complete. That includes not just support at the protocol level, but actual implemented support across all major window managers. There's no point accepting the driver into wine-staging if it's not enabled by default, and I want to deal with as few bug reports as I possibly can. This also helps prove that the driver is not a bad idea.
* A promise from the developers to respond promptly to all bug reports concerning window management (provided, I guess, that the same bug reports don't occur with the X11 driver).
* A promise from the developers to deal with any difficult rebase work. Rebasing is normally our responsibility as wine-staging maintainers, but for large and difficult patch sets we do request that the author be on hand to maintain their own work.
* A promise from the developers to try to upstream the driver after it is introduced into wine-staging. I will *not* be upstreaming the driver myself, and I do *not* intend to maintain it forever. Please do not treat wine-staging as an end goal in itself—it is a testing ground and nothing more.
Even with all that, I'm not thrilled about the driver. I recognize I may not have a choice in the matter, and I recognize I'm not an X11 developer and thus lack significant context, but I don't like the way a feature-incomplete protocol has been forcibly pushed on applications with the apparent intent of quickly replacing and removing its predecessor.
ἔρρωσο, Zebediah
Thanks, Alexandros
On Fri, Feb 19, 2021 at 10:55:20AM -0600, Zebediah Figura (she/her) wrote:
Hello Alexandros,
Hello Zebediah,
Thank you very much for your response!
On 2/19/21 9:16 AM, Alexandros Frantzis wrote:
In previous discussions there were some concerns about accepting the Wayland driver into staging, unless there was more confidence that it would eventually be accepted upstream. What's the best way to get an answer to this question of (eventual) upstream acceptance? Even in this somewhat experimental state the driver is viable for many use cases. What would be required to drive this effort forward on the path to staging and, later, upstream inclusion?
Having a positive answer from Alexandre (viz. that a Wayland driver is desirable) is one thing, and would be necessary for me to agree to maintain the driver, but I'd also like to see the following before accepting anything into wine-staging:
Alexandre (Cc-ed and hi!), it would be great if we could get some input about your views on the upstream inclusion of a Wayland driver.
- The driver should be at least as feature-complete as the X11 driver.
Ideally, it should be *more* feature-complete. That includes not just support at the protocol level, but actual implemented support across all major window managers. There's no point accepting the driver into wine-staging if it's not enabled by default, and I want to deal with as few bug reports as I possibly can. This also helps prove that the driver is not a bad idea.
- A promise from the developers to respond promptly to all bug reports
concerning window management (provided, I guess, that the same bug reports don't occur with the X11 driver).
The Wayland driver is not, in my view, a competitor to the X11 driver, but an independent entity, targeting an entirely different platform with its own capabilities and constraints. The existence of XWayland muddies the waters a bit, and one can certainly consider the Wayland driver as a competitor to the X11 -> XWayland path. This is a path which, as noted previously [1], provides fewer features than direct X11.
Perhaps it would make sense to use X11 running with XWayland as the bar to compare against in this case?
- A promise from the developers to deal with any difficult rebase work.
Rebasing is normally our responsibility as wine-staging maintainers, but for large and difficult patch sets we do request that the author be on hand to maintain their own work.
- A promise from the developers to try to upstream the driver after it
is introduced into wine-staging. I will *not* be upstreaming the driver myself, and I do *not* intend to maintain it forever. Please do not treat wine-staging as an end goal in itself—it is a testing ground and nothing more.
I fully agree with the above.
Even with all that, I'm not thrilled about the driver. I recognize I may not have a choice in the matter, and I recognize I'm not an X11 developer and thus lack significant context, but I don't like the way a feature-incomplete protocol has been forcibly pushed on applications with the apparent intent of quickly replacing and removing its predecessor.
This is certainly a big discussion with reasonable arguments from both sides, depending on the goals and trade-offs that one considers important. Regardless of where one stands, though, the fact is that Wayland adoption has been growing significantly, with some major distributions already using it as their default display architecture, and others planning to do so soon.
This growth in adoption of Wayland as the default choice, coupled with the significant reduction of development activity and thus the lack of new features on X11/XWayland (e.g. HDR), means that a lot of people are going to use Wine on Wayland-based desktops. I believe it would be in the best interest of both Wine and Wayland to work on providing the best experience possible by using a direct driver, instead of forcing users to go through the impedance-mismatch layer of XWayland.
Thanks, Alexandros
[1] https://www.winehq.org/pipermail/wine-devel/2020-December/178633.html
On 2/23/21 10:16 AM, Alexandros Frantzis wrote:
On Fri, Feb 19, 2021 at 10:55:20AM -0600, Zebediah Figura (she/her) wrote:
Hello Alexandros,
Hello Zebediah,
Thank you very much for your response!
On 2/19/21 9:16 AM, Alexandros Frantzis wrote:
In previous discussions there were some concerns about accepting the Wayland driver into staging, unless there was more confidence that it would eventually be accepted upstream. What's the best way to get an answer to this question of (eventual) upstream acceptance? Even in this somewhat experimental state the driver is viable for many use cases. What would be required to drive this effort forward on the path to staging and, later, upstream inclusion?
Having a positive answer from Alexandre (viz. that a Wayland driver is desirable) is one thing, and would be necessary for me to agree to maintain the driver, but I'd also like to see the following before accepting anything into wine-staging:
Alexandre (Cc-ed and hi!), it would be great if we could get some input about your views on the upstream inclusion of a Wayland driver.
- The driver should be at least as feature-complete as the X11 driver.
Ideally, it should be *more* feature-complete. That includes not just support at the protocol level, but actual implemented support across all major window managers. There's no point accepting the driver into wine-staging if it's not enabled by default, and I want to deal with as few bug reports as I possibly can. This also helps prove that the driver is not a bad idea.
- A promise from the developers to respond promptly to all bug reports
concerning window management (provided, I guess, that the same bug reports don't occur with the X11 driver).
The Wayland driver is not, in my view, a competitor to the X11 driver, but an independent entity, targeting an entirely different platform with its own capabilities and constraints. The existence of XWayland muddies the waters a bit, and one can certainly consider the Wayland driver as a competitor to the X11 -> XWayland path. This is a path which, as noted previously [1], provides fewer features than direct X11.
I fail to understand this statement. Wayland is a competitor, or at least a replacement, of X. It is used in the same ways, on the same distributions, and it was explicitly designed as such. That may not matter to Wine as an isolated project, but in my view we are not—we are part of an open source ecosystem, and should care about what happens to the libraries and protocols that we depend on.
Perhaps it would make sense to use X11 running with XWayland as the bar to compare against in this case?
In terms of avoiding bug reports, perhaps. In terms of proving that Wayland is not as bad as an idea as I fear, we really should compare it to native X11. Wine has to support a lot of things; if Wayland can't support them (or can't support them except with a hacky and WM-dependent interface) it's not a sufficient window protocol.
(Frankly, it's even possible that a user will upgrade from one Ubuntu LTS to the next and find that suddenly wine isn't working as well as it was before, because they've been quietly switched from X11 to Wayland. At that point it wouldn't matter that XWayland provides no better of an experience.)
- A promise from the developers to deal with any difficult rebase work.
Rebasing is normally our responsibility as wine-staging maintainers, but for large and difficult patch sets we do request that the author be on hand to maintain their own work.
- A promise from the developers to try to upstream the driver after it
is introduced into wine-staging. I will *not* be upstreaming the driver myself, and I do *not* intend to maintain it forever. Please do not treat wine-staging as an end goal in itself—it is a testing ground and nothing more.
I fully agree with the above.
Even with all that, I'm not thrilled about the driver. I recognize I may not have a choice in the matter, and I recognize I'm not an X11 developer and thus lack significant context, but I don't like the way a feature-incomplete protocol has been forcibly pushed on applications with the apparent intent of quickly replacing and removing its predecessor.
This is certainly a big discussion with reasonable arguments from both sides, depending on the goals and trade-offs that one considers important. Regardless of where one stands, though, the fact is that Wayland adoption has been growing significantly, with some major distributions already using it as their default display architecture, and others planning to do so soon.
This growth in adoption of Wayland as the default choice, coupled with the significant reduction of development activity and thus the lack of new features on X11/XWayland (e.g. HDR), means that a lot of people are going to use Wine on Wayland-based desktops. I believe it would be in the best interest of both Wine and Wayland to work on providing the best experience possible by using a direct driver, instead of forcing users to go through the impedance-mismatch layer of XWayland.
Yes, and if Wayland didn't have such glaring problems I'd fully agree. But at this point it's not clear to me that Wayland can (ever!) provide "the best experience possible" for those distributions already using it, or that it's worth what will probably be a lot of ugly code on our part.
Thanks, Alexandros
[1] https://www.winehq.org/pipermail/wine-devel/2020-December/178633.html
Alexandros Frantzis alexandros.frantzis@collabora.com writes:
On Fri, Feb 19, 2021 at 10:55:20AM -0600, Zebediah Figura (she/her) wrote:
Hello Alexandros,
Hello Zebediah,
Thank you very much for your response!
On 2/19/21 9:16 AM, Alexandros Frantzis wrote:
In previous discussions there were some concerns about accepting the Wayland driver into staging, unless there was more confidence that it would eventually be accepted upstream. What's the best way to get an answer to this question of (eventual) upstream acceptance? Even in this somewhat experimental state the driver is viable for many use cases. What would be required to drive this effort forward on the path to staging and, later, upstream inclusion?
Having a positive answer from Alexandre (viz. that a Wayland driver is desirable) is one thing, and would be necessary for me to agree to maintain the driver, but I'd also like to see the following before accepting anything into wine-staging:
Alexandre (Cc-ed and hi!), it would be great if we could get some input about your views on the upstream inclusion of a Wayland driver.
I'm not opposed in principle to having a Wayland driver upstream. In fact I started writing one myself many years ago... It got stalled when I realized there was essentially no way to do decent window management, and that the best we could do would be the equivalent of X11 desktop mode, where we manage the windows ourselves. I don't have the impression that the situation has improved in the meantime, or that there is any interest in improving it.
That doesn't mean it couldn't go upstream, but then there will be constraints on what hacks and workarounds you'll be able to do. For instance, it will have to stick to protocols that are standardized across desktops, without adding compositor-specific workarounds, just like we don't allow window manager specific hacks on the X11 side otherwise it quickly becomes unmaintainable.
This growth in adoption of Wayland as the default choice, coupled with the significant reduction of development activity and thus the lack of new features on X11/XWayland (e.g. HDR), means that a lot of people are going to use Wine on Wayland-based desktops. I believe it would be in the best interest of both Wine and Wayland to work on providing the best experience possible by using a direct driver, instead of forcing users to go through the impedance-mismatch layer of XWayland.
I expect you'll find a much bigger impedance mismatch between Wayland and Win32, and that in the end you'll end up reinventing XWayland using Windows APIs. But if that's your idea of fun go ahead ;-)
On Wed, Feb 24, 2021 at 09:34:09AM +0100, Alexandre Julliard wrote:
Alexandros Frantzis alexandros.frantzis@collabora.com writes:
On Fri, Feb 19, 2021 at 10:55:20AM -0600, Zebediah Figura (she/her) wrote:
Hello Alexandros,
Hello Zebediah,
Thank you very much for your response!
On 2/19/21 9:16 AM, Alexandros Frantzis wrote:
In previous discussions there were some concerns about accepting the Wayland driver into staging, unless there was more confidence that it would eventually be accepted upstream. What's the best way to get an answer to this question of (eventual) upstream acceptance? Even in this somewhat experimental state the driver is viable for many use cases. What would be required to drive this effort forward on the path to staging and, later, upstream inclusion?
Having a positive answer from Alexandre (viz. that a Wayland driver is desirable) is one thing, and would be necessary for me to agree to maintain the driver, but I'd also like to see the following before accepting anything into wine-staging:
Alexandre (Cc-ed and hi!), it would be great if we could get some input about your views on the upstream inclusion of a Wayland driver.
I'm not opposed in principle to having a Wayland driver upstream. In fact I started writing one myself many years ago... It got stalled when I realized there was essentially no way to do decent window management, and that the best we could do would be the equivalent of X11 desktop mode, where we manage the windows ourselves. I don't have the impression that the situation has improved in the meantime, or that there is any interest in improving it.
That doesn't mean it couldn't go upstream, but then there will be constraints on what hacks and workarounds you'll be able to do. For instance, it will have to stick to protocols that are standardized across desktops, without adding compositor-specific workarounds, just like we don't allow window manager specific hacks on the X11 side otherwise it quickly becomes unmaintainable.
Hello Alexandre,
Thank you for the reply!
It's indeed an explicit goal of this effort to use only official and widely supported protocols. Although some gaps remain, this approach has got us quite far already.
From the discussions so far, my understanding is that going through
wine-staging would the preferred path to upstreaming in this case. I would like to confirm that my understanding is indeed correct, or whether Zebediah or you would recommend some different approach.
Thanks, Alexandros
On 2/24/21 12:55 PM, Alexandros Frantzis wrote:
On Wed, Feb 24, 2021 at 09:34:09AM +0100, Alexandre Julliard wrote:
Alexandros Frantzis alexandros.frantzis@collabora.com writes:
On Fri, Feb 19, 2021 at 10:55:20AM -0600, Zebediah Figura (she/her) wrote:
Hello Alexandros,
Hello Zebediah,
Thank you very much for your response!
On 2/19/21 9:16 AM, Alexandros Frantzis wrote:
In previous discussions there were some concerns about accepting the Wayland driver into staging, unless there was more confidence that it would eventually be accepted upstream. What's the best way to get an answer to this question of (eventual) upstream acceptance? Even in this somewhat experimental state the driver is viable for many use cases. What would be required to drive this effort forward on the path to staging and, later, upstream inclusion?
Having a positive answer from Alexandre (viz. that a Wayland driver is desirable) is one thing, and would be necessary for me to agree to maintain the driver, but I'd also like to see the following before accepting anything into wine-staging:
Alexandre (Cc-ed and hi!), it would be great if we could get some input about your views on the upstream inclusion of a Wayland driver.
I'm not opposed in principle to having a Wayland driver upstream. In fact I started writing one myself many years ago... It got stalled when I realized there was essentially no way to do decent window management, and that the best we could do would be the equivalent of X11 desktop mode, where we manage the windows ourselves. I don't have the impression that the situation has improved in the meantime, or that there is any interest in improving it.
That doesn't mean it couldn't go upstream, but then there will be constraints on what hacks and workarounds you'll be able to do. For instance, it will have to stick to protocols that are standardized across desktops, without adding compositor-specific workarounds, just like we don't allow window manager specific hacks on the X11 side otherwise it quickly becomes unmaintainable.
Hello Alexandre,
Thank you for the reply!
It's indeed an explicit goal of this effort to use only official and widely supported protocols. Although some gaps remain, this approach has got us quite far already.
From the discussions so far, my understanding is that going through wine-staging would the preferred path to upstreaming in this case. I would like to confirm that my understanding is indeed correct, or whether Zebediah or you would recommend some different approach.
Yes, with my fears mostly assuaged, I at least am willing to sign on to maintain the driver in wine-staging.
Thanks, Alexandros
Hi,
Il 24/02/21 09:34, Alexandre Julliard ha scritto:
I'm not opposed in principle to having a Wayland driver upstream. In fact I started writing one myself many years ago... It got stalled when I realized there was essentially no way to do decent window management, and that the best we could do would be the equivalent of X11 desktop mode, where we manage the windows ourselves. I don't have the impression that the situation has improved in the meantime, or that there is any interest in improving it.
I have very little knowledge of how Wayland compares with X11 from the protocol point of view. Could you please elaborate a little bit on what is missing in Wayland? The only thing I've heard about so far is changing a window's absolute position. Can be annoying, but it's not a terrible issue...
My understanding is that X11 is basically in maintenance mode ad libitum, so as time passes it will lack new features that will get added only to Wayland. Eventually people might find that using Wine-with-Wayland, while having problems because Wayland is not perfect, is still better than Wine-with-Xorg or Wine-with-XWayland, because the latter do not support the features they like. So I think that having a Wayland driver would be a good service to at least some users.
On the other hand I don't think, as Zeb was suggesting, that if there is a Wayland driver, then it should have higher priority than X11. It's totally sensible to ship it, but require the user to set it as preferred in winecfg or some other way if they want to use it. Users who believe that direct Wayland's advantages outweigh its disadvantages will use it, and the others will not.
My 2 cents, Giovanni.
On 2/26/21 11:23 AM, Giovanni Mascellani wrote:
Hi,
Il 24/02/21 09:34, Alexandre Julliard ha scritto:
I'm not opposed in principle to having a Wayland driver upstream. In fact I started writing one myself many years ago... It got stalled when I realized there was essentially no way to do decent window management, and that the best we could do would be the equivalent of X11 desktop mode, where we manage the windows ourselves. I don't have the impression that the situation has improved in the meantime, or that there is any interest in improving it.
I have very little knowledge of how Wayland compares with X11 from the protocol point of view. Could you please elaborate a little bit on what is missing in Wayland? The only thing I've heard about so far is changing a window's absolute position. Can be annoying, but it's not a terrible issue...
My understanding is that X11 is basically in maintenance mode ad libitum, so as time passes it will lack new features that will get added only to Wayland. Eventually people might find that using Wine-with-Wayland, while having problems because Wayland is not perfect, is still better than Wine-with-Xorg or Wine-with-XWayland, because the latter do not support the features they like. So I think that having a Wayland driver would be a good service to at least some users.
On the other hand I don't think, as Zeb was suggesting, that if there is a Wayland driver, then it should have higher priority than X11. It's totally sensible to ship it, but require the user to set it as preferred in winecfg or some other way if they want to use it. Users who believe that direct Wayland's advantages outweigh its disadvantages will use it, and the others will not.
As a general rule putting patch sets in wine-staging that aren't enabled by default is pointless, inasmuch as wine-staging is only a testing ground. If we're going to root out all the bugs, I'd like the patch set to be enabled by default for all users, not just the ones that know about it and want to use it.
That doesn't necessarily mean that the driver should be the default in upstream wine, though.
My 2 cents, Giovanni.
On 28/02/2021 01:51, Zebediah Figura (she/her) wrote:
On 2/26/21 11:23 AM, Giovanni Mascellani wrote:
Hi,
Il 24/02/21 09:34, Alexandre Julliard ha scritto:
I'm not opposed in principle to having a Wayland driver upstream. In fact I started writing one myself many years ago... It got stalled when I realized there was essentially no way to do decent window management, and that the best we could do would be the equivalent of X11 desktop mode, where we manage the windows ourselves. I don't have the impression that the situation has improved in the meantime, or that there is any interest in improving it.
I have very little knowledge of how Wayland compares with X11 from the protocol point of view. Could you please elaborate a little bit on what is missing in Wayland? The only thing I've heard about so far is changing a window's absolute position. Can be annoying, but it's not a terrible issue...
My understanding is that X11 is basically in maintenance mode ad libitum, so as time passes it will lack new features that will get added only to Wayland. Eventually people might find that using Wine-with-Wayland, while having problems because Wayland is not perfect, is still better than Wine-with-Xorg or Wine-with-XWayland, because the latter do not support the features they like. So I think that having a Wayland driver would be a good service to at least some users.
On the other hand I don't think, as Zeb was suggesting, that if there is a Wayland driver, then it should have higher priority than X11. It's totally sensible to ship it, but require the user to set it as preferred in winecfg or some other way if they want to use it. Users who believe that direct Wayland's advantages outweigh its disadvantages will use it, and the others will not.
As a general rule putting patch sets in wine-staging that aren't enabled by default is pointless, inasmuch as wine-staging is only a testing ground. If we're going to root out all the bugs, I'd like the patch set to be enabled by default for all users, not just the ones that know about it and want to use it.
That doesn't necessarily mean that the driver should be the default in upstream wine, though.
My 2 cents, Giovanni.
Doesn't wine-staging have a specific tab in winecfg for experimental options that aren't on by default? CSMT used to be one of those way back.
On 3/1/21 7:49 AM, Gabriel Ivăncescu wrote:
On 28/02/2021 01:51, Zebediah Figura (she/her) wrote:
On 2/26/21 11:23 AM, Giovanni Mascellani wrote:
Hi,
Il 24/02/21 09:34, Alexandre Julliard ha scritto:
I'm not opposed in principle to having a Wayland driver upstream. In fact I started writing one myself many years ago... It got stalled when I realized there was essentially no way to do decent window management, and that the best we could do would be the equivalent of X11 desktop mode, where we manage the windows ourselves. I don't have the impression that the situation has improved in the meantime, or that there is any interest in improving it.
I have very little knowledge of how Wayland compares with X11 from the protocol point of view. Could you please elaborate a little bit on what is missing in Wayland? The only thing I've heard about so far is changing a window's absolute position. Can be annoying, but it's not a terrible issue...
My understanding is that X11 is basically in maintenance mode ad libitum, so as time passes it will lack new features that will get added only to Wayland. Eventually people might find that using Wine-with-Wayland, while having problems because Wayland is not perfect, is still better than Wine-with-Xorg or Wine-with-XWayland, because the latter do not support the features they like. So I think that having a Wayland driver would be a good service to at least some users.
On the other hand I don't think, as Zeb was suggesting, that if there is a Wayland driver, then it should have higher priority than X11. It's totally sensible to ship it, but require the user to set it as preferred in winecfg or some other way if they want to use it. Users who believe that direct Wayland's advantages outweigh its disadvantages will use it, and the others will not.
As a general rule putting patch sets in wine-staging that aren't enabled by default is pointless, inasmuch as wine-staging is only a testing ground. If we're going to root out all the bugs, I'd like the patch set to be enabled by default for all users, not just the ones that know about it and want to use it.
That doesn't necessarily mean that the driver should be the default in upstream wine, though.
My 2 cents, Giovanni.
Doesn't wine-staging have a specific tab in winecfg for experimental options that aren't on by default? CSMT used to be one of those way back.
Yes. However, this is a decision that the current wine-staging maintainers made, and some patches are effectively grandfathered in because we don't have the time to change them.
(There's also the GTK theming patch, which makes more sense to be optional since it's a matter of user preference. Really that should be the only thing on that tab...)
Hi,
Il 28/02/21 00:51, Zebediah Figura (she/her) ha scritto:
As a general rule putting patch sets in wine-staging that aren't enabled by default is pointless, inasmuch as wine-staging is only a testing ground. If we're going to root out all the bugs, I'd like the patch set to be enabled by default for all users, not just the ones that know about it and want to use it.
This makes sense. For the record, my comment was about which default to use for upstream Wine.
Giovanni.
-
Alexandre Julliard -
Alexandros Frantzis -
Gabriel Ivăncescu -
Giovanni Mascellani -
Zebediah Figura (she/her)