Live data from Hacker News

I hate: Programming Wayland applications

p4m.dev

111–120 of 184 posts

Re: I hate: Programming Wayland applications

#111

Earlier quoted context omitted.

> Not impossible, it just needs to be implemented at a different layer. The compositor needs to expose some API for global hotkeys. That's a big problem . When things become an optional extension for a compositor, that means you cannot reliably deploy something that depends on it to Wayland. At this moment, things in the wild are coupling themselves to libwayland-client and in practice ossifying its ABI as a standard…

xdg-shell is an optional extension for a compositor and yet you can reliably deploy things that depend on it. You're barking at the wrong tree.

OK so why wasn't this implemented in the first place? For that matter, why does our reinvented wheel have fundamental limitations?

Re: I hate: Programming Wayland applications

#112
post #70
post #52

Earlier quoted context omitted.

Th point is the decoupling. sxkhd runs irrespective of wm and means your en can optionally choose not to handle key bindings at all. With Wayland you end up depending on whether or not and how your compositor supports it.

How many keybings do you have and how often do you try new window managers? Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.

> Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.

Those aren't the only two options. There's no need to compromise the entire system for everybody if the Wayland devs would agree to configuration that controls these things.

Then those of us who need stuff to work rgardless of WM would get stuff to work and the rest of the Wayland users can simply go with a WM that suits them.

Re: I hate: Programming Wayland applications

#113
post #33

Earlier quoted context omitted.

Letting any GUI application capture all input and take full control of the desktop completely defeats the point of sandboxing and X11 does exactly that.

Yawn, X11 (and similar "unsecure" desktop environments) existed for half a century and the sky hasn't fallen. I'm tired of that "will somebody think of the children/grandparents" scare mongering.

It hasn't, but Windows has had its fair share of keyloggers, RATs, and so on, and I think we can all agree that anti-virus software is an inherently flawed concept.

The only thing keeping those away from Linux was its market share. With npm malware on the rise, this is no longer enough of a protection.

Re: I hate: Programming Wayland applications

#114
post #23
post #17

I have used quite a bit of Gtk and QT, and have had to touch X11 or Wayland very little directly, EXCEPT for one case where I wanted to provide a global hotkey...

Which is kind of understandable as Wayland tries to be more secure: and thus in Wayland not all keyboard events are propagated to all applications (that's what X11 does). I think it's a good idea to put security first in this iteration of FLOSS desktop technology.

Phoenix[0] has some good ideas about how X11 could be made more secure without breaking backwards compatibility. I don't understand what was so fundamentally broken about X11 as a protocol that it required a replacement protocol.

We can argue about limitations of X.org's implementation of the X server, but, as demonstrated by Phoenix, X.org doesn't have to be the only X server implementation.

[0]: https://git.dec05eba.com/phoenix

Re: I hate: Programming Wayland applications

#115
post #100

Earlier quoted context omitted.

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 w…

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.

Re: I hate: Programming Wayland applications

#116

Earlier quoted context omitted.

xdg-shell is an optional extension for a compositor and yet you can reliably deploy things that depend on it. You're barking at the wrong tree.

OK so why wasn't this implemented in the first place? For that matter, why does our reinvented wheel have fundamental limitations?

It's not a core protocol's concern and the fact that it's being successfully implemented proves that there are no fundamental limitations there.

I'm not happy with how the collaboration and planning between various parties involved went over years and I do believe that a lot of these adoption pains are fully self-inflicted, but that has absolutely nothing to do with Wayland's technical design.

Re: I hate: Programming Wayland applications

#117
post #98

Earlier quoted context omitted.

Tbh, 1300 lines of extremely cursed code to open a frigging window and GL context deserves that bile. Such a fundamental problem is also nothing that can be fixed through contributions except discarding the whole clusterfuck and starting over from scratch.

No, nothing deserves this constant whining and crying day in and day out. Especially coming from people who don't put in the work to build something else. It's really bizarre how the opensource community degraded into this space of constant aggresive, insulting screeching over every single project thats actually moving something in the Linux world. Coming from people who don't put any code behind it or do anything bu…

Tbh, it's quite delusional to think that a better alternative solution would win that's not backed by Redhat and GNOME. In a purely competitive environment, a design like Wayland could never have "won" as an X11 replacement, it was pushed long enough until it was "too big to fail".

Re: I hate: Programming Wayland applications

#119
post #23

Earlier quoted context omitted.

Which is kind of understandable as Wayland tries to be more secure: and thus in Wayland not all keyboard events are propagated to all applications (that's what X11 does). I think it's a good idea to put security first in this iteration of FLOSS desktop technology.

Phoenix[0] has some good ideas about how X11 could be made more secure without breaking backwards compatibility. I don't understand what was so fundamentally broken about X11 as a protocol that it required a replacement protocol. We can argue about limitations of X.org's implementation of the X server, but, as demonstrated by Phoenix, X.org doesn't have to be the only X server implementation. [0]: https://git.dec05eb…

I have no idea, but my impression was that basically nobody wanted to put in work on X11 anymore.

Re: I hate: Programming Wayland applications

#120

Earlier quoted context omitted.

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…

> 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 
    
    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.
Post reply on HN