Live data from Hacker News

I hate: Programming Wayland applications

p4m.dev

151–160 of 184 posts

Re: I hate: Programming Wayland applications

#151

Earlier quoted context omitted.

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.

You can’t effectively dismiss a critique of something missing from the core protocol by declaring it to not be its concern.

Why should a display manager concern itself with routing keystrokes to every application.

Re: I hate: Programming Wayland applications

#152

Earlier quoted context omitted.

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.

You can’t effectively dismiss a critique of something missing from the core protocol by declaring it to not be its concern.

I can, I just did. It's just not a thing that should be there at all, and it's obvious once you take a second to look at what's actually in it and why (spoiler: there's too much in it and not much can be done about it now).

Re: I hate: Programming Wayland applications

#153
post #70

Earlier quoted context omitted.

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.

Imagine you wrote an application that supports global, unfocused keybinds (OBS is one popular example). Instead of implementing it one way that works forever with any WM/DE (X11), now you must rely on each individual wayland compositor to implement one or more optional extensions correctly, and constantly deal with bug reports of people that are using unsupported or broken compositors.

Or you could write portable software that doesn't rely on reading global input. OBS you give as an example, and it is a good one. They could simply register a D-Bus handler and provide a second binary that sends messages to the running instance. The software is more general in this way as it allows full programmatic control. A Sway user, for instance, could add

  bindsym $mod+r exec obs-control toggle-recording
to their configuration. What's more, they can do this in response to other system events. A user might wish to change the recording configuration of OBS in response to an application opening, and it now becomes possible to write a script which opens the application and applies the change.

If your disdain for desktop isolation is so great, you needn't even use D-Bus. Registering a simple UNIX socket that accepts commands would work equally well in this case.

What's really desired here is a standard way for programs to expose user-facing commands to the system, which is clearly not within the scope of the specification for a display server. The problem with X11 is that it has for a long time exposed too much unrelated functionality like this to the user, and so many apps have become reliant on this and developers have neglected the creation of portable ways to achieve these objectives. A new specification for display servers that excludes this harmful behaviour is a clear long-term positive.

Re: I hate: Programming Wayland applications

#154

Earlier quoted context omitted.

You can’t effectively dismiss a critique of something missing from the core protocol by declaring it to not be its concern.

Why should a display manager concern itself with routing keystrokes to every application.

Why should a display manager also have to implement window management? (I know this is a separate complaint, but I still think it's a valid one.)

Re: I hate: Programming Wayland applications

#155

I have no love lost for Wayland, but this: > Make easy things easy. Make hard things doable. is generally unachievable. Instead, pick one: - easy things easy, hard things impossible - easy things tedious, hard things possible (Unless you want to maintain two sets of interfaces in parallel.)

Yeah, obviously you have multiple levels of public interfaces, like how CreateWindow calls CreateWindowEx under the hood.

Do people recommend the API surface should be totally flat and the same for all developers?

Re: I hate: Programming Wayland applications

#157
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…

> No, nothing deserves this constant whining and crying day in and day out.

Why even try an start a conversation with that attitude? Wayland doesn't get nearly as much hate as Windows, Chrome, or iOS. But I guess literally nothing is worth writing an article that has the word "fuck" in it 7 times, because that crosses some kind of ultimate line?

Re: I hate: Programming Wayland applications

#160

Earlier quoted context omitted.

Imagine you wrote an application that supports global, unfocused keybinds (OBS is one popular example). Instead of implementing it one way that works forever with any WM/DE (X11), now you must rely on each individual wayland compositor to implement one or more optional extensions correctly, and constantly deal with bug reports of people that are using unsupported or broken compositors.

Or you could write portable software that doesn't rely on reading global input. OBS you give as an example, and it is a good one. They could simply register a D-Bus handler and provide a second binary that sends messages to the running instance. The software is more general in this way as it allows full programmatic control. A Sway user, for instance, could add bindsym $mod+r exec obs-control toggle-recording to thei…

I'm not sure how any of that sidesteps the point of my comment, which was having to rely on many different wayland compositors all implementing hotkeys properly.

I don't think it's always practical or desired to move the hotkey support completely out of the program itself. Most users (especially consumer/nontechnical people such as many OBS users) are not willing to setup hotkeys through a third-party program to manually get it to control OBS externally... so I think it needs to support hotkeys internally, whether there is also control possible via an external socket/dbus/etc. or not.

Post reply on HN