Funny, I was literally just looking at this issue today. I switched to wayland a few weeks ago, just because it seems to save a lot of battery power. But so much basic functionality is still broken it's infuriating. And then so many things seem to follow the "unix functionality" and as a result they're half baked tools that aren't really working properly IMHO.
A lot of these issues have fixes or workarounds directly in KDE.
For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects.
There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone.
XWayland has had 2 or 3 patches to handle hidpi when the main wayland screen has fractional scaling, none of them are merged and they seem hardly active. KDE works around that by allowing you to turn it off for xwayland clients. Sway just passes it down and blurs everything.
When I exit a wayland session and then restart it the screen locks up. This doesn't happen with normal X.
And then there is electron. Slack is not the only app that ignores electron settings and doesn't run with wayland support. In chrome and electron it's supposedly supported but you have to toggle it yourself? What is this madness?
These things seem like basic functionality for me. I don't really get it. Sure, maybe I shouldn't expect a proper experience for random sway tools, so that makes the first two points irrelevant. But the fact that years in they still haven't found a proper solution on passing down hidpi for xwayland? That's incomprehensible for me.
>For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects.
>One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it.
If you're not a fan of making scripts then sway (and wlsunset I assume) is not for you. My sway install is held together by a myriad of scripts - keybindings are handled by a script, starting programs via bemenu goes through a script, sway itself is started by a script, etc. That's just how this compositor and its ecosystem are designed - they're for people who want the software itself to do the smallest possible thing with the least possible assumptions so that the user can do whatever they want to fill in the rest.
The problem isn’t that it’s held together by individual scripts and apps that one can replace or hack at. The problem is that none of these pieces ship in place.
Ideally you’d have some sort of offering that gives you a reasonable starting place with all these composable pieces in place, and then you can hack/replace/add/remove as needed.
Everyone starting from scratch doesn’t make sense. It’s like shipping a Unix system with no app doing it’s own paging because the devs rightly expect you to use some other tool to page output for you, but there’s no less/more installed (and no back buffer in the terminal or terminal emulator to boot). Then you complain and the answer is that you’re supposed to write your own (or research, download, compile, and install something someone else might have hacked up).
The reason why Chrome and Electron still need a flag is simple: Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11. They had a lot of false starts: it took years before Wayland support actually got upstreamed in any regard.
Likewise for Electron. It does generally work to the point of daily-driver usability today with stable Chrome and Electron, but some apps are shipping old and out-of-support versions of Electron, so unfortunately it has become a bit of a waiting game.
Anyways, you can't actually do proper DPI virtualization for X11 apps because afaik there is no protocol for apps to communicate the scale that they are actually rendering at, so there will never be full support for mixed or fractional DPI in XWayland to the same degree that it is supported in Wayland. I'm not 100% sure there would be a point to making such a protocol at this point, since blurry-but-correct surfaces seems like an OK trade-off to keep things working in the long term. If you run real X11 with mixed DPI or fractional DPI, you get quite a range of potential failure cases depending on what apps you run.
At this point most of my screen is filled with native Wayland apps, and Electron apps that use reasonably up-to-date Electron (like VS Code), so it's rare to see a blurry window.
If you want full desktop integration why are you using sway. Most of the functionality you're talking about requires writing scripts if you used i3 or awesome WM on X11 as well so has nothing to do with wayland.
Regarding exiting and restarting a wayland session, how do you do it? GDM, the console? It obviously works for most other people so it seems you're encountering a bug related to your hardware or setup so you could file a bug report with the appropriate project (again doesn't really seem like a wayland issue though).
> For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects.
> There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone.
I used to write little tools like his and my ~/bin is still littered with scripts from 10 years ago
Nowadays I want this functionality to work by default and I won't settle for a less usable system
> And then so many things seem to follow the "unix functionality" and as a result they're half baked tools that aren't really working properly IMHO.
I'm going to disagree pretty strongly with that. In fact, I think most of its problems are that it threw the Unix philosophy out the window. While it's true that it suffers from having made everything a implementation detail that can theoretically be plugged in with a different component, the problem is that they forced everything important to go through the compositor, which bottlenecks composiblilty and doesn't allow you to actually replace individual components without support from the (usually incomplete) monolith in the middle.
Except that nearly everything that makes the usual years-out-of-date Wayland gripe lists here are ALL specified protocols now, it's just a matter of time until they're implemented widely enough to put this to rest.
Fractional scaling, hotkeys, gamma control, screen capture, etc, all have protocols.
It's just early. It's fast to make little scripts and glue it together yourself, and until folks really enumerate use cases and build to meet them, it's going to feel unfinished. It takes years to build out a big project like this.
If you want "just works", stick to X and a mature desktop environment like KDE or Gnome for now (especially if you do any gaming).
This stuff “just worked” in the late 90’s (and probably earlier, assuming access to unix workstation hardware) with X11, when it was roughly the age Wayland is now.
> For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects.
Yeah, the existing tools are pretty low level. For now you need to write your own "scripts" for matching different states from different places (e.g.: idle + battery charging state). Hopefully someone will build higher level tools on top of the existing tools. The APIs are all there (i.e.: there are no technical limitations, it's just that nobody has done it yet).
> There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone.
I've been using GNOME on Wayland for over a year and have literally none of these issues other than X fractional scaling not being great. But even then fractional scaling is good enough that I generally don't notice it. (But all of my daily apps are Wayland native)
> swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not
Sounds like a problem with the tool, not Wayland.
> color warmth setting
This is a general issue on Wayland but GNOME has this built in. I'm surprised that KDE doesn't.
> In chrome and electron it's supposedly supported but you have to toggle it yourself?
I guess Chromium's Wayland support isn't considered production ready? I don't use Chromium often but running on XWayland hasn't bothered me much. I guess this would be more annoying if it was your primary browser.
scripting around hobby projects to fit your needs is the hacker ethos/mindset/what makes using linux/unix fun. But give the ecosystem time and Sway and its ecosystem will be just as good as X and i3 is.
The other one is controllable, but doesn't actually account for time or timezone.
Alright first off: file a bug! How am I supposed to know there is a user with a problem, if they don't tell me!
That said not sure what you mean by this exactly... gammastep 100% does account for the local time. But it does choose the time of day to transition based on the location. Are you in a different location than your timezone is set to?
XFree86 (and later, x.org) have always had better support for hidpi rendering than MacOS X and Windows (by my definition, which is based on the quality of tear-free vector, font and bitmap rendering at non-standard DPIs while using mainstream hardware).
The wayland developers apparently couldn’t figure out
how to read the X11 manual. Why expect them to reimplement it in a superior way?
You might want to research who the first wayland developers were and are now. You might be surprised. Let's just spoiler, that they not only read the X11 manual.
Intent is one thing, whenever userland GUI developers actually uses the API the intended way is another. It's not a bug, it's just a undocumented feature.
If everyone uses the API the "wrong way", now you're stuck supporting the "wrong way" or everything breaks and people WILL complain.
So your issues are basically exclusively with X, X clients and most of all, proprietary X clients that are using major-revs-old versions of Electron. Yeah, that sounds like a real drag, glad I use Wayland and only have Ledger Live that I'm forced to use twice a year.
> But the fact that years in they still haven't found a proper solution on passing down hidpi for xwayland? That's incomprehensible for me.
It's crazy how this is incomprehensible despite it being explained quite clearly every time it comes up. There might be patches, but they are incomplete and they are kludgy and the experts that could push it through ARE WORKING ON IMPROVING WAYLAND. If it remains incomprehensible, go read through the fractional scaling protocol merge and see how much discussion there was for designing that protocol, not even considering the X interop scenario you want.
You can: (1) try really hard to convince volunteers to spend huge amounts of time supporting something they deemed dead years ago, or (2) try to get shitty proprietary companies to, you know, fund a single developer part time to do basic maintenance, (3) use less crappy tools and/or demand that you aren't forced to use shitty tools.
Why is it ALWAYS that people reach for (1)? I swear to god I hope it's folks that don't do OSS development themselves. The entitlement and ignorance makes me head spin. But hey, random OSS devs are much easier to rage at than your CTO, or some random "chat startup" that doesn't give a fuck. So rock on with your ire against OSS devs not working on your explicitly deprecated scenario.
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.
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.
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.
This falls right on time for my 2023 "Linux on the desktop" attempt! (now I wish https://github.com/phil294/AHK_X11 had a Wayland option...)
I can't live without Office! My personal favorite is 2010 x64, as Word then starts faster than the current Wordpad.
Office 2010 works great in Windows 11, but there've been some suspicious move making me believe old office version will be given a poison pill or something under the plausible deniability of "security risks of 13 year old software", like how Outlook 2010 can't connect to outlook.com anymore (though it works great with gmail using google's GWSO plugin)
On MY computer, I run what I want. So I'll try Office 2010 in wine within Wayland.
You can always do so, as long as you're not connected to the internet. In the same way that on your property you can drive what you want, but on the road there are minimum standards of safety that are supposed to be met, and some authority might enforce them. I completely relate to the "who moved my cheese?" effect, but unpatched internet connected software affects more than just yourself. This is not giving companies that completely disable software that could otherwise be hardened with some minimal loss of functionality (like disabling the old Office equation editor) a pass.
Being connected to the internet is nothing like being a car on a road... it's more like joining a "crowd" of "people", with each "person" being another internet-connected computer, and the "crowd" being the network. The recent "pandemic" has taught everyone a lot about virus-spread stuff, so it's an appropriate analogy in my opinion.
Vulnerable pieces of software can be exploited to receive or transmit viruses. The viruses spread through the crowd to anyone who is vulnerable. But just because someone spread the virus doesn't mean an authority is going to crack down on them for being intentionally reckless. If you crash into somebody on the road however...
I've been running these patches to play around with them and it seems pretty good; layered windows (WS_EX_LAYERED) work great, and the issue you would have with non-reparenting X11/XWayland WMs (mostly the mouse cursor being offset) is gone. There's still some minor quirks remaining, so it's not perfect, but a complex program like FL Studio seems to work just fine, as does some games using Wined3d.
The only thing I really hit that would be nice to fix is that it appears tablet support isn't in yet, or at least it didn't work for me. Of course, tablet support is a thing I generally wish could be improved in Wine, especially because Windows apps are slowly moving towards more modern APIs than the old wintab32 defacto standard.
Many Windows applications since Windows 7 support fractional scaling natively (125%, 150%). Is there any way of accessing these modes with WINE? Is this really the same thing as simply setting the font DPI scale (which is what the WINE docs suggest doing)?
I am not knowledgeable on the low level details of Wine, or windows gui apis, but this might actually become properly working on the Wayland backend, as it has a scaling property.
Linux gui applications historically have used X11 for desktop window management (think how your windows layer on top of each other).
Wayland is a new ecosystem that aims to take over for X11 (as X11 was developed in mind with a lot of functionality that many do not care about, and just want a desktop environment).
But it's a controversial effort, and Wayland still doesn't support a lot of the functionality even from the desktop perspective.
Wine is not something that lets you (just) play games, it is effectively a re-implementation of windows low level apis, on top of linux. It lets you call the dlls, and kernel functions, effectively running windows applications in linux.
The wine community is opinionated, and effectively weren't going to support Wayland; because it has some shortcomings in terms of api surface or ways that wayland handles things.
> X11 for desktop window management (think how your windows layer on top of each other)
That’s not really the primary job of these protocols - they are primarily about interfacing with GUI apps and displaying their content — compositing those contents on top of each other in one way or another is the job of a window manager, which can be in-built, or separate from the display server.
> Wayland still doesn't support a lot of the functionality even from the desktop perspective
This has been less and less true. Plenty, or even most distros ship with wayland by default and people don’t even realize it. Under gnome which is arguably the most complete implementation I really have a hard time listing things that don’t work.
It’s less a shortcoming of the wayland api, and more that they didn’t want to implement bad ideas in the protocol with the only use case being windows api compatibility.
Honestly, most people shouldn't even much have to know what Wayland is, and the fact that we're even talking about it is a testament to how badly it was done.
It's the thing that makes graphics on the screen, i.e. why you're not looking at a terminal. For some reason, the decision was made to drastically revamp it in such a way that trying to switch caused a lot of problems. This is like a TEN YEAR OLD deal.
These days it’s pretty much done and finished. Xwayland works fairly well to the point you almost couldn’t tell.
The only issue with wayland usage currently is apps in the xwayland compatibility layer are lacking the new features wayland adds like dpi scaling across screens.
I’m very happy that wayland + pipewire + flatpak now gives us basic security practices like apps having to ask permission to record the mic/screen/webcam vs the state of things in X where being able to draw a window also grants full access to everything.
> We are still fixing stuff in Wayland, stuff that Microsoft and Apple had figured out 20 years ago.
I don't know, given that the UX situation in Windows UI - itself a inconsistent disaster that makes the disjointed things that make up KDE looks like a consistent desktop experience. They can't decide what UI framework to keep supporting, they keep changing what you're supposed to use to build your GUI every bunch of years.
As for the Apple side, well, destroying everything every few years with almost no regards for backwards compatibility isn't "figured out 20 years ago".
Apple has giving up on having consistently non-blurry fractional scaling, pushing apple users to buy monitors "recommended by Apple", even if they are from other vendors.
On Windows not all Apps do scale on a HiDPI display. You then have to fiddle in the program's launch options and hope it's not too blurry when scaled.
Wayland does only have blurriness with certain Xwayland embeddings.
Like screen recording. Popular Wayland native apps not dependant on Xorg. Wine working on Wayland.
Tangible benefits of switching to Wayland. And by those, I don't mean "no screen tearing", since it practically did not exist on most desktop environments with half-decent compositors.
Readit News
A lot of these issues have fixes or workarounds directly in KDE.
For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects.
There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone.
XWayland has had 2 or 3 patches to handle hidpi when the main wayland screen has fractional scaling, none of them are merged and they seem hardly active. KDE works around that by allowing you to turn it off for xwayland clients. Sway just passes it down and blurs everything.
When I exit a wayland session and then restart it the screen locks up. This doesn't happen with normal X.
And then there is electron. Slack is not the only app that ignores electron settings and doesn't run with wayland support. In chrome and electron it's supposedly supported but you have to toggle it yourself? What is this madness?
These things seem like basic functionality for me. I don't really get it. Sure, maybe I shouldn't expect a proper experience for random sway tools, so that makes the first two points irrelevant. But the fact that years in they still haven't found a proper solution on passing down hidpi for xwayland? That's incomprehensible for me.
>One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it.
If you're not a fan of making scripts then sway (and wlsunset I assume) is not for you. My sway install is held together by a myriad of scripts - keybindings are handled by a script, starting programs via bemenu goes through a script, sway itself is started by a script, etc. That's just how this compositor and its ecosystem are designed - they're for people who want the software itself to do the smallest possible thing with the least possible assumptions so that the user can do whatever they want to fill in the rest.
Ideally you’d have some sort of offering that gives you a reasonable starting place with all these composable pieces in place, and then you can hack/replace/add/remove as needed.
Everyone starting from scratch doesn’t make sense. It’s like shipping a Unix system with no app doing it’s own paging because the devs rightly expect you to use some other tool to page output for you, but there’s no less/more installed (and no back buffer in the terminal or terminal emulator to boot). Then you complain and the answer is that you’re supposed to write your own (or research, download, compile, and install something someone else might have hacked up).
Anyways, you can't actually do proper DPI virtualization for X11 apps because afaik there is no protocol for apps to communicate the scale that they are actually rendering at, so there will never be full support for mixed or fractional DPI in XWayland to the same degree that it is supported in Wayland. I'm not 100% sure there would be a point to making such a protocol at this point, since blurry-but-correct surfaces seems like an OK trade-off to keep things working in the long term. If you run real X11 with mixed DPI or fractional DPI, you get quite a range of potential failure cases depending on what apps you run.
At this point most of my screen is filled with native Wayland apps, and Electron apps that use reasonably up-to-date Electron (like VS Code), so it's rare to see a blurry window.
I'm not doubting you, but given that ChromeOS uses Wayland I'm very confused by this.
Do you have any examples? I used ms teams in chrome yesterday, and it seemed to work fine with webcam and screen sharing.
Regarding exiting and restarting a wayland session, how do you do it? GDM, the console? It obviously works for most other people so it seems you're encountering a bug related to your hardware or setup so you could file a bug report with the appropriate project (again doesn't really seem like a wayland issue though).
> There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone.
I used to write little tools like his and my ~/bin is still littered with scripts from 10 years ago
Nowadays I want this functionality to work by default and I won't settle for a less usable system
I'm going to disagree pretty strongly with that. In fact, I think most of its problems are that it threw the Unix philosophy out the window. While it's true that it suffers from having made everything a implementation detail that can theoretically be plugged in with a different component, the problem is that they forced everything important to go through the compositor, which bottlenecks composiblilty and doesn't allow you to actually replace individual components without support from the (usually incomplete) monolith in the middle.
Fractional scaling, hotkeys, gamma control, screen capture, etc, all have protocols.
If you want "just works", stick to X and a mature desktop environment like KDE or Gnome for now (especially if you do any gaming).
Have we hit the two decade mark yet?
This stuff “just worked” in the late 90’s (and probably earlier, assuming access to unix workstation hardware) with X11, when it was roughly the age Wayland is now.
Yeah, the existing tools are pretty low level. For now you need to write your own "scripts" for matching different states from different places (e.g.: idle + battery charging state). Hopefully someone will build higher level tools on top of the existing tools. The APIs are all there (i.e.: there are no technical limitations, it's just that nobody has done it yet).
> There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone.
Try gammastep.
> swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not
Sounds like a problem with the tool, not Wayland.
> color warmth setting
This is a general issue on Wayland but GNOME has this built in. I'm surprised that KDE doesn't.
> In chrome and electron it's supposedly supported but you have to toggle it yourself?
I guess Chromium's Wayland support isn't considered production ready? I don't use Chromium often but running on XWayland hasn't bothered me much. I guess this would be more annoying if it was your primary browser.
I wouldn’t be surprised if slack just ships with a much older chrome build that wasn’t built with wayland support.
Also, have a look at Gnome’s wayland offering. It is by far the most complete as of yet.
[0] https://releases.electronjs.org
Alright first off: file a bug! How am I supposed to know there is a user with a problem, if they don't tell me!
That said not sure what you mean by this exactly... gammastep 100% does account for the local time. But it does choose the time of day to transition based on the location. Are you in a different location than your timezone is set to?
Or if you have the skills please contribute back and fixes these things that bug you!
XFree86 (and later, x.org) have always had better support for hidpi rendering than MacOS X and Windows (by my definition, which is based on the quality of tear-free vector, font and bitmap rendering at non-standard DPIs while using mainstream hardware).
The wayland developers apparently couldn’t figure out how to read the X11 manual. Why expect them to reimplement it in a superior way?
If everyone uses the API the "wrong way", now you're stuck supporting the "wrong way" or everything breaks and people WILL complain.
> But the fact that years in they still haven't found a proper solution on passing down hidpi for xwayland? That's incomprehensible for me.
It's crazy how this is incomprehensible despite it being explained quite clearly every time it comes up. There might be patches, but they are incomplete and they are kludgy and the experts that could push it through ARE WORKING ON IMPROVING WAYLAND. If it remains incomprehensible, go read through the fractional scaling protocol merge and see how much discussion there was for designing that protocol, not even considering the X interop scenario you want.
You can: (1) try really hard to convince volunteers to spend huge amounts of time supporting something they deemed dead years ago, or (2) try to get shitty proprietary companies to, you know, fund a single developer part time to do basic maintenance, (3) use less crappy tools and/or demand that you aren't forced to use shitty tools.
Why is it ALWAYS that people reach for (1)? I swear to god I hope it's folks that don't do OSS development themselves. The entitlement and ignorance makes me head spin. But hey, random OSS devs are much easier to rage at than your CTO, or some random "chat startup" that doesn't give a fuck. So rock on with your ire against OSS devs not working on your explicitly deprecated scenario.
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
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".
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.
I can't live without Office! My personal favorite is 2010 x64, as Word then starts faster than the current Wordpad.
Office 2010 works great in Windows 11, but there've been some suspicious move making me believe old office version will be given a poison pill or something under the plausible deniability of "security risks of 13 year old software", like how Outlook 2010 can't connect to outlook.com anymore (though it works great with gmail using google's GWSO plugin)
On MY computer, I run what I want. So I'll try Office 2010 in wine within Wayland.
You can always do so, as long as you're not connected to the internet. In the same way that on your property you can drive what you want, but on the road there are minimum standards of safety that are supposed to be met, and some authority might enforce them. I completely relate to the "who moved my cheese?" effect, but unpatched internet connected software affects more than just yourself. This is not giving companies that completely disable software that could otherwise be hardened with some minimal loss of functionality (like disabling the old Office equation editor) a pass.
Vulnerable pieces of software can be exploited to receive or transmit viruses. The viruses spread through the crowd to anyone who is vulnerable. But just because someone spread the virus doesn't mean an authority is going to crack down on them for being intentionally reckless. If you crash into somebody on the road however...
The only thing I really hit that would be nice to fix is that it appears tablet support isn't in yet, or at least it didn't work for me. Of course, tablet support is a thing I generally wish could be improved in Wine, especially because Windows apps are slowly moving towards more modern APIs than the old wintab32 defacto standard.
Many Windows applications since Windows 7 support fractional scaling natively (125%, 150%). Is there any way of accessing these modes with WINE? Is this really the same thing as simply setting the font DPI scale (which is what the WINE docs suggest doing)?
Wayland is a new ecosystem that aims to take over for X11 (as X11 was developed in mind with a lot of functionality that many do not care about, and just want a desktop environment).
But it's a controversial effort, and Wayland still doesn't support a lot of the functionality even from the desktop perspective.
Wine is not something that lets you (just) play games, it is effectively a re-implementation of windows low level apis, on top of linux. It lets you call the dlls, and kernel functions, effectively running windows applications in linux.
The wine community is opinionated, and effectively weren't going to support Wayland; because it has some shortcomings in terms of api surface or ways that wayland handles things.
Someone decided to try to support wayland anyway.
That’s not really the primary job of these protocols - they are primarily about interfacing with GUI apps and displaying their content — compositing those contents on top of each other in one way or another is the job of a window manager, which can be in-built, or separate from the display server.
> Wayland still doesn't support a lot of the functionality even from the desktop perspective
This has been less and less true. Plenty, or even most distros ship with wayland by default and people don’t even realize it. Under gnome which is arguably the most complete implementation I really have a hard time listing things that don’t work.
It's the thing that makes graphics on the screen, i.e. why you're not looking at a terminal. For some reason, the decision was made to drastically revamp it in such a way that trying to switch caused a lot of problems. This is like a TEN YEAR OLD deal.
The only issue with wayland usage currently is apps in the xwayland compatibility layer are lacking the new features wayland adds like dpi scaling across screens.
I’m very happy that wayland + pipewire + flatpak now gives us basic security practices like apps having to ask permission to record the mic/screen/webcam vs the state of things in X where being able to draw a window also grants full access to everything.
So defeating.
I don't know, given that the UX situation in Windows UI - itself a inconsistent disaster that makes the disjointed things that make up KDE looks like a consistent desktop experience. They can't decide what UI framework to keep supporting, they keep changing what you're supposed to use to build your GUI every bunch of years.
As for the Apple side, well, destroying everything every few years with almost no regards for backwards compatibility isn't "figured out 20 years ago".
Deleted Comment
On Windows not all Apps do scale on a HiDPI display. You then have to fiddle in the program's launch options and hope it's not too blurry when scaled.
Wayland does only have blurriness with certain Xwayland embeddings.
It's not a solved problem.
MS does a lot of things wrong, but backwards compatibility is still their strong point.
Tangible benefits of switching to Wayland. And by those, I don't mean "no screen tearing", since it practically did not exist on most desktop environments with half-decent compositors.
I ran a few tests and it works for games well already, but there are still some issues to iron out. I'll run more tests once it's upstreamed.