Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Wayland is close to macOS windowing, just like systemd is close to launchd. That’s how open source can approach the competence of macOS, or Windows for that matter.


sort by: page size:

It would be easier to bring the features to Linux than MacOS as MacOS lacks modern APIs for things like graphics rendering and kernel support for containerisation.

I thought about it, writing a DE targeting Wayland replicating MacOS. There are lots of considerations though, like how to ensure apps written with QT or GTK would render correctly, put their menu in the right place and all that.

I am wholly unqualified for such a task, though I have the enthusiasm for it.


It's done by the window manager, which is integrated directly into Wayland. The tight coupling of the two is a semi-contentious issue.

Wayland, and the entire Linux Window manager situation seems like a massive mess from the pov of an outsider, a widely used, stable and open-source app that can bypass this unnecessary complexity could be a great example for other apps to follow

What OS? I do this in Linux and X11, but was unable to figure out Wayland. Also, macOS was no joy for me.

Do you even know anything about the Wayland design?

Wayland is more about just getting surfaces from A => B and management of those surfaces, it doesn't really do anything shockingly different from how something like macOS does it.


An X window manager would likely have to be completely rewritten to work on Wayland, I doubt many of them have much abstraction of the underlying window system.

The issue I have with wayland is that it just continues to fragment the Linux desktop ecosystem, and it moved things to the toolkit that just don’t make sense there: I don’t want my window decorations to depend on whether the app is built with Qt or Gtk. I don’t want projects like McClim ( https://common-lisp.net/project/mcclim/ ) to depend on C code to communicate with the windowing system, etc.

Wayland is a protocol specifically for compositing window managers, the point of it was to simplify the implementation of window managers that already existed as X compositors, e.g. Mutter, KWin, Enlightenment. If other window managers weren't doing that then it wouldn't really make sense to port them to Wayland, because that entails also redesigning them as a compositor. I know many older X window managers never bothered to implement a compositor and just recommended people use compiz, compton, picom, etc.

Someone could build a compatibility layer based on picom or something, and that has been talked about for a while, but I don't think it will happen unless somebody funds it with some real dollars.


A number of people dislike Wayland because applications can't watch the screen, keyboard input, clipboard etc outside of their own window. Really, that's one of its great strengths over X11.

Right, but at least as far as I know, currently a window manager trying to do compositing in Linux has to fight with X11 to achieve that, because it was not really designed to support that use case. Which is why Wayland is getting traction I guess.

It's perfectly possible to have that with something like the X window system. The irony is that this protocol gives applications way too many capabilities. But Wayland is a chance to fix that for good and finally have proper compartmentalisation in the GUI.

Wayland has a massive loss in functionality (in the name of "security" and off-loading implementation details to compositors/window managers) compared to X11 though.

Stuff like xdotool, screen sharing, clipboard sharing, etc. is much harder.


A wayland window manager.

Wayland is not a program, it's a protocol, so there is no way it could depend on systemd. Some compositors may choose to, some compositors may choose not to.

For being written in 2019, I am surprised that the article had no mention of the existence of Wayland. On my systems I have already moved off of Xorg onto Sway¹ as my compositor and window manager and have no intention of going back. Sway has a great programability via it's own swaymsg IPC protocol that allows me to do all the manipulations that I would care to do, and even works on my dual-paned HiDPI 5K monitor.

¹ https://swaywm.org


Having tried to write a window manager for X, I am always impressed by anyone who has enough followthrough to actually finish one. And I'm very eager to see if Wayland has a nicer and more sane API than X.

Isn't one of the most popular Wayland clients a window manager? I'm confused.

Sounds good! I just checked around a little bit and the only program I really would like to have wayland support is vscode and that seems to be around the corner. So I will wait for that and then try it out.

Thanks for explaining!


there's no fundamental design flaw in Wayland

Except that window management is tightly coupled to display management.

The Mir developers seem to at least seem to care about software modularity.

next

Legal | privacy