I don't care about lightweight virtualization solutions, I care about native applications. If we start talking about virtualization, let's forget about Linux as a software platform altogether. Why would anyone want to run Linux if you can run Flatpaks under Windows, FreeBSD, etc. etc. etc. not to mention increased memory consumption, disk consumption, slower startup, and ... ISVs just don't like it. They like to compile native applications and be done with that like they do for Windows, MacOS, Android and iOS.
> - systray - There are implementations of this
Exactly, "implementations" - which means you cannot write an app which could run under all Wayland DEs and minimize to the systray. This is not an issue under Xorg Windows MacOS - only under Wayland.
> global keyboard shortcuts - It's not clear what this means. There were some proposals for this but none adequately explained the problem.
"proposals", exactly, no APIs, no standard way to make 'em work in all Wayland compositors.
> drag-n-drop
Removed.
> screenshotting, screencasting - This is in the portal API.
Again, Flatpak.
> UI rendering acceleration - Not sure what this means, Wayland clients can just use OpenGL or Vulkan.
It means under Windows you use Win32/D3D and as a programmer you don't have to think how to make your application run fast using system wide GPU hardware acceleration. Again, there's no common API underneath GTK, Qt, EFL which provides it which means a zoo of implementations, bugs and problems.
Still, you're right, it has nothing to do with Wayland, so moved to a new section and rephrased! Good point.
> I'm not sure what this means, applications can use an abstraction layer that deals with it for them.
Doesn't exist currently.
> Well no, if they're short on manpower they can just use an existing compositor such as Mir, wlroots, mutter, etc.
Their lead programmers think otherwise or they would have started using them a long time ago. Please argue with them. Is this an issue right now? YES!
> I'm not sure what can be done about this and this seems like complaining about an unsolveable problem, you will also have similar problems if you try to install Windows 11 or MacOS Monterey on an old PC and try to run modern apps on it.
Windows and X.org both can run on VESA compatible GPUs, that also means you have safe mode in case your graphical driver misbehaves. No such option with Wayland compositors. Is this an issue with Wayland itself? No. Is this a valid current issue? Yes.
> This is completely wrong, basically all applications and UI toolkits just use freetype.
Already mentioned that GTK Qt EFL based applications and Web browsers here on this PC render fonts differently despite all using FreeType. They don't just use FreeType, there's no such thing as "just using FreeType".
> This is also completely wrong, this is what fontconfig is for. It's not the best API though so this section could be rephrased as a review of freetype and fontconfig.
See the previous paragraph. I don't care why they look different and render fonts differently, but the issue remains.
> This is also completely wrong, I just checked Android and MacOS and there is no setting to change the font rendering. Not sure about Windows as I don't use it.
In Android all apps look exactly the same to me. In MacOS last time I used it all apps looked exactly the same. In Windows: classic Win32 applications all look the same: https://www.thewindowsclub.com/disable-font-smoothing-window...
> See what I said above, Wayland cannot implement this. If you wanted this you would have to build it on top of Wayland. Wayland is a API to use when implementing a toolkit.
> Toolkit fragmentation is a real thing which should be mentioned in this article, but see above again, this is not something that Wayland is ever going to be in any position to fix.
Addressed.
> Maybe someone could fix it but those apps really need to be ported to a different API.
Windows has moved from GDI to WDM 1/2/3 transparently and most old applications continue to work. Not a good argument, sorry.
> Well most compositors are using hardware upscaling.
Addressed/removed.
> This is wrong, that's what the pointer constraints protocol is for.
Can you provide more info please?
> This again has nothing to do with X.org or Wayland. The title bars and file dialogs are handled by the toolkit.
> So I think you could just replace this entire section with this statement and then go from there.
Moved/addressed.
> This one's potentially a real problem, but again, it's not clear what "screen/session/keyboard/mouse settings" are. That could be thousands of things. And this also has nothing to do with Wayland because it's not a protocol for configuring settings.
Does Wayland necessitate a compositor implementation for the user? Yes. Does the user want to configure each of dozen possible compositors? Very unlikely, they want to configure their graphics and related settings once and for all.
> See above, this has nothing to do with Wayland.
I've lost you here.
> This statement is badly worded, technically this isn't true and it just needs to be implemented.
Is this an issue RIGHT NOW? Yes.
> These are valid issues, please make these issues more prominent.
Copying and pasting is not my forte.
-------------------------------------------------------
P.S. I beg you - please stop talking about "this needs to be implemented", "this could work if", etc. - expressions like these unfortunately prove it right.
You started with "misinformation" yet the article describes the CURRENT ISSUES plaguing Linux on the desktop.
If you want to actually make a difference (about the article), start talking about _the status quo_.