# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 46
# self = https://watcher.sour.is/conv/kans6va
Meddling with Wayland (Sway) again.
- Pointer barriers don’t work. Each compositor has to implement this feature on its own. Sway doesn’t.
- My multipass won’t work anymore. Has to be implemented in the compositor. I use this almost daily.
- Couldn’t find a way (yet) to set the “app ID” from GTK3. When running a GTK3 program under Wayland, wmclass and wmname are simply ignored. This means I cannot write assign rules for my terminal at the moment. Would have to switch to another terminal (or port to GTK4?).
- No shared clipboard between XWayland programs (of which there are a lot) and Wayland.
- redshift. Each compositor has to implement this on its own.
In general, the old model of “programs that work together” is gone on Wayland because of security reasons. I can understand the reasoning behind this. Downside is that each compositor has to implement everything and the kitchen sink now. (If I were to write my own Wayland compositor, it would be an unbelievably huge amount of work.) I’m not convinced that this is a good model. The Sway guys are duplicating all the efforts of the GNOME guys and the KDE guys (and that’s basically it, because all the other compositors are toys – because it’s so much harder to write a compositor than an X11 window manager, only larger projects can afford that).
I’m trying to stay positive and optimistic. But it’s hard. Wayland does not have a “killer feature”, at least none that I can see. Why would I *want* to switch?
This situation reminds me of switching from Windows to Linux. For a long time, I was complaining that Linux couldn’t do this or that, so I staid on Windows. Eventually, I saw the *advantages* of using Linux, so switching became much easier and I was willing to make sacrifices. Same thing when I switched my servers from Linux to OpenBSD. With Wayland, I haven’t reached this point yet. All I see is obstacles and disadvantages.
I’ll keep looking for reasons to switch to Wayland … As soon as I find a good reason, it’ll be fine.
My favorite quote on this topic by Benno Rice: https://movq.de/v/06189654e5/benno-rice-change.ogg
Meddling with Wayland (Sway) again.
- Pointer barriers don’t work. Each compositor has to implement this feature on its own. Sway doesn’t.
- My multipass won’t work anymore. Has to be implemented in the compositor. I use this almost daily.
- Couldn’t find a way (yet) to set the “app ID” from GTK3. When running a GTK3 program under Wayland, wmclass and wmname are simply ignored. This means I cannot write assign rules for my terminal at the moment. Would have to switch to another terminal (or port to GTK4?).
- No shared clipboard between XWayland programs (of which there are a lot) and Wayland.
- redshift. Each compositor has to implement this on its own.
In general, the old model of “programs that work together” is gone on Wayland because of security reasons. I can understand the reasoning behind this. Downside is that each compositor has to implement everything and the kitchen sink now. (If I were to write my own Wayland compositor, it would be an unbelievably huge amount of work.) I’m not convinced that this is a good model. The Sway guys are duplicating all the efforts of the GNOME guys and the KDE guys (and that’s basically it, because all the other compositors are toys – because it’s so much harder to write a compositor than an X11 window manager, only larger projects can afford that).
I’m trying to stay positive and optimistic. But it’s hard. Wayland does not have a “killer feature”, at least none that I can see. Why would I *want* to switch?
This situation reminds me of switching from Windows to Linux. For a long time, I was complaining that Linux couldn’t do this or that, so I staid on Windows. Eventually, I saw the *advantages* of using Linux, so switching became much easier and I was willing to make sacrifices. Same thing when I switched my servers from Linux to OpenBSD. With Wayland, I haven’t reached this point yet. All I see is obstacles and disadvantages.
I’ll keep looking for reasons to switch to Wayland … As soon as I find a good reason, it’ll be fine.
My favorite quote on this topic by Benno Rice: https://movq.de/v/06189654e5/benno-rice-change.ogg
Meddling with Wayland (Sway) again.
- Pointer barriers don’t work. Each compositor has to implement this feature on its own. Sway doesn’t.
- My multipass won’t work anymore. Has to be implemented in the compositor. I use this almost daily.
- Couldn’t find a way (yet) to set the “app ID” from GTK3. When running a GTK3 program under Wayland, wmclass and wmname are simply ignored. This means I cannot write assign rules for my terminal at the moment. Would have to switch to another terminal (or port to GTK4?).
- No shared clipboard between XWayland programs (of which there are a lot) and Wayland.
- redshift. Each compositor has to implement this on its own.
In general, the old model of “programs that work together” is gone on Wayland because of security reasons. I can understand the reasoning behind this. Downside is that each compositor has to implement everything and the kitchen sink now. (If I were to write my own Wayland compositor, it would be an unbelievably huge amount of work.) I’m not convinced that this is a good model. The Sway guys are duplicating all the efforts of the GNOME guys and the KDE guys (and that’s basically it, because all the other compositors are toys – because it’s so much harder to write a compositor than an X11 window manager, only larger projects can afford that).
I’m trying to stay positive and optimistic. But it’s hard. Wayland does not have a “killer feature”, at least none that I can see. Why would I *want* to switch?
This situation reminds me of switching from Windows to Linux. For a long time, I was complaining that Linux couldn’t do this or that, so I staid on Windows. Eventually, I saw the *advantages* of using Linux, so switching became much easier and I was willing to make sacrifices. Same thing when I switched my servers from Linux to OpenBSD. With Wayland, I haven’t reached this point yet. All I see is obstacles and disadvantages.
I’ll keep looking for reasons to switch to Wayland … As soon as I find a good reason, it’ll be fine.
My favorite quote on this topic by Benno Rice: https://movq.de/v/06189654e5/benno-rice-change.ogg
Also, I’m really curious: Will X servers actually die? Or will we end up with both X11 and Wayland? I’m aware that there are no devs anymore developing X.Org, because they all moved to developing Wayland (in a nutshell). But maybe others will step up? Will someone write a new X server eventually without all the historical cruft?
I really don’t know. Nobody is doing any of that at the moment because X.Org still works. What will happen if it doesn’t anymore?
Also, I’m really curious: Will X servers actually die? Or will we end up with both X11 and Wayland? I’m aware that there are no devs anymore developing X.Org, because they all moved to developing Wayland (in a nutshell). But maybe others will step up? Will someone write a new X server eventually without all the historical cruft?
I really don’t know. Nobody is doing any of that at the moment because X.Org still works. What will happen if it doesn’t anymore?
Also, I’m really curious: Will X servers actually die? Or will we end up with both X11 and Wayland? I’m aware that there are no devs anymore developing X.Org, because they all moved to developing Wayland (in a nutshell). But maybe others will step up? Will someone write a new X server eventually without all the historical cruft?
I really don’t know. Nobody is doing any of that at the moment because X.Org still works. What will happen if it doesn’t anymore?
Also, I’m really curious: Will X servers actually die? Or will we end up with both X11 and Wayland? I’m aware that there are no devs anymore developing X.Org, because they all moved to developing Wayland (in a nutshell). But maybe others will step up? Will someone write a new X server eventually without all the historical cruft?
I really don’t know. Nobody is doing any of that at the moment because X.Org still works. What will happen if it doesn’t anymore?
@movq Hmm, how do pointer barriers work? How do you switch to another screen then? At one point, you just have to, don't you?
What's your use case to send keyboard events to an asortment of windows? I never did that and can't see when that would be useful. But I'm sure there are lots of applications out there for that.
If I want a fucked up clipboard, I can also simply use a VM… Oh dear, this is a total killer. So Wayland is absolutely worthless to me.
I never tried Wayland myself. Nor did I do any research on that matter. From all you said and I heard from other mates, let me answer your question why you want to switch: You don't. :-) This model really sounds totally insane. It feels like it's heavily contradicting KISS at all possible levels. Complicating everthing at basically no gain. Security is all good and nice, but if you can't do basic things anymore, then that's the opposite of progress or even a working system. I fear it's going to be the same with systemd and System V Init. Eventually everybody is forced to switch over. But not now. Hopefully, by then some things are sorted out and even simplified. Hope dies last, but it dies.
Very nice quote, I completely agree! :-D
@movq As far as I can tell, the duplicated effort is lessened by using an intermediate library like wlroots.
> Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.
I agree; the lack of hackability in Wayland is very unfortunate.
@lyse
> Hmm, how do pointer barriers work? How do you switch to another screen then? At one point, you just have to, don't you?
My xpointerbarrier is very simple: It creates a *static* barrier. To switch to another screen, I press a hotkey. But they can be implemented differently, for example you might have to “push” the pointer over the barrier or you might have to hit it at a certain speed or something like that. I didn’t need anything like that, though.
> What's your use case to send keyboard events to an asortment of windows?
Mainly typing the same thing into multiple SSH sessions. For example, I edited the same zone file on both of our DNS servers at work today.
(Blog post about multipass)
multipass is not a *must have* for me – tmux has that feature, too, as well as some terminal emulators. But all those other solutions require *thinking ahead*, whereas with multipass I can just combine any windows that I like *at any time*. (Or maybe it is possible with tmux as well, by moving panes around like crazy, which I imagine is quite cumbersome.)
> If I want a fucked up clipboard […]
I couldn’t be bothered to investigate this. Just found these two links with some more info:
- https://blog.martin-graesslin.com/blog/2016/07/synchronizing-the-x11-and-wayland-clipboard/
- https://www.reddit.com/r/swaywm/comments/rv668l/yet_another_clipboard_thread_x11_sync_wayland_and/
So it’s a nice example of “has been solved in KDE, but not in Sway”.
> Complicating everthing at basically no gain. Security is all good and nice, but if you can't do basic things anymore, then that's the opposite of progress or even a working system.
I’m pretty sure that you can get to a working system, you just have be willing to accept the change. :-)
I agree, it feels like they overshot the target with regards to security. There is no room anymore for *pragmatic* solutions. It’s a tradeoff. With the rise of Flatpak and Snap and all that, I think this additional security is warranted, because people will probably run more and more completely untrusted programs in the future (not even *somewhat* approved by a distro). 🫤
Btw, I *think* nothing in the Wayland protocol specs says that you have to cram everything into the compositor. People *could have* designed interfaces to allow for “a Wayland server” and “a Wayland window manager”, it’s just that nobody did do it. Or maybe things get way too complicated if you try to do it.
There was a waysome project a long time ago, but it’s dead. That’s a super interesting approach. I already loved that about awesomewm back in the day: You can drop your own scripts to greatly extend the core functions. If I’m ever going to write a Wayland compositor, that’s what I’m going to do: Implement as much as possible in Lua, so users can easily install their own stuff.
> I never tried Wayland myself. Nor did I do any research on that matter.
You’re already an i3 user, aren’t you? 🤔 Switching to Sway should be much less painful for you. Give it a shot, don’t trust anything I say! 😅
@lyse
> Hmm, how do pointer barriers work? How do you switch to another screen then? At one point, you just have to, don't you?
My xpointerbarrier is very simple: It creates a *static* barrier. To switch to another screen, I press a hotkey. But they can be implemented differently, for example you might have to “push” the pointer over the barrier or you might have to hit it at a certain speed or something like that. I didn’t need anything like that, though.
> What's your use case to send keyboard events to an asortment of windows?
Mainly typing the same thing into multiple SSH sessions. For example, I edited the same zone file on both of our DNS servers at work today.
(Blog post about multipass)
multipass is not a *must have* for me – tmux has that feature, too, as well as some terminal emulators. But all those other solutions require *thinking ahead*, whereas with multipass I can just combine any windows that I like *at any time*. (Or maybe it is possible with tmux as well, by moving panes around like crazy, which I imagine is quite cumbersome.)
> If I want a fucked up clipboard […]
I couldn’t be bothered to investigate this. Just found these two links with some more info:
- https://blog.martin-graesslin.com/blog/2016/07/synchronizing-the-x11-and-wayland-clipboard/
- https://www.reddit.com/r/swaywm/comments/rv668l/yet_another_clipboard_thread_x11_sync_wayland_and/
So it’s a nice example of “has been solved in KDE, but not in Sway”.
> Complicating everthing at basically no gain. Security is all good and nice, but if you can't do basic things anymore, then that's the opposite of progress or even a working system.
I’m pretty sure that you can get to a working system, you just have be willing to accept the change. :-)
I agree, it feels like they overshot the target with regards to security. There is no room anymore for *pragmatic* solutions. It’s a tradeoff. With the rise of Flatpak and Snap and all that, I think this additional security is warranted, because people will probably run more and more completely untrusted programs in the future (not even *somewhat* approved by a distro). 🫤
Btw, I *think* nothing in the Wayland protocol specs says that you have to cram everything into the compositor. People *could have* designed interfaces to allow for “a Wayland server” and “a Wayland window manager”, it’s just that nobody did do it. Or maybe things get way too complicated if you try to do it.
There was a waysome project a long time ago, but it’s dead. That’s a super interesting approach. I already loved that about awesomewm back in the day: You can drop your own scripts to greatly extend the core functions. If I’m ever going to write a Wayland compositor, that’s what I’m going to do: Implement as much as possible in Lua, so users can easily install their own stuff.
> I never tried Wayland myself. Nor did I do any research on that matter.
You’re already an i3 user, aren’t you? 🤔 Switching to Sway should be much less painful for you. Give it a shot, don’t trust anything I say! 😅
@lyse
> Hmm, how do pointer barriers work? How do you switch to another screen then? At one point, you just have to, don't you?
My xpointerbarrier is very simple: It creates a *static* barrier. To switch to another screen, I press a hotkey. But they can be implemented differently, for example you might have to “push” the pointer over the barrier or you might have to hit it at a certain speed or something like that. I didn’t need anything like that, though.
> What's your use case to send keyboard events to an asortment of windows?
Mainly typing the same thing into multiple SSH sessions. For example, I edited the same zone file on both of our DNS servers at work today.
(Blog post about multipass)
multipass is not a *must have* for me – tmux has that feature, too, as well as some terminal emulators. But all those other solutions require *thinking ahead*, whereas with multipass I can just combine any windows that I like *at any time*. (Or maybe it is possible with tmux as well, by moving panes around like crazy, which I imagine is quite cumbersome.)
> If I want a fucked up clipboard […]
I couldn’t be bothered to investigate this. Just found these two links with some more info:
- https://blog.martin-graesslin.com/blog/2016/07/synchronizing-the-x11-and-wayland-clipboard/
- https://www.reddit.com/r/swaywm/comments/rv668l/yet_another_clipboard_thread_x11_sync_wayland_and/
So it’s a nice example of “has been solved in KDE, but not in Sway”.
> Complicating everthing at basically no gain. Security is all good and nice, but if you can't do basic things anymore, then that's the opposite of progress or even a working system.
I’m pretty sure that you can get to a working system, you just have be willing to accept the change. :-)
I agree, it feels like they overshot the target with regards to security. There is no room anymore for *pragmatic* solutions. It’s a tradeoff. With the rise of Flatpak and Snap and all that, I think this additional security is warranted, because people will probably run more and more completely untrusted programs in the future (not even *somewhat* approved by a distro). 🫤
Btw, I *think* nothing in the Wayland protocol specs says that you have to cram everything into the compositor. People *could have* designed interfaces to allow for “a Wayland server” and “a Wayland window manager”, it’s just that nobody did do it. Or maybe things get way too complicated if you try to do it.
There was a waysome project a long time ago, but it’s dead. That’s a super interesting approach. I already loved that about awesomewm back in the day: You can drop your own scripts to greatly extend the core functions. If I’m ever going to write a Wayland compositor, that’s what I’m going to do: Implement as much as possible in Lua, so users can easily install their own stuff.
> I never tried Wayland myself. Nor did I do any research on that matter.
You’re already an i3 user, aren’t you? 🤔 Switching to Sway should be much less painful for you. Give it a shot, don’t trust anything I say! 😅
@lyse
> Hmm, how do pointer barriers work? How do you switch to another screen then? At one point, you just have to, don't you?
My xpointerbarrier is very simple: It creates a *static* barrier. To switch to another screen, I press a hotkey. But they can be implemented differently, for example you might have to “push” the pointer over the barrier or you might have to hit it at a certain speed or something like that. I didn’t need anything like that, though.
> What's your use case to send keyboard events to an asortment of windows?
Mainly typing the same thing into multiple SSH sessions. For example, I edited the same zone file on both of our DNS servers at work today.
(Blog post about multipass)
multipass is not a *must have* for me – tmux has that feature, too, as well as some terminal emulators. But all those other solutions require *thinking ahead*, whereas with multipass I can just combine any windows that I like *at any time*. (Or maybe it is possible with tmux as well, by moving panes around like crazy, which I imagine is quite cumbersome.)
> If I want a fucked up clipboard […]
I couldn’t be bothered to investigate this. Just found these two links with some more info:
- https://blog.martin-graesslin.com/blog/2016/07/synchronizing-the-x11-and-wayland-clipboard/
- https://www.reddit.com/r/swaywm/comments/rv668l/yet_another_clipboard_thread_x11_sync_wayland_and/
So it’s a nice example of “has been solved in KDE, but not in Sway”.
> Complicating everthing at basically no gain. Security is all good and nice, but if you can't do basic things anymore, then that's the opposite of progress or even a working system.
I’m pretty sure that you can get to a working system, you just have be willing to accept the change. :-)
I agree, it feels like they overshot the target with regards to security. There is no room anymore for *pragmatic* solutions. It’s a tradeoff. With the rise of Flatpak and Snap and all that, I think this additional security is warranted, because people will probably run more and more completely untrusted programs in the future (not even *somewhat* approved by a distro). 🫤
Btw, I *think* nothing in the Wayland protocol specs says that you have to cram everything into the compositor. People *could have* designed interfaces to allow for “a Wayland server” and “a Wayland window manager”, it’s just that nobody did do it. Or maybe things get way too complicated if you try to do it.
There was a waysome project a long time ago, but it’s dead. That’s a super interesting approach. I already loved that about awesomewm back in the day: You can drop your own scripts to greatly extend the core functions. If I’m ever going to write a Wayland compositor, that’s what I’m going to do: Implement as much as possible in Lua, so users can easily install their own stuff.
> I never tried Wayland myself. Nor did I do any research on that matter.
You’re already an i3 user, aren’t you? 🤔 Switching to Sway should be much less painful for you. Give it a shot, don’t trust anything I say! 😅
@mckinley That’s right, wlroots is a huge improvement. I put all my hopes in that library. 😅
@mckinley That’s right, wlroots is a huge improvement. I put all my hopes in that library. 😅
@mckinley That’s right, wlroots is a huge improvement. I put all my hopes in that library. 😅
@mckinley That’s right, wlroots is a huge improvement. I put all my hopes in that library. 😅
@nmke-de Ohh, that looks interesting. 🤔 That’s exactly that Lua thingy I was talking about, isn’t it? 🤔 Maybe I should try kiwmi next.
@nmke-de Ohh, that looks interesting. 🤔 That’s exactly that Lua thingy I was talking about, isn’t it? 🤔 Maybe I should try kiwmi next.
@nmke-de Ohh, that looks interesting. 🤔 That’s exactly that Lua thingy I was talking about, isn’t it? 🤔 Maybe I should try kiwmi next.
@nmke-de Ohh, that looks interesting. 🤔 That’s exactly that Lua thingy I was talking about, isn’t it? 🤔 Maybe I should try kiwmi next.
@movq Oh, now I see, thanks. These barriers seem like a cool idea to try some time myself.
Alright, multipass is basically for administrating multiple systems at once. Good thing, I'm not an admin. :-) But now I remember a good mate doing this, too. If I'm not mistaken, he used tmux's builtin functionality to update all his, I don't know how many, machines at the same time. Pretty cool actually. This also reminds me that I really should finally take a deeper look at tmux some day. Never did that before. I just open a new terminal and my tiling window manager takes care of most things, well the layout. Except that I would have to explicitly ssh into the other system if I were working some remotely.
Yes, I'm on i3 and really not in a mood to fiddle around and waste my time with broken or unfinished stuff if I can easily avoid it. I just want my system to work. :-)
As for redshift, there is this protocol extension:
https://wayland.app/protocols/wlr-gamma-control-unstable-v1
“Protocol extension” sounds complex, but it basically just means: “Here’s an XML file that describes our thing.” It’s much more formalized than specs like EWMH, which are mostly written in prose. If a compositor decides to implement it, it knows exactly which functions to implement, which arguments they get, and so on.
This is a generic extension that allows you to set a gamma table. So, on Sway, you can use this:
https://github.com/minus7/redshift/tree/wayland
However, scroll down to this table:
https://wayland.app/protocols/wlr-gamma-control-unstable-v1#compositor-support
This *only* works on Sway, not GNOME nor KDE.
For GNOME, there is this other fork:
https://github.com/prahal/redshift/tree/add-gnomerr-method-v0.2
It’s using “GnomeRR”, which appears to be part of “libgnome-desktop”. I couldn’t find official docs for this library (I didn’t search for long, though). Here’s the code: https://gitlab.gnome.org/GNOME/gnome-desktop/-/tree/master/libgnome-desktop They’re basically doing their own thing, outside of Wayland protocol specs (or I misunderstood). It probably makes sense from their point of view.
As for redshift, there is this protocol extension:
https://wayland.app/protocols/wlr-gamma-control-unstable-v1
“Protocol extension” sounds complex, but it basically just means: “Here’s an XML file that describes our thing.” It’s much more formalized than specs like EWMH, which are mostly written in prose. If a compositor decides to implement it, it knows exactly which functions to implement, which arguments they get, and so on.
This is a generic extension that allows you to set a gamma table. So, on Sway, you can use this:
https://github.com/minus7/redshift/tree/wayland
However, scroll down to this table:
https://wayland.app/protocols/wlr-gamma-control-unstable-v1#compositor-support
This *only* works on Sway, not GNOME nor KDE.
For GNOME, there is this other fork:
https://github.com/prahal/redshift/tree/add-gnomerr-method-v0.2
It’s using “GnomeRR”, which appears to be part of “libgnome-desktop”. I couldn’t find official docs for this library (I didn’t search for long, though). Here’s the code: https://gitlab.gnome.org/GNOME/gnome-desktop/-/tree/master/libgnome-desktop They’re basically doing their own thing, outside of Wayland protocol specs (or I misunderstood). It probably makes sense from their point of view.
As for redshift, there is this protocol extension:
https://wayland.app/protocols/wlr-gamma-control-unstable-v1
“Protocol extension” sounds complex, but it basically just means: “Here’s an XML file that describes our thing.” It’s much more formalized than specs like EWMH, which are mostly written in prose. If a compositor decides to implement it, it knows exactly which functions to implement, which arguments they get, and so on.
This is a generic extension that allows you to set a gamma table. So, on Sway, you can use this:
https://github.com/minus7/redshift/tree/wayland
However, scroll down to this table:
https://wayland.app/protocols/wlr-gamma-control-unstable-v1#compositor-support
This *only* works on Sway, not GNOME nor KDE.
For GNOME, there is this other fork:
https://github.com/prahal/redshift/tree/add-gnomerr-method-v0.2
It’s using “GnomeRR”, which appears to be part of “libgnome-desktop”. I couldn’t find official docs for this library (I didn’t search for long, though). Here’s the code: https://gitlab.gnome.org/GNOME/gnome-desktop/-/tree/master/libgnome-desktop They’re basically doing their own thing, outside of Wayland protocol specs (or I misunderstood). It probably makes sense from their point of view.
As for redshift, there is this protocol extension:
https://wayland.app/protocols/wlr-gamma-control-unstable-v1
“Protocol extension” sounds complex, but it basically just means: “Here’s an XML file that describes our thing.” It’s much more formalized than specs like EWMH, which are mostly written in prose. If a compositor decides to implement it, it knows exactly which functions to implement, which arguments they get, and so on.
This is a generic extension that allows you to set a gamma table. So, on Sway, you can use this:
https://github.com/minus7/redshift/tree/wayland
However, scroll down to this table:
https://wayland.app/protocols/wlr-gamma-control-unstable-v1#compositor-support
This *only* works on Sway, not GNOME nor KDE.
For GNOME, there is this other fork:
https://github.com/prahal/redshift/tree/add-gnomerr-method-v0.2
It’s using “GnomeRR”, which appears to be part of “libgnome-desktop”. I couldn’t find official docs for this library (I didn’t search for long, though). Here’s the code: https://gitlab.gnome.org/GNOME/gnome-desktop/-/tree/master/libgnome-desktop They’re basically doing their own thing, outside of Wayland protocol specs (or I misunderstood). It probably makes sense from their point of view.
You have to appreciate Drew DeVault’s work, though. The entire Sway team, actually. If it wasn’t for them and their persistence, the situation would probably be *much worse*, because I have a feeling that nobody would consider the use cases of lightweight desktops at all. And, of course, wlroots wouldn’t exist.
You have to appreciate Drew DeVault’s work, though. The entire Sway team, actually. If it wasn’t for them and their persistence, the situation would probably be *much worse*, because I have a feeling that nobody would consider the use cases of lightweight desktops at all. And, of course, wlroots wouldn’t exist.
You have to appreciate Drew DeVault’s work, though. The entire Sway team, actually. If it wasn’t for them and their persistence, the situation would probably be *much worse*, because I have a feeling that nobody would consider the use cases of lightweight desktops at all. And, of course, wlroots wouldn’t exist.
You have to appreciate Drew DeVault’s work, though. The entire Sway team, actually. If it wasn’t for them and their persistence, the situation would probably be *much worse*, because I have a feeling that nobody would consider the use cases of lightweight desktops at all. And, of course, wlroots wouldn’t exist.