Wine-Staging 8.8 Down To Less Than 500 Patches Atop Wine

[phoronix]

Phoronix: Wine-Staging 8.8 Down To Less Than 500 Patches Atop Wine

Building off Friday's release of Wine 8.8 is the Wine-Staging experimental/testing blend that carries hundreds of extra patches atop this open-source software for leveraging Windows games and applications on Linux and other operating systems...

https://www.phoronix.com/news/Wine-Staging-8.8

[uid313]

But does it have Windows 11 style, and does it have Adwaita style?

[Vistaus]

But does it have Windows 11 style, and does it have Adwaita style?

It has Windows 10 style, but not Adwaita style. But it's not hard to find an Adwaita msstyles theme (there's also a Breeze one) or create your own. But I know you don't like any of these options.

[ssokolow]

It has Windows 10 style, but not Adwaita style. But it's not hard to find an Adwaita msstyles theme (there's also a Breeze one) or create your own. But I know you don't like any of these options.

My question is whether enabling an msstyle still causes a big performance hit. That's why I've been using a registry patch to set default Breeze colours on the un-themed/Win9x look.

[Britoid]

But does it have Windows 11 style, and does it have Adwaita style?

What would be the point of theming it? It’s never going to look or feel native and all you’d be doing is increasing the chance of layout bugs.

[Monsterovich]

Why don't the developers of wine staging add a patch to implement child window rendering? A lot of apps require it.

[Vistaus]

My question is whether enabling an msstyle still causes a big performance hit. That's why I've been using a registry patch to set default Breeze colours on the un-themed/Win9x look.

I've never encountered performance hits with msstyles, but yeah, I do prefer the Breeze reg patch.

[WizardGed]

Why don't the developers of wine staging add a patch to implement child window rendering? A lot of apps require it.

Long story short because it's pretty painful to implement (to the best of my knowledge) just about every DE on Linux has bugs surrounding their implementation and the bugs are dependent on the backend (same implementation has different bugs on x11 vs wayland). People get pissy about the wayland one because of relative window placement based on z value but the reality is some DE's on x11 have the same issue. The trick is to be broken enough while also being consistent enough that the way to address the issue is well documented (Windows's absolute placement)

[Monsterovich]

Long story short because it's pretty painful to implement (to the best of my knowledge) just about every DE on Linux has bugs surrounding their implementation and the bugs are dependent on the backend (same implementation has different bugs on x11 vs wayland). People get pissy about the wayland one because of relative window placement based on z value but the reality is some DE's on x11 have the same issue. The trick is to be broken enough while also being consistent enough that the way to address the issue is well documented (Windows's absolute placement)

For some reason this feature is in Proton Wine and there is no problem to implement it. I don't care about issues in Wayland.

[WizardGed]

For some reason this feature is in Proton Wine and there is no problem to implement it. I don't care about issues in Wayland.

taking a cursory look over at the proton GitHub page it looks like they have issues with it as well. bunch of bug reports and specific flags to fix an auto menu close issue. also it appears to use the vulkan api only ATM which isn't fully upstreamed yet. Also its a valve project don't expect anything to be pushed upstream if valve can't do the same or has a plan for it in Wayland it doesn't really matter what anyone likes. Wayland is the first class citizen for valve with all their devices/frameworks being developed for it first.