# 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 15607
# self = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=11306
# next = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=11406
# prev = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=11206
So I’ve been wondering why some copy-and-paste actions “don’t work” on Wayland. Turns out, in Wayland there’s only one clipboard (like in probably most other OSes): The one where you select something and then hit ^C to copy it (it’s called the CLIPBOARD selection). They have intentionally not included the PRIMARY selection of X11 where you can just select some text to copy it and use the middle-mouse button to paste it.
Almost 10 years ago, they started an initiative to bring back PRIMARY:
https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
That protocol is still “unstable” and thus not every Wayland client supports it:
https://wayland.app/protocols/primary-selection-unstable-v1
I honestly didn’t really look into this before and I didn’t know that it’s *still* unstable/unsupported, hence my confusion. (To be fair, I don’t know for certain if that particular protocol is already 10 years old. It looks like it because the copyright notice at the bottom says so, but no idea if that’s a reliable source.)
This is one of those things that are very subjective. The Wayland guys apparently thought that it was a “usability problem” to have two clipboards, so they removed one of them. Actually, the mechanism of X11 is totally generic, there are an “infinite” number of clipboards and we have just settled on using only two.
This is an interesting topic because Wayland is *so old* now that it looks like it has missed the developments of the last ~10 years or more: Way back in the past, I was indeed very confused about the different X11 clipboards because some clients used CLIPBOARD (hit ^C) and others only used PRIMARY (middle-mouse) – but this has long settled down. *Most* clients now have something like ^C to explicitly copy data into CLIPBOARD and ^V to paste it. It’s the standard thing now. And then *on top of that* power-users can additionally use PRIMARY where you just select text. This is a good and powerful thing, if you ask me.
I use both clipboards all the time. My mental model knows where the data goes. PRIMARY is like a short-term clipboard and CLIPBOARD is long-term. I think this is much better than just having one clipboard and I kind of feel like making good use of this is what keeps me from having to install a clipboard manager.~
So I’ve been wondering why some copy-and-paste actions “don’t work” on Wayland. Turns out, in Wayland there’s only one clipboard (like in probably most other OSes): The one where you select something and then hit ^C to copy it (it’s called the CLIPBOARD selection). They have intentionally not included the PRIMARY selection of X11 where you can just select some text to copy it and use the middle-mouse button to paste it.
Almost 10 years ago, they started an initiative to bring back PRIMARY:
https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
That protocol is still “unstable” and thus not every Wayland client supports it:
https://wayland.app/protocols/primary-selection-unstable-v1
I honestly didn’t really look into this before and I didn’t know that it’s *still* unstable/unsupported, hence my confusion. (To be fair, I don’t know for certain if that particular protocol is already 10 years old. It looks like it because the copyright notice at the bottom says so, but no idea if that’s a reliable source.)
This is one of those things that are very subjective. The Wayland guys apparently thought that it was a “usability problem” to have two clipboards, so they removed one of them. Actually, the mechanism of X11 is totally generic, there are an “infinite” number of clipboards and we have just settled on using only two.
This is an interesting topic because Wayland is *so old* now that it looks like it has missed the developments of the last ~10 years or more: Way back in the past, I was indeed very confused about the different X11 clipboards because some clients used CLIPBOARD (hit ^C) and others only used PRIMARY (middle-mouse) – but this has long settled down. *Most* clients now have something like ^C to explicitly copy data into CLIPBOARD and ^V to paste it. It’s the standard thing now. And then *on top of that* power-users can additionally use PRIMARY where you just select text. This is a good and powerful thing, if you ask me.
I use both clipboards all the time. My mental model knows where the data goes. PRIMARY is like a short-term clipboard and CLIPBOARD is long-term. I think this is much better than just having one clipboard and I kind of feel like making good use of this is what keeps me from having to install a clipboard manager.~
So I’ve been wondering why some copy-and-paste actions “don’t work” on Wayland. Turns out, in Wayland there’s only one clipboard (like in probably most other OSes): The one where you select something and then hit ^C to copy it (it’s called the CLIPBOARD selection). They have intentionally not included the PRIMARY selection of X11 where you can just select some text to copy it and use the middle-mouse button to paste it.
Almost 10 years ago, they started an initiative to bring back PRIMARY:
https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
That protocol is still “unstable” and thus not every Wayland client supports it:
https://wayland.app/protocols/primary-selection-unstable-v1
I honestly didn’t really look into this before and I didn’t know that it’s *still* unstable/unsupported, hence my confusion. (To be fair, I don’t know for certain if that particular protocol is already 10 years old. It looks like it because the copyright notice at the bottom says so, but no idea if that’s a reliable source.)
This is one of those things that are very subjective. The Wayland guys apparently thought that it was a “usability problem” to have two clipboards, so they removed one of them. Actually, the mechanism of X11 is totally generic, there are an “infinite” number of clipboards and we have just settled on using only two.
This is an interesting topic because Wayland is *so old* now that it looks like it has missed the developments of the last ~10 years or more: Way back in the past, I was indeed very confused about the different X11 clipboards because some clients used CLIPBOARD (hit ^C) and others only used PRIMARY (middle-mouse) – but this has long settled down. *Most* clients now have something like ^C to explicitly copy data into CLIPBOARD and ^V to paste it. It’s the standard thing now. And then *on top of that* power-users can additionally use PRIMARY where you just select text. This is a good and powerful thing, if you ask me.
I use both clipboards all the time. My mental model knows where the data goes. PRIMARY is like a short-term clipboard and CLIPBOARD is long-term. I think this is much better than just having one clipboard and I kind of feel like making good use of this is what keeps me from having to install a clipboard manager.~
So I’ve been wondering why some copy-and-paste actions “don’t work” on Wayland. Turns out, in Wayland there’s only one clipboard (like in probably most other OSes): The one where you select something and then hit ^C to copy it (it’s called the CLIPBOARD selection). They have intentionally not included the PRIMARY selection of X11 where you can just select some text to copy it and use the middle-mouse button to paste it.
Almost 10 years ago, they started an initiative to bring back PRIMARY:
https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
That protocol is still “unstable” and thus not every Wayland client supports it:
https://wayland.app/protocols/primary-selection-unstable-v1
I honestly didn’t really look into this before and I didn’t know that it’s *still* unstable/unsupported, hence my confusion. (To be fair, I don’t know for certain if that particular protocol is already 10 years old. It looks like it because the copyright notice at the bottom says so, but no idea if that’s a reliable source.)
This is one of those things that are very subjective. The Wayland guys apparently thought that it was a “usability problem” to have two clipboards, so they removed one of them. Actually, the mechanism of X11 is totally generic, there are an “infinite” number of clipboards and we have just settled on using only two.
This is an interesting topic because Wayland is *so old* now that it looks like it has missed the developments of the last ~10 years or more: Way back in the past, I was indeed very confused about the different X11 clipboards because some clients used CLIPBOARD (hit ^C) and others only used PRIMARY (middle-mouse) – but this has long settled down. *Most* clients now have something like ^C to explicitly copy data into CLIPBOARD and ^V to paste it. It’s the standard thing now. And then *on top of that* power-users can additionally use PRIMARY where you just select text. This is a good and powerful thing, if you ask me.
I use both clipboards all the time. My mental model knows where the data goes. PRIMARY is like a short-term clipboard and CLIPBOARD is long-term. I think this is much better than just having one clipboard and I kind of feel like making good use of this is what keeps me from having to install a clipboard manager.~
@lyse Aarrrgh. 🙈🙈🙈 There’s nothing you can do to prevent that next time, is there?
@lyse Aarrrgh. 🙈🙈🙈 There’s nothing you can do to prevent that next time, is there?
@lyse Aarrrgh. 🙈🙈🙈 There’s nothing you can do to prevent that next time, is there?
@lyse Aarrrgh. 🙈🙈🙈 There’s nothing you can do to prevent that next time, is there?
@prologic 8.9 people per km², sounds awesome. 😃 Even less than Finland. 😅 (On average.)
@prologic 8.9 people per km², sounds awesome. 😃 Even less than Finland. 😅 (On average.)
@prologic 8.9 people per km², sounds awesome. 😃 Even less than Finland. 😅 (On average.)
@prologic 8.9 people per km², sounds awesome. 😃 Even less than Finland. 😅 (On average.)
Iceland seems like a nice place to be right now.
Iceland seems like a nice place to be right now.
Iceland seems like a nice place to be right now.
Iceland seems like a nice place to be right now.
😆 I’ll take a close up next time. 😅
😆 I’ll take a close up next time. 😅
😆 I’ll take a close up next time. 😅
😆 I’ll take a close up next time. 😅
Not gonna lie, hacking on dwl is fun. Not sure if it’s worth it (is Wayland really going to win?), but it’s fun. 😅
Not gonna lie, hacking on dwl is fun. Not sure if it’s worth it (is Wayland really going to win?), but it’s fun. 😅
Not gonna lie, hacking on dwl is fun. Not sure if it’s worth it (is Wayland really going to win?), but it’s fun. 😅
Not gonna lie, hacking on dwl is fun. Not sure if it’s worth it (is Wayland really going to win?), but it’s fun. 😅
@prologic Soooooooo … what wins? Users or the Complexity Budget? 😏
@prologic Soooooooo … what wins? Users or the Complexity Budget? 😏
@prologic Soooooooo … what wins? Users or the Complexity Budget? 😏
@prologic Soooooooo … what wins? Users or the Complexity Budget? 😏
In (old, pre-compositor) X11, windows were rectangles on screen. Every normal X11 client could query all windows and their positions. Tools like slop were easy to implement: You can use it to interactively select one of the windows on the screen, e.g. to make a screenshot of that window. slop just queries the window under the mouse pointer, it can then highlight it and read its position. Done. (slop includes more bloat/eyecandy, but that’s beside the point.)
Afaik, that’s not possible on Wayland. slurp exists but there is no standard way (yet?) for it to query the window tree. It’s different for each Wayland compositor. slurp’s README includes an example for Sway; for dwl you need this patch; and selecting individual windows probably does not work at all on labwc (because those guys try to stick only to established protocols/standards – an admirable goal).
This is just a small example. I think things like these slow down Wayland progress/adoption a lot. You could get a lot more done on X11 because the rules weren’t so strict. On Wayland, everything has to become an official protocol (that each compositor then has to implement individually) or it’s going to be an incompatible, unofficial, compositor-specific solution.
Both approaches have pros and cons. Wayland is much more idealistic than the “wild west” of X11. The price is that it takes a hell of a lot more time and energy to push things forward on Wayland.
In (old, pre-compositor) X11, windows were rectangles on screen. Every normal X11 client could query all windows and their positions. Tools like slop were easy to implement: You can use it to interactively select one of the windows on the screen, e.g. to make a screenshot of that window. slop just queries the window under the mouse pointer, it can then highlight it and read its position. Done. (slop includes more bloat/eyecandy, but that’s beside the point.)
Afaik, that’s not possible on Wayland. slurp exists but there is no standard way (yet?) for it to query the window tree. It’s different for each Wayland compositor. slurp’s README includes an example for Sway; for dwl you need this patch; and selecting individual windows probably does not work at all on labwc (because those guys try to stick only to established protocols/standards – an admirable goal).
This is just a small example. I think things like these slow down Wayland progress/adoption a lot. You could get a lot more done on X11 because the rules weren’t so strict. On Wayland, everything has to become an official protocol (that each compositor then has to implement individually) or it’s going to be an incompatible, unofficial, compositor-specific solution.
Both approaches have pros and cons. Wayland is much more idealistic than the “wild west” of X11. The price is that it takes a hell of a lot more time and energy to push things forward on Wayland.
In (old, pre-compositor) X11, windows were rectangles on screen. Every normal X11 client could query all windows and their positions. Tools like slop were easy to implement: You can use it to interactively select one of the windows on the screen, e.g. to make a screenshot of that window. slop just queries the window under the mouse pointer, it can then highlight it and read its position. Done. (slop includes more bloat/eyecandy, but that’s beside the point.)
Afaik, that’s not possible on Wayland. slurp exists but there is no standard way (yet?) for it to query the window tree. It’s different for each Wayland compositor. slurp’s README includes an example for Sway; for dwl you need this patch; and selecting individual windows probably does not work at all on labwc (because those guys try to stick only to established protocols/standards – an admirable goal).
This is just a small example. I think things like these slow down Wayland progress/adoption a lot. You could get a lot more done on X11 because the rules weren’t so strict. On Wayland, everything has to become an official protocol (that each compositor then has to implement individually) or it’s going to be an incompatible, unofficial, compositor-specific solution.
Both approaches have pros and cons. Wayland is much more idealistic than the “wild west” of X11. The price is that it takes a hell of a lot more time and energy to push things forward on Wayland.
In (old, pre-compositor) X11, windows were rectangles on screen. Every normal X11 client could query all windows and their positions. Tools like slop were easy to implement: You can use it to interactively select one of the windows on the screen, e.g. to make a screenshot of that window. slop just queries the window under the mouse pointer, it can then highlight it and read its position. Done. (slop includes more bloat/eyecandy, but that’s beside the point.)
Afaik, that’s not possible on Wayland. slurp exists but there is no standard way (yet?) for it to query the window tree. It’s different for each Wayland compositor. slurp’s README includes an example for Sway; for dwl you need this patch; and selecting individual windows probably does not work at all on labwc (because those guys try to stick only to established protocols/standards – an admirable goal).
This is just a small example. I think things like these slow down Wayland progress/adoption a lot. You could get a lot more done on X11 because the rules weren’t so strict. On Wayland, everything has to become an official protocol (that each compositor then has to implement individually) or it’s going to be an incompatible, unofficial, compositor-specific solution.
Both approaches have pros and cons. Wayland is much more idealistic than the “wild west” of X11. The price is that it takes a hell of a lot more time and energy to push things forward on Wayland.
@eldersnake Nothing stops you from having two different sessions. 😏
@eldersnake Nothing stops you from having two different sessions. 😏
@eldersnake Nothing stops you from having two different sessions. 😏
@eldersnake Nothing stops you from having two different sessions. 😏
Even if it might sound a bit overdramatic: Having a “mostly working” dwl Wayland setup now is a huge relief. 😅 It’s quite the weight off my shoulders.
There are still lots of items on my TODO list, but if X.Org were to die tomorrow, I wouldn’t be completely screwed. Only, like, 30% screwed.
Even if it might sound a bit overdramatic: Having a “mostly working” dwl Wayland setup now is a huge relief. 😅 It’s quite the weight off my shoulders.
There are still lots of items on my TODO list, but if X.Org were to die tomorrow, I wouldn’t be completely screwed. Only, like, 30% screwed.
Even if it might sound a bit overdramatic: Having a “mostly working” dwl Wayland setup now is a huge relief. 😅 It’s quite the weight off my shoulders.
There are still lots of items on my TODO list, but if X.Org were to die tomorrow, I wouldn’t be completely screwed. Only, like, 30% screwed.
Even if it might sound a bit overdramatic: Having a “mostly working” dwl Wayland setup now is a huge relief. 😅 It’s quite the weight off my shoulders.
There are still lots of items on my TODO list, but if X.Org were to die tomorrow, I wouldn’t be completely screwed. Only, like, 30% screwed.
@bender Ha! That’s the way to go! 😃
@bender Ha! That’s the way to go! 😃
@bender Ha! That’s the way to go! 😃
@bender Ha! That’s the way to go! 😃
@aelaraji @prologic Hmm, yeah, looks a bit better than ai.txt / robots.txt, but I wouldn’t trust that they don’t spoof their user agent. 🤔
@aelaraji @prologic Hmm, yeah, looks a bit better than ai.txt / robots.txt, but I wouldn’t trust that they don’t spoof their user agent. 🤔
@aelaraji @prologic Hmm, yeah, looks a bit better than ai.txt / robots.txt, but I wouldn’t trust that they don’t spoof their user agent. 🤔
@aelaraji @prologic Hmm, yeah, looks a bit better than ai.txt / robots.txt, but I wouldn’t trust that they don’t spoof their user agent. 🤔
@prologic And it won’t be the last. 😅 It’s inevitable at this level of complexity …
@prologic And it won’t be the last. 😅 It’s inevitable at this level of complexity …
@prologic And it won’t be the last. 😅 It’s inevitable at this level of complexity …
@prologic And it won’t be the last. 😅 It’s inevitable at this level of complexity …
Lot of testing going on here today. 🤣
Lot of testing going on here today. 🤣
Lot of testing going on here today. 🤣
Lot of testing going on here today. 🤣
Well, I have a very basic setup going now that I can use for further experiments.
In the long run, I’m going to effectively fork dwl. I’m very glad that this project exists, saves me a lot of work. I think this is the only way forward for me – any other compositor out there requires making too many sacrifices.
The big question is: How stable is wlroots (the underlying Wayland library)? There appear to be _a lot_ of breaking changes in each release, these are the last two releases:
- https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.17.0
- https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0
Will I have the resources to keep up with that? Maybe it’s _still_ too early to begin this journey. 🤔
Well, I have a very basic setup going now that I can use for further experiments.
In the long run, I’m going to effectively fork dwl. I’m very glad that this project exists, saves me a lot of work. I think this is the only way forward for me – any other compositor out there requires making too many sacrifices.
The big question is: How stable is wlroots (the underlying Wayland library)? There appear to be _a lot_ of breaking changes in each release, these are the last two releases:
- https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.17.0
- https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0
Will I have the resources to keep up with that? Maybe it’s _still_ too early to begin this journey. 🤔
Well, I have a very basic setup going now that I can use for further experiments.
In the long run, I’m going to effectively fork dwl. I’m very glad that this project exists, saves me a lot of work. I think this is the only way forward for me – any other compositor out there requires making too many sacrifices.
The big question is: How stable is wlroots (the underlying Wayland library)? There appear to be _a lot_ of breaking changes in each release, these are the last two releases:
- https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.17.0
- https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0
Will I have the resources to keep up with that? Maybe it’s _still_ too early to begin this journey. 🤔
Well, I have a very basic setup going now that I can use for further experiments.
In the long run, I’m going to effectively fork dwl. I’m very glad that this project exists, saves me a lot of work. I think this is the only way forward for me – any other compositor out there requires making too many sacrifices.
The big question is: How stable is wlroots (the underlying Wayland library)? There appear to be _a lot_ of breaking changes in each release, these are the last two releases:
- https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.17.0
- https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0
Will I have the resources to keep up with that? Maybe it’s _still_ too early to begin this journey. 🤔
There’s hope regarding Wayland.
I’ve tried dwl a few years back, but my keyboard didn’t work. This appears to have been fixed, probably due to advances in wlroots and this commit.
And look at it: It’s just about 3000 lines of C code. *That* is hackable. That is something that I can fix, extend, or adapt if needed. *That is the way to go.*
Thank goodness, finally some good news.
There’s hope regarding Wayland.
I’ve tried dwl a few years back, but my keyboard didn’t work. This appears to have been fixed, probably due to advances in wlroots and this commit.
And look at it: It’s just about 3000 lines of C code. *That* is hackable. That is something that I can fix, extend, or adapt if needed. *That is the way to go.*
Thank goodness, finally some good news.
There’s hope regarding Wayland.
I’ve tried dwl a few years back, but my keyboard didn’t work. This appears to have been fixed, probably due to advances in wlroots and this commit.
And look at it: It’s just about 3000 lines of C code. *That* is hackable. That is something that I can fix, extend, or adapt if needed. *That is the way to go.*
Thank goodness, finally some good news.
There’s hope regarding Wayland.
I’ve tried dwl a few years back, but my keyboard didn’t work. This appears to have been fixed, probably due to advances in wlroots and this commit.
And look at it: It’s just about 3000 lines of C code. *That* is hackable. That is something that I can fix, extend, or adapt if needed. *That is the way to go.*
Thank goodness, finally some good news.