6 ms·

The last time I checked on this situation, the Wine developers said they had indefinitely halted any plans for a Wayland port and not so much for the graphical

The last time I checked on this situation, the Wine developers said they had indefinitely halted any plans for a Wayland port and not so much for the graphical reasons that this article suggests but the windowing a.p.i reasons. — so what changed in this regard? Can this project actually render Windows windows on Wine or is it only for fullscreen games?

sho_hn 6y ago
What changed is that the Wayland world keeps evolving, and things aren't always as dramatic as they first appear. Bridging the windowing semantics is difficult indeed as the Wayland approach doesn't let clients introspect the windowing system or absolutely position themselves, but it doesn't mean you can't get quite far with the excellent relative positioning provided by the xdg-shell/xdg-popup protocols, for example. The video in the article demonstrates Notepad and other windowed apps.
pantalaimon 6y ago
Well, wine developers are still skeptical https://www.winehq.org/pipermail/wine-devel/2021-February/181338.html https://www.winehq.org/pipermail/wine-devel/2021-February/18...
- Blikkentrekker 6y ago
  That is a single Wine staging developer, however., not “wine developers”. That having been said, I share some of the concerns that Wayland is pushed, not as an alternative to X11 but as a replacement that many powerful players insist must and shall replace X11, all the while lacking many features that X11 has and that are used.
  - bluGill 6y ago
    Wayland is pushed because nobody is maintaining X11, the people who used to maintain X11 are now working on wayland. In short your choice is push wayland everywhere, or fund a new group of people to maintain X11. For the later I have little confidence in one person alone making significant progress, but if you want to prove me wrong - well good luck. I am betting on wayland long term, though I still have X11 a lot of places.
    - Blikkentrekker 6y ago
      Perhaps , but that doesn't change that as of this moment, Wayland lacks many feature that users have come to rely on. Certainly you can see the problem with the situation that developers of one project abandon it and start a new project that lacks many of the features of the old and claim that users should use the new one. It's not an issue of what will win in the long run; it's an issue of a replacement product being pushed for adoption long ere it be ready.
      - cycloptic 6y ago
        I think that's why TFA is working on some of the features that are missing, e.g. a native Wine port.
        Blikkentrekker 6y ago
        Those are not the features of the protocol that are missing; that is an application that does not support it. The features of the protocol that are missing are what made Wine developers indefinitely shelf their attempt to port it and as I read it, this port indeed is only a partial port for certain use cases that can't map the entirety of Window's windowing a.p.i. as Wine generally can. The reason many people aren't using Wayland is not because their favorite application does not support it yet, but because at this stage the protocol on a fundamental level does not allow them to do what they need to.
        cycloptic 6y ago
        In general, the wayland protocol is not the same as the X11 protocol and is probably not going to have all the same features implemented in the same way. If it was the same, it would be called the X11 protocol. From a user perspective it doesn't matter what the protocol is or how certain things are implemented, ultimately the only thing they care about is if the application works. Just my observation, asking for X11-style sandbox escapes to support Wine is a mistake, it's much better to work with the system so it becomes feasible to run Wine applications within a sandbox. It just doesn't make sense to break Wayland's design because of other insecure legacy designs in the Win32 API.
ubercow13 6y ago
It's not for fullscreen games, it's for Windows windows. There is a separate effort for fullscreen games: https://github.com/varmd/wine-wayland https://github.com/varmd/wine-wayland edit: my mistake, the difference is actually that this one doesn't support Vulkan, and the project I linked only supports Vulkan. So, for playing games with DXVK, the linked project is the more useful one.
- Blikkentrekker 6y ago
  So what changed? It is my understanding that the WinAPI requires absolute window positioning to function. — has Wayland since offered that?
  - ubercow13 6y ago
    It's explained a bit in the previous blog post [1]. I expect that comment you are referencing from a Wine developer was just dismissive without giving any thought to possible non-obvious solutions. Now someone has implemented an alternative solution. [1] https://www.collabora.com/news-and-blog/news-and-events/a-wayland-driver-for-wine.html https://www.collabora.com/news-and-blog/news-and-events/a-wa...
    - Blikkentrekker 6y ago
      I feel your language underestimates the scope of the problem. As the blog post itself implies: > The Wayland protocol is by design more constrained compared to more traditional display systems like X11 and win32, which brings a unique sets of challenges in the integration of Wayland with Wine. Since Wayland's window model is not based on a single flat 2D co-ordinate space, as X11's was, the Wayland protocol doesn't allow apps to control their absolute position on the screen. Win32 applications heavily rely on this feature, so the Wayland driver uses a few tricks to accommodate many common cases, like transient windows (menus, tooltips etc). It doesn't so much explain what it solved and how, but that it delivered a partial implementation of common cases based on what can be done at this point.
      - 6y ago

