# 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 4
# self = https://watcher.sour.is/conv/anhstrq
I’m putting all efforts to switch to Wayland on hold for another 2 years, minimum.
As we all know, writing a Wayland compositor from scratch is next to impossible. Luckily, there’s the wlroots project which aims to build a base library for this task. Basically every compositor except for GNOME and KDE uses it. (This is good! The less fragmentation, the better.)
wlroots is still very volatile, lots of changes with every release. Downstream users (i.e., the projects that write the actual compositor) have to constantly “chase” changes in wlroots. dwl, my favorite compositor at the moment, has recently switched their main branch to target the wlroots *git* version instead of the latest release. My understanding is that they *have* to do this in order to keep up with wlroots (maybe I’m wrong).
Everything is volatile and a moving target.
Why does any of this matter for me? Because I have to eventually fork dwl or at least keep a patch set, and I don’t have the stamina to constantly fiddle with this stuff. I’m running my own X11 window manager, it’s highly specialized, and using just “some Wayland compositor out there” is a *huge* step backward that I’m not willing to take. I tried, it’s just painful and annoying with *zero* benefits.
So … it was fun experimenting with Wayland a bit, but I’m now back to waiting for things to settle down considerably.
I’m putting all efforts to switch to Wayland on hold for another 2 years, minimum.
As we all know, writing a Wayland compositor from scratch is next to impossible. Luckily, there’s the wlroots project which aims to build a base library for this task. Basically every compositor except for GNOME and KDE uses it. (This is good! The less fragmentation, the better.)
wlroots is still very volatile, lots of changes with every release. Downstream users (i.e., the projects that write the actual compositor) have to constantly “chase” changes in wlroots. dwl, my favorite compositor at the moment, has recently switched their main branch to target the wlroots *git* version instead of the latest release. My understanding is that they *have* to do this in order to keep up with wlroots (maybe I’m wrong).
Everything is volatile and a moving target.
Why does any of this matter for me? Because I have to eventually fork dwl or at least keep a patch set, and I don’t have the stamina to constantly fiddle with this stuff. I’m running my own X11 window manager, it’s highly specialized, and using just “some Wayland compositor out there” is a *huge* step backward that I’m not willing to take. I tried, it’s just painful and annoying with *zero* benefits.
So … it was fun experimenting with Wayland a bit, but I’m now back to waiting for things to settle down considerably.
I’m putting all efforts to switch to Wayland on hold for another 2 years, minimum.
As we all know, writing a Wayland compositor from scratch is next to impossible. Luckily, there’s the wlroots project which aims to build a base library for this task. Basically every compositor except for GNOME and KDE uses it. (This is good! The less fragmentation, the better.)
wlroots is still very volatile, lots of changes with every release. Downstream users (i.e., the projects that write the actual compositor) have to constantly “chase” changes in wlroots. dwl, my favorite compositor at the moment, has recently switched their main branch to target the wlroots *git* version instead of the latest release. My understanding is that they *have* to do this in order to keep up with wlroots (maybe I’m wrong).
Everything is volatile and a moving target.
Why does any of this matter for me? Because I have to eventually fork dwl or at least keep a patch set, and I don’t have the stamina to constantly fiddle with this stuff. I’m running my own X11 window manager, it’s highly specialized, and using just “some Wayland compositor out there” is a *huge* step backward that I’m not willing to take. I tried, it’s just painful and annoying with *zero* benefits.
So … it was fun experimenting with Wayland a bit, but I’m now back to waiting for things to settle down considerably.
I’m putting all efforts to switch to Wayland on hold for another 2 years, minimum.
As we all know, writing a Wayland compositor from scratch is next to impossible. Luckily, there’s the wlroots project which aims to build a base library for this task. Basically every compositor except for GNOME and KDE uses it. (This is good! The less fragmentation, the better.)
wlroots is still very volatile, lots of changes with every release. Downstream users (i.e., the projects that write the actual compositor) have to constantly “chase” changes in wlroots. dwl, my favorite compositor at the moment, has recently switched their main branch to target the wlroots *git* version instead of the latest release. My understanding is that they *have* to do this in order to keep up with wlroots (maybe I’m wrong).
Everything is volatile and a moving target.
Why does any of this matter for me? Because I have to eventually fork dwl or at least keep a patch set, and I don’t have the stamina to constantly fiddle with this stuff. I’m running my own X11 window manager, it’s highly specialized, and using just “some Wayland compositor out there” is a *huge* step backward that I’m not willing to take. I tried, it’s just painful and annoying with *zero* benefits.
So … it was fun experimenting with Wayland a bit, but I’m now back to waiting for things to settle down considerably.