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.
Exactly my impression. And honestly, X11 isn't exactly beautiful like the author is implying. A lot of the same wayland complaints they are putting here apply to X11. The main difference is that wayland is apparently handling the event loop for you while X11 expects you to set that up yourself.
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.
A big complaint in TFA is that Win32 is much much easier to use than Wayland is:
>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.
I was going to point out that wayland is a protocol & surely there must be other ways to do this. But your point about mesa expecting wayland-client is a very tight binding here.
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.
> But your point about mesa expecting wayland-client is a very tight binding here.
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).
Having done some mobile development where app sandboxes have been prevalent for years, it's annoying to deal with but necessary. Given the bad behavior some devs attempt, often ad SDKs trying to perma-cookie users, stealing clipboards, etc, having a platform that can support app isolation seems necessary for normal desktop usage.
The point of wayland, though, is that back then 13-year-old you would get an application that "works" but to support myriad things (like HiDPI) you'd have to DIY it. Whereas now, sure a 13 year old perhaps won't write directly to wayland's APIs, but you'll use a library and have a much more globally usable result. And honestly probably have a better time - less effort for the same result, and with a more maintainable project in the long run.
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.
There is nothing "niche" about plugging in a modern (e.g. made within last 5 years) laptop into an external display.
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.
I always plug my laptop into one or two external displays.
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.
This article is complaining about the complexity of creating a simple window in Wayland, which is much easier in Win32. Wayland doesn't make creating "a rather complex application" any easier either. In both cases you would use a framework. Even more so in Wayland, which doesn't provide widgets or standard dialogs at all, while Win32 does.
Creating a simple window in Wayland isn't much harder than in Win32. You get a wl_surface, attach a wl_buffer to it, wrap it with xdg_toplevel and handle some callbacks for resizing etc. There's some boilerplate that allows all this to be extensible in backwards-compatible ways, but nothing complex, really. simple-touch example in Weston repository has about 400 lines.
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.
> Creating a simple window in Wayland isn't much harder than in Win32. You get a wl_surface, attach a wl_buffer to it, wrap it with xdg_toplevel and handle some callbacks for resizing etc. There's some boilerplate that allows all this to be extensible in backwards-compatible ways, but nothing complex, really. simple-touch example in Weston repository has about 400 lines.
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:
That's significantly less than 400 lines, and requires essentially just two function calls, RegisterClass and CreateWindowEx, the rest is the message loop and its callback.
Yes, this isn't much easier than doing it yourself with libwayland-client, even despite of it being a whole layer of abstraction higher (which is obviously why it's shorter, duh). There's more to type when you go lower level, but fundamentally it's still just "get me a window, here's my content, have some callbacks". Toolkits that provide similar (or even simpler) APIs on top of Wayland exist too.
I have written some OpenGL applications in X11, so they did not use much of X11 besides setting up windows for the OpenGL contexts, after which the rest of the programs were written using the OpenGL API.
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.
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.