Linux

45551 readers

1750 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
No misinformation
No NSFW content
No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago

MODERATORS

[email protected]

251

KDE's Nate Graham On X11 Being A Bad Platform & The Wayland Future (www.phoronix.com)

submitted 6 months ago by [email protected] to c/[email protected]

181 comments fedilink hide all child comments

Well known KDE developer Nate Graham is out with a blog post today outlining his latest Wayland thoughts, how X11 is a bad platform, and the recent topic of "Wayland breaking everything" isn't really accurate.

"In this context, “breaking everything” is another perhaps less accurate way of saying “not everything is fully ported yet”. This porting is necessary because Wayland is designed to target a future that doesn’t include 100% drop-in compatibility with everything we did in the past, because it turns out that a lot of those things don’t make sense anymore. For the ones that do, a compatibility layer (XWayland) is already provided, and anything needing deeper system integration generally has a path forward (Portals and Wayland protocols and PipeWire) or is being actively worked on. It’s all happening!"

Nate's Original Blog Post

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 9 points 6 months ago* (last edited 6 months ago) (1 children)

That's my problem with this. It tries to be a desktop display server protocol without unifying all desktop requirements. Sure, X11 is old and have unnecessary things that aren't relevant anymore, however, as someone who builds their own DE, (e.g.: tiling window managers) I see it as the end of this masterrace. Unless everybody moves to wlroots. Flameshot, for example, is already dealing with this, having at least 5 implementations only for linux, and only wlroots and x11 are standards.

Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE. But as you said DEs can implement it simply. Let's say wlroots will implement this but others can decide otherwise. And for those the app won't run.

Another example, that affects my app personally, is the ability to query which monitor is the pointer at. Wayland doesn't care having these so I doesn't care supporting wayland. And I"m being sad about this because X is slowly fading away so new apps will not run on my desktop.

Moreover with X11 I could write my own hotkey daemon in my lanuage of choice, now I would have to fork the compositor.

Do I see it wrong?

[–] [email protected] 2 points 6 months ago

Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE.

The wayland way to do that is to have the application be a compositor, they made sure that nesting introduces only minimal overhead. And that ties in with the base protocol being so simple: If you only need to deal with talking to the compositor you're running on, and to the client that you want to embed, a wayland compositor is indeed very small and lean. Much of the codebase in the big compositors deals with kms, multiple monitor support, complex windowing logic that you don't need, etc.

Oh and just for the record that doesn't mean that you can't undock the terminal: Just ask the compositor you're running on for a second window and compose it there. You can in principle even reparent (client disconnecting from one compositor and connecting to the other) but I think that's only standardised for the crash case there's no standard protocol to ask a client to connect to another compositor. Just need to standardise the negotiation protocol, not the mechanism.