Live data from Hacker News

I hate: Programming Wayland applications

p4m.dev

51–60 of 184 posts

Re: I hate: Programming Wayland applications

#51
post #19
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...

He complained there is no way to do the easy thing in Wayland - there is a way: Gtk and QT

...which is overkill when you only need a Vulkan or GL canvas which spans the windows client area... and even with GTK or Qt your app still stands out like a sore thumb on the "other" desktop environment because the window chrome doesn't match the rest of the system.

Re: I hate: Programming Wayland applications

#52
post #40
post #8

Earlier quoted context omitted.

It is a damn shame that tools like xdotool (automation) and sxhkd (global keybinds) are impossible to recreate under Wayland.

I'm using Sway right now and I have key binds. Not sure why you think that's impossible.

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.

Re: I hate: Programming Wayland applications

#54
post #16

The constant loud bile spewing over Wayland and systemd just won't stop here, will it? It's getting a bit boring, especially since none really does more than complain.

Especially systemd. Declarative management of services is a bad thing? Some people just wanna complain

Systemd sucks though for good reasons.

Re: I hate: Programming Wayland applications

#55
post #8
post #3

Wayland was designed from the point of view of theoretical purists. It's basically "how would a display server work in an ideal world", unfortunately, that design turns out to also be impractical and straight up developer/user hostile.

It is a damn shame that tools like xdotool (automation) and sxhkd (global keybinds) are impossible to recreate under Wayland.

Not only that. A11y is also quite hard. Tools that are simple to implement thanks to good a11y apis - for example on macos, the tool rcmd or homerow - are super hard to do in Wayland.

Re: I hate: Programming Wayland applications

#56
post #4

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.

Here is how to get Win32 up and running: https://learn.microsoft.com/en-us/windows/win32/learnwin32/y...

It's absolutely trivial in comparison. Same thing with Xlib; < 100 lines of C code is enough for a simple app.

Re: I hate: Programming Wayland applications

#57
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.

Well kind of. It'll be several decades before we see any practical benefits - at the moment once you have local execution you can do anything you want - accessing other apps or even root is trivial.

Re: I hate: Programming Wayland applications

#58
post #33

Earlier quoted context omitted.

A security disaster? Howso?

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.

> Defeats the point of sandboxing

Sandboxing defeats the point of said applications. If you want your computer to have no functionality, check out Figma. A clickable prototype sounds like precisely the security the world needs right now.

Re: I hate: Programming Wayland applications

#60
post #37

Reminds me somewhat of Vulkan. I think the trend of making the actual specification of something lower level and less convenient is rather logical. Why burden implements with a load of convenience functions when that could be left up to libraries?

> when that could be left up to libraries?

Because those libraries will not materialize in time, and more importantly the hobbyists who are supposed to write those libraries don't have the testing capabilities of large organizations (e.g. testing across hundreds of hardware configurations).

Post reply on HN