https://movq.de/v/0a0969059a/2024-06-25--19-59-29--58376.ogg
Still a noob, but I can see some progress and I enjoy playing very much. 😊
(Use headphones, probably sounds like crap otherwise.)
https://movq.de/v/0a0969059a/2024-06-25--19-59-29--58376.ogg
Still a noob, but I can see some progress and I enjoy playing very much. 😊
(Use headphones, probably sounds like crap otherwise.)
https://movq.de/v/19f5512396/IMG_20240623_104210.jpg
The dark area below them? It’s not a shadow, it’s dirt. O_o
https://movq.de/v/19f5512396/IMG_20240623_104210.jpg
The dark area below them? It’s not a shadow, it’s dirt. O_o
https://movq.de/v/19f5512396/IMG_20240623_104210.jpg
The dark area below them? It’s not a shadow, it’s dirt. O_o
https://movq.de/v/19f5512396/IMG_20240623_104210.jpg
The dark area below them? It’s not a shadow, it’s dirt. O_o
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.
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.
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.
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.
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.
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.
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.
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.
ai.txt / robots.txt, but I wouldn’t trust that they don’t spoof their user agent. 🤔
ai.txt / robots.txt, but I wouldn’t trust that they don’t spoof their user agent. 🤔
ai.txt / robots.txt, but I wouldn’t trust that they don’t spoof their user agent. 🤔
ai.txt / robots.txt, but I wouldn’t trust that they don’t spoof their user agent. 🤔
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. 🤔
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. 🤔
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. 🤔
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. 🤔
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.
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.
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.
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.
Interestingly, this isn’t such a crazy rare scenario after all, see this comment regarding
XF86MonBrightness*: https://github.com/swaywm/wlroots/pull/1771#issuecomment-515507790
Interestingly, this isn’t such a crazy rare scenario after all, see this comment regarding
XF86MonBrightness*: https://github.com/swaywm/wlroots/pull/1771#issuecomment-515507790
Interestingly, this isn’t such a crazy rare scenario after all, see this comment regarding
XF86MonBrightness*: https://github.com/swaywm/wlroots/pull/1771#issuecomment-515507790
Interestingly, this isn’t such a crazy rare scenario after all, see this comment regarding
XF86MonBrightness*: https://github.com/swaywm/wlroots/pull/1771#issuecomment-515507790
$header_cache option, which might help a bit:http://www.mutt.org/doc/manual/#header-cache
I disabled it over a year ago on my machine, because it didn’t make that much of a difference anymore. 🤔
$header_cache option, which might help a bit:http://www.mutt.org/doc/manual/#header-cache
I disabled it over a year ago on my machine, because it didn’t make that much of a difference anymore. 🤔
$header_cache option, which might help a bit:http://www.mutt.org/doc/manual/#header-cache
I disabled it over a year ago on my machine, because it didn’t make that much of a difference anymore. 🤔
$header_cache option, which might help a bit:http://www.mutt.org/doc/manual/#header-cache
I disabled it over a year ago on my machine, because it didn’t make that much of a difference anymore. 🤔
When there’s a goal, though, it takes them a whole minute to begin cheering. That is some excessive buffering. 😂
When there’s a goal, though, it takes them a whole minute to begin cheering. That is some excessive buffering. 😂
When there’s a goal, though, it takes them a whole minute to begin cheering. That is some excessive buffering. 😂
When there’s a goal, though, it takes them a whole minute to begin cheering. That is some excessive buffering. 😂
It depends on the type of rosin, though. The one that I used before is basically opaque and also much harder:
I intentionally went for the softer rosin this time, because I find it easier to use. It’s stickier and can be applied to the bow much easier.
It depends on the type of rosin, though. The one that I used before is basically opaque and also much harder:
I intentionally went for the softer rosin this time, because I find it easier to use. It’s stickier and can be applied to the bow much easier.
It depends on the type of rosin, though. The one that I used before is basically opaque and also much harder:
I intentionally went for the softer rosin this time, because I find it easier to use. It’s stickier and can be applied to the bow much easier.