In a few months/years I expect gaming on linux to be more performant than windows on both nvidia and amd for about.most games. cause both nvidia and winee are taking steps to support nvidia better and I have heard that wine wayland already runs faster than wine on native X11
As someone who has written client code targetting X11, it’s indeed quite unfortunate that, to properly target Wayland, it’d need to all be replaced, but… good riddance. Working with X11 was fucking hell. X11 has so much broken/unreasonable garbage in, like, most places. Working with X11 has been, by far, my programming worst experience.
This is not to say that Wayland is automatically better at everything (I haven’t looked into it much, and the server-side decoration problem is indeed a problem) but it’d be damn hard to be worse than X11 or be anywhere close to it.
Yeah, I’ve seen libdecor as a solution, but it still feels quite off to have pretty much every wayland client have a whole dependency for such a trivial thing.
Yes, the client is supposed to manage the client content, but the obvious question then is whether the window decorations are part of its content. In some cases (stuff merged into the decorations) it can definitely be the case, but, for most things I’d say the decorations are as much a part of the client content as the apps entry in the taskbar (both contain the title of the app, potentially the icon, options to close/maximize/minimize). The only difference is that decorations always appear immediately above a window, but even that isn’t really a fundamental part.
I have noticed that one of the groups that does not seem to be complaining about Wayland are the toolkit folks. GTK added support back in GTK3. Qt added it. Enlightenment added it. They must have jumped on it for a reason.
When you look at the Wayland readiness docs for things like XFCE, it stands out that all the apps are already ready ( because they are GTK based in this case ).
Looked into some more things, and… base wayland does seem to continue the trend of “lol no not allowing you to do a basic thing, because surely noone has a good reason to” more - no custom positioning of windows (remembering custom window positions on reopen, window moving segments of Rhythm doctor), cursor wrapping (amazing to use in blender, wish more things did it, it feels so much better to use than the cursor being temporarily frozen in place or moving freely through everything).
At least there’s still the chance for extensions (wayland.app/…/pointer-constraints-unstable-v1 plus wayland.app/…/relative-pointer-unstable-v1 I think provide the ability to set the cursor position on wrapping and have that not interrupt the stream of relative position changes) but with things not being in base wayland it means that apps can’t just assume basic features on linux wayland which they can everywhere else (windows, mac, X11) unless they just choose to ignore hypothetical WMs which refuse to implement them.
I believe I also have a situation where ydotool wouldn’t be sufficient too - namely, having scrcpy open in the background and sending it keypresses to play/pause/change volume of the content on my phone from global keypresses (which trigger a shell script that chooses to either forward the presses to scrcpy, or if it’s not open, do some hacks to do what they would have done if not intercepted).
I use xmonad as my main WM, so Hyprland would be a very easy transition. I would have switched by now but I just love Haskell
so much.
I’m not talented enough to port Hyprland to Haskell (at least the configuration aspect) but I wish someone wanted to do that. What I like about xmonad is that its core is actually formally verified.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.