Hacker News Reader

Comment by justin_ | Hacker News Reader

Weirdly, I was just thinking about this earlier today. Years ago, Wine developers basically refused to add Wayland support. They told the Wayland devs that they'd stick with X11 and XWayland. Why? Because X11 and Win32 specify position windows in absolute screen coordinates, whereas Wayland positions windows relative to their parents. This broke some assumptions across the Wine project about positioning windows, and it didn't seem worth it to fix[0][1]. (And there may have been other issues. I'm not an expert).

Even when the driver was being developed around 2021, it seems like the Wine developers only begrudgingly accepted it[2].

Exciting to see this finally hitting upstream. Progress in desktop Linux often seems slow, but things are moving forward.

[0] https://bugs.winehq.org/show_bug.cgi?id=42284#c1

[1] https://news.ycombinator.com/item?id=19127952

[2] https://www.phoronix.com/news/Wine-Julliard-Wayland-2021

View on HN

Many of those restriction in wayland were by design. Lots of simple task is seen as privileged and restricted to the window manager. These restriction may (or may not) make sense for native wayland application.

However, for wine, as a compatible layer with windows, every deviation from windows behavior is seen as a missing feature.

I am not sure if constantly creating artificial restriction and working around them is "moving forward".

If the restriction is about improving real security issues and people are doing that work for free, then isn’t it worth it? In fact, if I were an open-source project myself and someone is willing to go through the legwork of supporting doing the migration of my codebase to a newer piece of tech, I should be encouraging it and the only thing I get to enforce is quality for it being a default and no substantial regressions when not using that new tech (or I can accept some regressions if I think the value provided is better). So if XWayland is better then fine. But someone has to keep putting maintenance resources into it. The Wayland folks shouldn’t be putting any resources into it when they think they’ve reasonably addressed any real technical blockers and then they should ask for the distro maintainers to remove it because they don’t want to maintain it anymore. The distro owners can donate maintenance cycles or $$ if XWayland is a sufficient experience in terms of providing the perf, DX and security that projects they care about need. Cooler projects with more attention will naturally obtain more dev cycles from talented engineers anyway.

The work is not done for free. It is done by consultant agencies like Collabora with full time paid developers. It is just unclear who funds them.

And no, it's not worth it. The amount of regressions are high compared to the rather questionable security benefits.

“For free” meaning from the perspective of Wine. The project isn’t using its own funds to pay for this.

I don't think the Wine developers were simply being hostile due to a dislike of the concept, I also agree that a Wine Wayland driver seems weird. And yet, here we are: when I use it, it seems to work almost exactly like you'd hope. I'm not sure if the reason this has changed is because there are new standard Wayland protocols that help with some of these issues, or if they just came up with clever workarounds (like always anchoring new windows to be relatively positioned or something.) Either way, it works.

I have heard there are still some tricky impedance mismatches though. I have no idea what they're doing for the system tray, for example. Right now, if I cause a tray icon to exist in Wine with Wayland patches on SwayWM, what happens is I get a "Wine System Tray" window. Not ideal to be sure.

Reply on news.ycombinator.com