| |
| ▲ | 201984 16 hours ago | parent | next [-] | | 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. | | |
| ▲ | jauntywundrkind 16 hours ago | parent [-] | | 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. | | |
| ▲ | seba_dos1 15 hours ago | parent [-] | | > 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). |
|
| |
| ▲ | hedgehog 16 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | graemep 16 hours ago | parent [-] | | How often has that been a problem for desktop OSes? | | |
| ▲ | hedgehog 16 hours ago | parent [-] | | Constantly. Phishing, tech support scams, supply chain attacks on e.g. NPM, problems have been rampant since we connected desktops to the internet. | | |
| ▲ | graemep 16 hours ago | parent [-] | | I mean specifically things that using using Wayland will improve. | | |
| ▲ | hedgehog 16 hours ago | parent [-] | | The commenter above appeared to reference Wayland preventing apps from having unrestricted access to screen contents and clipboard, so those. | | |
| ▲ | adrian_b 15 hours ago | parent [-] | | Having some kind of access control list or other method of enforcing access rights for windows and clipboards is definitely a good thing. 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. | | |
| ▲ | hedgehog 14 hours ago | parent | next [-] | | Having a medium understanding of graphics hardware and software stack, and being an everyday desktop Linux user recently, it's hard to square these kinds of complaints with the actual technical situation. Like, people say X11 is network transparent but that's not in practice true. People argue the same problems could be solved in X11, but in practice despite a decade + of complaining about Wayland nobody did the work make the improvements to X. Unlike say the systemd situation Wayland just seems like a better and necessary 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? | | |
| ▲ | adrian_b 12 hours ago | parent [-] | | X11 is in practice network transparent. 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. | | |
| ▲ | hedgehog 11 hours ago | parent [-] | | In practice for some applications, for my purposes X11 forwarding never really worked (due to GLX and bandwidth among other issues). So that's 50/50 anecdote. I just checked and it appears Wayland adoption has helped push apps to adopt EGL which helps. There are tradeoffs both ways but let's not pretend X11 is adequate for everyone or every application. Subjectively, when I use Gnome now it's by far better than any version of desktop Linux I used a decade or two ago. |
|
| |
| ▲ | vasvir 11 hours ago | parent | prev [-] | | In the same sense windows are not network transparent when in fact RDP works perfectly, certainly much better that X11 over WAN. Actually for wayland there is wprs for remote display of apps so here it goes the network transparency argument... |
|
|
|
|
|
| |
| ▲ | mato 17 hours ago | parent | prev [-] | | I used to program pure Xlib when I was 13 or so. I don't think the then-13-year-old me would manage pure Wayland. | | |
| ▲ | atomicnumber3 17 hours ago | parent | next [-] | | 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. | | |
| ▲ | adrian_b 16 hours ago | parent [-] | | HiDPI has always been perfectly supported by X11. 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. | | |
| ▲ | izacus 15 hours ago | parent [-] | | 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. | | |
| ▲ | adrian_b 15 hours ago | parent [-] | | 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. |
|
|
| |
| ▲ | silon42 16 hours ago | parent | prev [-] | | You underestimate youself as a 13 year old... if you had to, you'd do it (given time). |
|
|
| |
| ▲ | zabzonk 16 hours ago | parent [-] | | To create a simple window, no it isn't. To create a rather complex application, then yes it is, compared with using a higher-level framework. | | |
| ▲ | modeless 16 hours ago | parent [-] | | 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. | | |
| ▲ | seba_dos1 16 hours ago | parent [-] | | 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. | | |
| ▲ | Joker_vD 14 hours ago | parent [-] | | > 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: #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);
}
}
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. | | |
| ▲ | seba_dos1 13 hours ago | parent [-] | | 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. |
|
|
|
|
|
