| 2026-04-29 01:46:29 +0000 | RMSBach | (~RMSBach@24.210.2.24) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2026-04-29 01:46:43 +0000 | RMSBach | (~RMSBach@2603:6013:9b40:6f2::1040) RMSBach |
| 2026-04-29 02:45:34 +0000 | coldpress | (~coldpress@124.143.212.35.bc.googleusercontent.com) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-04-29 02:46:55 +0000 | coldpress | (~coldpress@124.143.212.35.bc.googleusercontent.com) coldpress |
| 2026-04-29 04:00:49 +0000 | haskellbridge | (~hackager@96.28.224.214) (Read error: Connection reset by peer) |
| 2026-04-29 04:01:10 +0000 | haskellbridge | (~hackager@96.28.224.214) hackager |
| 2026-04-29 04:02:36 +0000 | jaysson | (~jay@user/jaysson) (Quit: WeeChat 4.9.0) |
| 2026-04-29 04:44:06 +0000 | <haskellbridge> | <colonelpanic> wondering if the sort of obvious idea of trying to make xmonad talk to river is an idea that anyone else has considerd. i did see that this was created recently https://codeberg.org/andrea_rossato/hs-wayland-scanner I think there are a lot of different ways that this could be approached. Maybe this is less feasible than I'm imagining it to be, but i do wonder if we could fork the core xmonad repo and try to keep its api as... |
| 2026-04-29 04:44:12 +0000 | <haskellbridge> | ... consistent as possible. i think it might be possible to preserve a substantial portion of xmonad contrib this way as well. Thoughts? |
| 2026-04-29 04:49:21 +0000 | <geekosaur> | it was discussed here recently, in fact |
| 2026-04-29 04:49:41 +0000 | <geekosaur> | (search for "river") |
| 2026-04-29 04:50:20 +0000 | <geekosaur> | there should even be an image from a quick vibe-coded PoC by Solid |
| 2026-04-29 04:50:53 +0000 | <geekosaur> | still needs someone to do the actual work, plus translating contrib over will be a rather large project |
| 2026-04-29 06:28:30 +0000 | vados | (~vados@46-133-1-158.mobile.vf-ua.net) (Quit: WeeChat 4.7.1) |
| 2026-04-29 07:32:45 +0000 | nattkyrro | (~serenity@user/nattkyrro) nattkyrro |
| 2026-04-29 08:23:02 +0000 | ft | (~ft@p508db287.dip0.t-ipconnect.de) (Quit: leaving) |
| 2026-04-29 09:26:09 +0000 | Enrico63 | (~Enrico63@85.255.235.90) Enrico63 |
| 2026-04-29 10:48:01 +0000 | Enrico63 | (~Enrico63@85.255.235.90) (Quit: Client closed) |
| 2026-04-29 12:04:51 +0000 | Enrico63 | (~Enrico63@85.255.235.90) Enrico63 |
| 2026-04-29 12:08:34 +0000 | avalan | (~dweller@178.62.146.60) (Ping timeout: 244 seconds) |
| 2026-04-29 12:10:19 +0000 | dweller | (~dweller@178.62.146.60) dwelli |
| 2026-04-29 12:54:47 +0000 | Enrico63 | (~Enrico63@85.255.235.90) (Quit: Client closed) |
| 2026-04-29 13:50:49 +0000 | tremon | (~tremon@83.80.159.219) tremon |
| 2026-04-29 14:33:32 +0000 | jaysson | (~jay@user/jaysson) jaysson |
| 2026-04-29 15:22:58 +0000 | vados | (~vados@46-133-1-158.mobile.vf-ua.net) |
| 2026-04-29 16:38:39 +0000 | gwentpl | (~gwpl@user/gwentpl) (Read error: Connection reset by peer) |
| 2026-04-29 16:52:39 +0000 | gwentpl | (~gwpl@user/gwentpl) gwentpl |
| 2026-04-29 17:19:19 +0000 | gwentpl | (~gwpl@user/gwentpl) (Read error: Connection reset by peer) |
| 2026-04-29 17:21:22 +0000 | gwentpl | (~gwpl@user/gwentpl) gwentpl |
| 2026-04-29 17:42:31 +0000 | <haskellbridge> | <colonelpanic> geekosaur: of course, but its also something that could be done incrementally |
| 2026-04-29 17:43:02 +0000 | <geekosaur> | it could be, but without contrib xmonad loses a lot of what it offers |
| 2026-04-29 17:43:10 +0000 | <geekosaur> | I mean, the core is _really_ plain |
| 2026-04-29 17:43:38 +0000 | <haskellbridge> | <colonelpanic> yes of course, but i think it could still feel pretty good, with just the "core of contrib" |
| 2026-04-29 17:44:04 +0000 | <haskellbridge> | <colonelpanic> and I think migration for a lot of stuff probably wont be too hard |
| 2026-04-29 17:44:28 +0000 | <haskellbridge> | <colonelpanic> I haven't looked in to it in detail but I think it might be possible to minimize that amount of api change to the core |
| 2026-04-29 17:47:18 +0000 | <geekosaur> | yeh, the problem there isn't the core. the problem is that many things (in particular layouts) do window server operations, and XLib and libwayland are very different beasts |
| 2026-04-29 17:47:51 +0000 | <geekosaur> | (sadly Spencer didn't realize xcb was a thing when he wrote xmonad; if he had, that would be much easier to migrate) |
| 2026-04-29 18:07:37 +0000 | <haskellbridge> | <colonelpanic> theyre are a lot layouts that are more pure though and would be a bit easier to work with |
| 2026-04-29 18:08:29 +0000 | <geekosaur> | right, but some of the ones that aren't are the more popular ones (e.g. `Tabbed`) |
| 2026-04-29 18:10:02 +0000 | <haskellbridge> | <colonelpanic> yeah i guess the question is like how compatible with xmonad should any migration try to be |
| 2026-04-29 18:10:50 +0000 | <haskellbridge> | <colonelpanic> are there design tweaks to the xmonad paradigm that any effort here that should be made, or should we just aim for similarity to make adaptation of existing xmonad-contrib as easy as possible |
| 2026-04-29 18:11:44 +0000 | <haskellbridge> | <colonelpanic> this might be crazy, but would it be crazy to try to write a core that aims to actually support x11 and River somehow, maybe by using xcb instead of XLib? |
| 2026-04-29 18:12:43 +0000 | <haskellbridge> | <colonelpanic> I have some time to throw at this, but I guess I'd like some input from people about what sort of thing would be more likely to draw support from the existing xmonad community |
| 2026-04-29 18:56:12 +0000 | <geekosaur> | it seems pretty likely that wayland will need to be a separate effort, because even as a river plugin it would run into things like manageHooks not really working the same way in a Wayland world |
| 2026-04-29 18:57:02 +0000 | <geekosaur> | (we're "abusing" an ancient configuration system for window matching that nobody uses any more even on x11 and doesn't exist at all on wayland) |
| 2026-04-29 19:13:20 +0000 | ft | (~ft@p200300cf3f4f28002264268f01ab0284.dip0.t-ipconnect.de) ft |
| 2026-04-29 20:11:45 +0000 | haskellbridge | (~hackager@96.28.224.214) (Ping timeout: 244 seconds) |
| 2026-04-29 20:12:04 +0000 | haskellbridge | (~hackager@96.28.224.214) hackager |
| 2026-04-29 21:06:30 +0000 | vados | (~vados@46-133-1-158.mobile.vf-ua.net) (Read error: Connection reset by peer) |
| 2026-04-29 21:21:17 +0000 | vados | (~vados@46-133-18-172.mobile.vf-ua.net) |