Seems like complaining about how difficult to use Win32 and COM are. And they are if you use them directly! You don't do that - you use libraries that others have sweated over, as you did with raylib.
Win32 has exactly the same setup of problems here as wayland does. Moreso because Win32 just gives you back opaque handles which you are expected to keep track of and use the Win32 API to do any meaningful interactions.
The only understandable complaint is that wayland makes it hard for different windows to interact with one another for security. IMO, that's a silly goal to chase after, but that's just me.
The only problem that has existed is that originally there was a single DPI value, not a different DPI value for each monitor.
This has never created any problem for the people using multiple monitors with the same resolution, but only for the people who have used multiple monitors having different resolutions and who might have not liked the changes in windows size when moving a window from a monitor to another monitor.
That was indeed a problem, but it really affected a rather niche use case and it was also trivial to solve without any change in the X11 design, by just making DPI a per monitor variable, which was done long ago.
So criticizing X11 about a supposed problem with HiDPI is incorrect. I have used only multiple 4k monitors with my PCs, with X11, for more than a dozen years and I never had any problem with HiDPI, with the exception of many Java programs written by morons, which ignore the system settings and which also do not allow the user to change the font used by them. I do not know which is the problem with the Java programmers, but I never encountered programs with such a behavior, except those written in Java. Moreover, the Java programs are also the only that had problems with monitors using 10-bit per color component.
While X11 itself never had problems with supporting HiDPI, at least not in the XFCE that I am using, I heard that other desktop environments have created problems with HiDPI that have nothing to do with X11, by not exposing the X11 DPI settings but providing instead some "window scaling" settings, which is something that I do not know how it is implemented, but there are good chances that it is implemented in a wrong way, judging from the complaints that I have seen. I cannot imagine how one could use correctly a "window scaling" factor, because the font rendering program must know the true DPI value when rendering for instance a 12-point font. If rendering is done at a wrong DPI and then the image is scaled, the result is garbage, so in that case it would not be surprising that people claimed that HiDPI works badly in X11, when in fact it was Gnome or whatever desktop environment was used who was guilty for bad support, not X11. I never had to fight with those desktop environments, but I assume that even those would have worked correctly with HiDPI, when using xrandr to configure X11, instead of using the settings of the desktop environment.
These kind of posts just show how disconnected from reality some of y'all are from what most Linux desktop users nowadays actually need from the desktop platform.
Even without configuring distinct DPIs per monitor that was not a problem for me, because on the small screen of the laptop I kept only some less important application, like the e-mail program, while working on the bigger external displays, so I had no reason to move windows between the small screen of the laptop and the bigger external displays.
But like I said, setting a different DPI value for each monitor has been added to X11 many years ago, I do not remember how many.
I do not see why one would want to move windows between the external displays and the laptop, when you have connected external displays, so I consider this a niche use case, i.e. moving windows between small screens and big screens. I agree with you that having simultaneously big screens and small screens is not niche, so I was not referring to this.
Without a per-screen DPI value you cannot control the ratio between the sizes of a window when is moved between the big screen and the small screen, but even when you control the ratio, moving windows between screens of different sizes does not work well because you must choose some compromise, e.g. if you keep the same physical size some windows from the big screen will not fit on the small screen and if you make the windows occupy the same fraction of the screen size they will change their sizes during moving and they will be more difficult to use on the small screen.
But like I have said, this no longer matters as the problem has been solved even for this niche use case. I do not even remember if this problem still existed by the time when Wayland became usable.
However, such a thing could be relatively easily added to X11 without changing the X protocol, so this does not appear as a sufficient motivation for the existence of Wayland.
I have not tried Wayland yet, because I have never heard anyone describing an important enough advantage of Wayland, while it definitely has disadvantages, like not being network transparent, which is an X11 feature that I use.
Therefore, I do not know which is the truth, but from the complaints that I have heard the problem seems to be that in Wayland it is not simple to control the access rights to windows and clipboards.
Yes, access to those must be restricted, but it must be very easy for users to specify when to share windows with someone else or between their own applications. The complaints about Wayland indicate that this mechanism of how to allow sharing has not been thought well. It should have been something as easy as clicking a set of windows to specify something like the first being allowed to access the others, or like each of them being able to access all the others.
This should have been a major consideration when designing access control and it appears that a lot of such essential requirements have been overlooked when Wayland was designed and they had to be patched somehow later, which does not inspire confidence in the quality of the design.
At a higher level, I've never found someone who is deeply familiar with the Linux GUI software stack who also thinks Wayland is the wrong path, while subjectively as a user most or all of my Linux GUI machines are using Wayland and there's no noticeable difference.
From an app dev perspective, I have a small app I maintain that runs on Mac and Linux with GPU acceleration and at no point did I need to a make any choices related to Wayland vs X.
So, overall, the case that Wayland has some grave technical or strategic flaws just don't pass the smell test. Maybe I'm missing something?
That means that I can run a program, e.g. Firefox, either on my PC or on one of my servers, and I see the same Firefox windows on my display and I am able to use Firefox in the same way, regardless if I run it locally or on a server.
The same with any other program. I cannot do the same with Wayland, which can display only the output of programs that are running on my PC.
This an example of a feature that is irrelevant for those who have a single computer, but there are enough users with multiple computers, for which Wayland is not good enough.
Wayland was designed to satisfy only the needs of a subset of the Linux users. This would have been completely fine, except that now many Linux distributions evolve in a direction where they attempt to force Wayland on everybody, both on those for which Wayland is good enough and on those for which Wayland is not good enough.
I have already passed through a traumatic experience when a gang of incompetents have captured an essential open-source project and they have removed all the features that made that project useful and then they have forced their ideas of what the application should do upon the users. That happened when KDE 3.5 was replaced by KDE 4.
After a disastrous testing of KDE 4 (disastrous not due to bugs but due to intentional design choices incompatible with my needs), I reverted to KDE 3.5 for a couple of years, until the friction needed to keep it has become so great that I was forced to switch to XFCE. At least at that time there was an alternative.
Now, Wayland does not have an alternative, despite not being adequate for everybody. For now, X11 works fine, but since it seems unlikely that Wayland will ever be suitable for me, I am evaluating whether I should maintain a fork of X11 for myself or write a replacement containing only the functionality that I need. That would not be so complex as there are many features of X11 or Wayland that I do not use, so implementing only what I really need might be simple enough. The main application that I do not control would be an Internet browser, like Firefox or Chromium, but that I could run in a VM with Wayland, which would be preferable for security anyway.
Not done it for a while, but ssh into remote machine and start a GUI app used to work for me. It needs one setting in ssh config AFAIK.
> subjectively as a user most or all of my Linux GUI machines are using Wayland and there's no noticeable difference.
Not anymore. There used to be though, and i think it may have got a bad name by being rolled out by distros (especially as the default) before it was ready for most users. I can remember several issues, the worst was with screenshots.
I can accept that as I use a rolling release distro as a daily driver, so you expect some issues, but its not OK if those rough edges hit people using more mainstream distros (which I think they did)
Window positioning API seems like the biggest oversight to me, as someone developing a multi window desktop app at work. That and global hotkeys and accessibility.
Due to my reliance on X over SSH i only run Wayland where i strictly need it (my HDR display, namely)
Actually for wayland there is wprs for remote display of apps so here it goes the network transparency argument...
I do not know the current state of RDP etc., but does it allow you to open a single application rather than an entire desktop on Linux, and does it display correctly for the device you are using rather than the one the app is running on?
My question was "How often has that been a problem. Is it a vulnerability that has been, or or likely to be, exploited in practice?
I would have thought that filesystem access is the biggest issue, followed by network access. There are solutions for these, of course, but in most cases the default is either unrestricted or what the app asked for.
>Getting any example application to work is so incredibly ridiculous, that every second I program on Wayland, I yarn for the times I did Win32 programming.
And that comes from the core of how Wayland is designed.
In Win32, the stable interface / ABI is the set of C functions provided by the operating system through DLLs. These are always dynamically loaded, so Microsoft is free to change the internal interface used for controlling windows at any time. Because of this, decades-old .exes still run fine on Windows 11.
In Wayland, the stable interface is the binary protocol to the compositor, in addition to the libwayland-client library plus extensions. Instead of that socket being an "implementation detail", it's now something that all programs that just want to make a window have to deal with. You also can't just use the socket and ignore the libwayland libraries, because mesa uses libwayland-client and you probably want hardware acceleration.
The other big issue is the core Wayland protocol is useless; you have to use a bunch of protocol extensions to do anything, and different compositors may implement different versions of them. On Win32, Microsoft can just add another C function to user32.dll and you don't have to think about protocol how that gets transformed into messages on the socket layer, or compatibility issues with different sets of extensions being supported by different compositors.
Anyone know of exceptions? People who get mesa working anyhow, some way?
It also doesn't preclude people from making nicer experiences on top of libwayland. Again I'd be curious to see what material is out there. It feels like a library that materializes the current state of things into a local view would go a long way to dispel the rage of people such as the author here, who seem to detest callbacks with firey rage.
The idea of the wayland registry seem unifying & grand to me. Ok yes it's async & doesn't hide it? Lot of ink spilled to be upset about that, and doesn't feel like an immutable fact that must govern life, if that for some reason makes you as mad as this dude.
You don't have to use Mesa's wayland-egl to make EGL work with Wayland, you can easily pass dmabufs by yourself - though this will theoretically be less portable as dmabufs are Linux specific (but practically they're also implemented by various BSDs).
Some compositor's insistence on CSD can make it a bit more complex since you get that in Win32 for free, but on the sane ones you just add xdg-decoration and you're done.
Also, this is all apples-to-oranges anyway, as Win32 is a toolkit, while wayland-client is just a protocol (de)serializer.
I believe the youth nowadays calls what you wrote "copium". Because creating a simple window in Win32 (a whole program, in fact) looks like this:
#ifndef UNICODE
#define UNICODE
#endif
#include <windows.h>
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PWSTR pCmdLine, int nCmdShow)
{
const wchar_t CLASS_NAME[] = L"Sample Window Class";
WNDCLASS wc = { };
wc.lpfnWndProc = WindowProc;
wc.hInstance = hInstance;
wc.lpszClassName = CLASS_NAME;
RegisterClass(&wc);
HWND hwnd = CreateWindowEx(0, CLASS_NAME, L"Hello World! Program",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
NULL, NULL, hInstance, NULL);
if (hwnd == NULL)
{
return 0;
}
ShowWindow(hwnd, nCmdShow);
MSG msg = { };
while (GetMessage(&msg, NULL, 0, 0) > 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return 0;
}
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_DESTROY:
PostQuitMessage(0);
return 0;
default:
return DefWindowProc(hwnd, uMsg, wParam, lParam);
}
}
It's absolutely trivial in comparison. Same thing with Xlib; < 100 lines of C code is enough for a simple app.
Those applications seemed quite simple to write in comparison with what is described in the parent article, despite doing animation in real time based on the mouse and keyboard inputs.