While I agree that a simple fix this for me button is a great option for users, being a destructive fix it for me button is not. If you want to argue that it is a good thing since this particular piece of software, for the typical linux user who uses without understanding it, I want to counter argument that breaking other software which might rely on wayland in some way and the system now being configured completely different as a side effect, is way worse for a usability point of view.
The user now has one app that works, potentially dozens that don't, doesn't know why it broke, and doesn't know how to fix it. Which is why destructive fix it's for a single app is not a great idea. If it was non-destructive, I would totally agree with you.
From a technical point of view I agree, but I haven't encountered any desktop applications that require Wayland and don't work on X11. It's almost exclusively the other way around in my experience.
I'm sure there are some applications out there that rely on Wayland support, but Wayland is unusable for proper remote tech support without some extensions to the API that Wayland developers don't want to add (notably, the ability to send input to running applications).
There are workarounds (hooking directly into the input system, for example) but those work despite Wayland, not because of it.
I'm willing to go as far as to say that by clicking the "fix me" button, the end user will probably end up fixing more applications than it breaks.
Exactly, if it's not something that can be isolated/determined to ONLY affecting the app itself, it shouldn't be done, and if you really really want to do it, there should be a big fat warning, but I really wouldn't..
I think we can leave that up to the users of the software. If the users grant the developer that authority by running the software, and they're happy with the results, then who are we to say otherwise? True, we can decide not to use the software ourselves. But I don't think people like us that are savvy and contrarian enough to likely be affected by this pragmatic solution are the intended target users of this product anyway, at least not on the receiving end (sometimes called the "host" or "server"), where IIUC Wayland needs to be disabled.
> without some extensions to the API that Wayland developers
Depends on what what you mean by "Wayland developers". Wlroots, and thus sway, support such extensions and I think KDE is open to standardizing such extensions. Gnome supports remote desktop through an xdg portal. The problem is that, as with several other things, all of the compositors haven't agreed on a single standard.
Unfortunately doesn't seem like many, as most apps use some sort of toolkit, and generally most support either only X11 or X11 and Wayland, supporting only Wayland isn't popular.
Though people who want to avoid using toolkits would probably do that, as Wayland's API is much more sane for apps.
However for example Waydroid only supports running on Wayland, and somehow nobody has created a reverse XWayland yet (People that ask for this get constantly redirected to nested compositors which is absolutely the wrong thing, a proper reverse XWayland would seemlessly integrate the apps like Xwayland does, and you could drag them, transparency would work, and https://wayland.app/protocols/xdg-shell#xdg_surface:request:... would be converted to _GTK_FRAME_EXTENTS, etc)
I don't remember which anymore, but a bit over a year ago, I tried switching everything to Wayland, and had too many problems in my specific hardware setup, went back to x11 and some things just broke and some apps I couldn't use. It was not a pleasant journey, so to say. The transition itself can also be a problem, some things can stay in a config and then not be properly reconfigured.
I've used sway, as an example to Wayland only, and if you have specific things configured around Wayland as a compositor, they break too..
But that shouldn't really be the focus point of the discussion, what really is the point, you don't just yank a whole system wide config out from under an unsuspecting user, there's so many variables you just don't know or can account for. Creating a stable application, is also respecting other apps and the system it runs on, not just going in blazin' fixing things for yourself and then not caring about what side effect/consequences it can have. And worse, not informing about it properly.
The user now has one app that works, potentially dozens that don't, doesn't know why it broke, and doesn't know how to fix it. Which is why destructive fix it's for a single app is not a great idea. If it was non-destructive, I would totally agree with you.