sho_hn 6y ago

What changed is that the Wayland world keeps evolving, and things aren't always as dramatic as they first appear. Bridging the windowing semantics is difficult indeed as the Wayland approach doesn't let clients introspect the windowing system or absolutely position themselves, but it doesn't mean you can't get quite far with the excellent relative positioning provided by the xdg-shell/xdg-popup protocols, for example. The video in the article demonstrates Notepad and other windowed apps.

pantalaimon 6y ago

Well, wine developers are still skeptical https://www.winehq.org/pipermail/wine-devel/2021-February/181338.html https://www.winehq.org/pipermail/wine-devel/2021-February/18...

Blikkentrekker 6y ago
That is a single Wine staging developer, however., not “wine developers”. That having been said, I share some of the concerns that Wayland is pushed, not as an alternative to X11 but as a replacement that many powerful players insist must and shall replace X11, all the while lacking many features that X11 has and that are used.
- bluGill 6y ago
  Wayland is pushed because nobody is maintaining X11, the people who used to maintain X11 are now working on wayland. In short your choice is push wayland everywhere, or fund a new group of people to maintain X11. For the later I have little confidence in one person alone making significant progress, but if you want to prove me wrong - well good luck. I am betting on wayland long term, though I still have X11 a lot of places.
  - Blikkentrekker 6y ago
    Perhaps , but that doesn't change that as of this moment, Wayland lacks many feature that users have come to rely on. Certainly you can see the problem with the situation that developers of one project abandon it and start a new project that lacks many of the features of the old and claim that users should use the new one. It's not an issue of what will win in the long run; it's an issue of a replacement product being pushed for adoption long ere it be ready.
    - cycloptic 6y ago
      I think that's why TFA is working on some of the features that are missing, e.g. a native Wine port.
      - Blikkentrekker 6y ago
        Those are not the features of the protocol that are missing; that is an application that does not support it. The features of the protocol that are missing are what made Wine developers indefinitely shelf their attempt to port it and as I read it, this port indeed is only a partial port for certain use cases that can't map the entirety of Window's windowing a.p.i. as Wine generally can. The reason many people aren't using Wayland is not because their favorite application does not support it yet, but because at this stage the protocol on a fundamental level does not allow them to do what they need to.
        cycloptic 6y ago
        In general, the wayland protocol is not the same as the X11 protocol and is probably not going to have all the same features implemented in the same way. If it was the same, it would be called the X11 protocol. From a user perspective it doesn't matter what the protocol is or how certain things are implemented, ultimately the only thing they care about is if the application works. Just my observation, asking for X11-style sandbox escapes to support Wine is a mistake, it's much better to work with the system so it becomes feasible to run Wine applications within a sandbox. It just doesn't make sense to break Wayland's design because of other insecure legacy designs in the Win32 API.

ubercow13 6y ago

It's not for fullscreen games, it's for Windows windows. There is a separate effort for fullscreen games: https://github.com/varmd/wine-wayland https://github.com/varmd/wine-wayland edit: my mistake, the difference is actually that this one doesn't support Vulkan, and the project I linked only supports Vulkan. So, for playing games with DXVK, the linked project is the more useful one.

Blikkentrekker 6y ago
So what changed? It is my understanding that the WinAPI requires absolute window positioning to function. — has Wayland since offered that?
- ubercow13 6y ago
  It's explained a bit in the previous blog post [1]. I expect that comment you are referencing from a Wine developer was just dismissive without giving any thought to possible non-obvious solutions. Now someone has implemented an alternative solution. [1] https://www.collabora.com/news-and-blog/news-and-events/a-wayland-driver-for-wine.html https://www.collabora.com/news-and-blog/news-and-events/a-wa...
  - Blikkentrekker 6y ago
    I feel your language underestimates the scope of the problem. As the blog post itself implies: > The Wayland protocol is by design more constrained compared to more traditional display systems like X11 and win32, which brings a unique sets of challenges in the integration of Wayland with Wine. Since Wayland's window model is not based on a single flat 2D co-ordinate space, as X11's was, the Wayland protocol doesn't allow apps to control their absolute position on the screen. Win32 applications heavily rely on this feature, so the Wayland driver uses a few tricks to accommodate many common cases, like transient windows (menus, tooltips etc). It doesn't so much explain what it solved and how, but that it delivered a partial implementation of common cases based on what can be done at this point.
    - 6y ago