3 ms·

>Wayland, on the other hand, is just a compositor. Wayland is _just_ a protocol. There a multiple compositors (GNOME, KDE, Weston, Sway, etc) implementing the

>Wayland, on the other hand, is just a compositor. Wayland is _just_ a protocol. There a multiple compositors (GNOME, KDE, Weston, Sway, etc) implementing the protocol differently. >I'm sad because X is fun to figure out. I'm currently implementing the drag-and-drop protocol in our Xwayland WM [1]. Trust me, this is far from being fun. Very far, it's not even funny. >I can make a WinAPI app in C that opens a window in a few KB, where as to do that in Linux now I HAVE to support XCB and also write my own tiny UI for Wayland. Sticking to broken old standards is not going to be the solution. We have to move forward. There are many embarrassing things in X11 -- Wayland gives us an opportunity to start from scratch. [1]: https://github.com/swaywm/wlroots/pull/841 https://github.com/swaywm/wlroots/pull/841

exikyut 8y ago
> There a multiple compositors (GNOME, KDE, Weston, Sway, etc) implementing the protocol differently. Genuine question. How can I run a mixed environment, then? I can mix and match Qt and GTK apps without any thought in X, and furthermore, I can run Metacity with Plasma, or KWin with one or more gnome-panel instances. (If the processes are still named like that... it's been a while, heh.) Yes, in practice, I will admit I wouldn't probably do that, but the kind of flexibility - that expansive upper bound - is what lets me also go to the other end of the extreme and set up a lightweight environment that does function exactly the way I'd like it to. I'm a bit scared of "implementing the protocol differently." Meep. How differently? After having read a bit, I see that Wayland is standardized, but still - how well will things interact, in the worst case scenario? With X, it's "...ooookay, so my dock has decided to acquire a titlebar, and I can resize and move it around the screen. This is... nice?" - but with Wayland, would things not appear on the screen at all, for example, or would my session [choices] be genuinely unusable [together] at all? > Sticking to broken old standards is not going to be the solution. We have to move forward. There are many embarrassing things in X11 -- Wayland gives us an opportunity to start from scratch. Pragmatically - not nostalgically speaking - I do completely agree. I actually just stumbled on https://blogs.igalia.com/dape/2018/03/21/updated-chromium-legacy-wayland-support/ https://blogs.igalia.com/dape/2018/03/21/updated-chromium-le... and learned that Wayland has been running webOS in LG TVs for the past 4 years. That's truly impressive, I didn't know that. I'm really impressed that Chromium and Firefox both support Wayland now, not to mention GTK and Qt. It's going to be interesting to see how things go over the next few years. > I'm currently implementing the drag-and-drop protocol in our Xwayland WM [1]. Trust me, this is far from being fun. Very far, it's not even funny. I see. I had a look at some of the linked issues. It doesn't look particularly fun, yeah. It's very important work though, very cool. I also just discovered what wlroots actually is, which looks rather interesting too. Something I know will need to exist at some point is the Wayland equivalent of Xvnc, aka a headless display surface that "displays" solely via VNC. This would be a good building block for that. Poking around has helped me understand the Wayland model a bit better, thanks. -- One question that immediately comes to mind about Wayland is how well I could "warp" Wayland clients from one backend to another (within the unbroken constraint that both backends remain on the same machine), without closing/destroying the client first. The purpose being a) to move windows between isolated/disparate video heads (should be achievable with a compositor.....), b) to move clients between an actual video output and eg an Xvnc-style headless backend, and c) to restart the compositor or upgrade the video driver (in some future world where graphics drivers are livepatch-aware), without a session restart. This would probably be viably implementable with a thin proxy layer (which does 0.1% protocol decoding, passing the rest through transparently - perhaps even via a SHM LFQ or similar). Implementing this proxy, and adding some things to the spec that momentarily "puts clients to sleep" to avoid difficult side effects with queued instructions, could be interesting.

exikyut 8y ago

> There a multiple compositors (GNOME, KDE, Weston, Sway, etc) implementing the protocol differently. Genuine question. How can I run a mixed environment, then? I can mix and match Qt and GTK apps without any thought in X, and furthermore, I can run Metacity with Plasma, or KWin with one or more gnome-panel instances. (If the processes are still named like that... it's been a while, heh.) Yes, in practice, I will admit I wouldn't probably do that, but the kind of flexibility - that expansive upper bound - is what lets me also go to the other end of the extreme and set up a lightweight environment that does function exactly the way I'd like it to. I'm a bit scared of "implementing the protocol differently." Meep. How differently? After having read a bit, I see that Wayland is standardized, but still - how well will things interact, in the worst case scenario? With X, it's "...ooookay, so my dock has decided to acquire a titlebar, and I can resize and move it around the screen. This is... nice?" - but with Wayland, would things not appear on the screen at all, for example, or would my session [choices] be genuinely unusable [together] at all? > Sticking to broken old standards is not going to be the solution. We have to move forward. There are many embarrassing things in X11 -- Wayland gives us an opportunity to start from scratch. Pragmatically - not nostalgically speaking - I do completely agree. I actually just stumbled on https://blogs.igalia.com/dape/2018/03/21/updated-chromium-legacy-wayland-support/ https://blogs.igalia.com/dape/2018/03/21/updated-chromium-le... and learned that Wayland has been running webOS in LG TVs for the past 4 years. That's truly impressive, I didn't know that. I'm really impressed that Chromium and Firefox both support Wayland now, not to mention GTK and Qt. It's going to be interesting to see how things go over the next few years. > I'm currently implementing the drag-and-drop protocol in our Xwayland WM [1]. Trust me, this is far from being fun. Very far, it's not even funny. I see. I had a look at some of the linked issues. It doesn't look particularly fun, yeah. It's very important work though, very cool. I also just discovered what wlroots actually is, which looks rather interesting too. Something I know will need to exist at some point is the Wayland equivalent of Xvnc, aka a headless display surface that "displays" solely via VNC. This would be a good building block for that. Poking around has helped me understand the Wayland model a bit better, thanks. -- One question that immediately comes to mind about Wayland is how well I could "warp" Wayland clients from one backend to another (within the unbroken constraint that both backends remain on the same machine), without closing/destroying the client first. The purpose being a) to move windows between isolated/disparate video heads (should be achievable with a compositor.....), b) to move clients between an actual video output and eg an Xvnc-style headless backend, and c) to restart the compositor or upgrade the video driver (in some future world where graphics drivers are livepatch-aware), without a session restart. This would probably be viably implementable with a thin proxy layer (which does 0.1% protocol decoding, passing the rest through transparently - perhaps even via a SHM LFQ or similar). Implementing this proxy, and adding some things to the spec that momentarily "puts clients to sleep" to avoid difficult side effects with queued instructions, could be interesting.