| 2025-10-03 00:00:42 +0200 | <rascasse> | and with XLibre remixing the cards, there is still good hope for the future of X11 wms |
| 2025-10-03 00:02:28 +0200 | <geekosaur> | hah, I was hoping someone would do that |
| 2025-10-03 00:03:03 +0200 | <geekosaur> | that said, the X11 protocol needs a fair amount of work to fix various shortcomings (like, font handling between my three monitors) |
| 2025-10-03 00:04:39 +0200 | <rascasse> | yea I think XLibre is really a good news for that, the activity is quite good, checking at the progress so far, it's gaining some traction |
| 2025-10-03 00:05:34 +0200 | <rascasse> | Im about to swith my laptop soon tbh |
| 2025-10-03 00:05:41 +0200 | <rascasse> | on xlibre |
| 2025-10-03 00:06:17 +0200 | <rascasse> | Xmonad has already been reported working |
| 2025-10-03 00:06:58 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
| 2025-10-03 00:26:46 +0200 | rascasse | (~rascasse@user/diep) (Ping timeout: 255 seconds) |
| 2025-10-03 00:47:30 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-10-03 01:18:35 +0200 | rascasse | (~rascasse@user/diep) diep |
| 2025-10-03 01:20:34 +0200 | rascasse | (~rascasse@user/diep) (Remote host closed the connection) |
| 2025-10-03 03:52:42 +0200 | haskellbridge | (~hackager@syn-096-028-224-214.res.spectrum.com) (Remote host closed the connection) |
| 2025-10-03 03:53:49 +0200 | haskellbridge | (~hackager@syn-096-028-224-214.res.spectrum.com) hackager |
| 2025-10-03 04:44:25 +0200 | td_ | (~td@i53870901.versanet.de) (Ping timeout: 264 seconds) |
| 2025-10-03 04:46:01 +0200 | td_ | (~td@i5387093E.versanet.de) |
| 2025-10-03 07:06:58 +0200 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Quit: Done for the day!) |
| 2025-10-03 07:34:24 +0200 | redgloboli | (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2025-10-03 07:35:59 +0200 | redgloboli | (~redglobol@user/redgloboli) redgloboli |
| 2025-10-03 09:59:30 +0200 | <haskellbridge> | <Solid> XLibre looks like a joke and not something one should put their hopes on |
| 2025-10-03 10:08:57 +0200 | ximon | (~ximon@user/ximon) ximon |
| 2025-10-03 10:23:07 +0200 | ximon | (~ximon@user/ximon) (Ping timeout: 250 seconds) |
| 2025-10-03 10:23:30 +0200 | <deepy> | It looks to be run by possibly the least pleasant people you'd be able to find, and who instead of acknowledging the issues with X11 instead blames it on some "woke agenda" |
| 2025-10-03 12:19:00 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
| 2025-10-03 12:57:15 +0200 | <haskellbridge> | <Solid> Yeah, if you're that much of an asshole you get kicked out of contributing to X11 of all things, then I certainly don't want to use your fork either |
| 2025-10-03 13:42:55 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-10-03 15:09:31 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
| 2025-10-03 15:18:18 +0200 | ft | (~ft@p4fc2a225.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2025-10-03 15:18:18 +0200 | srk | (~sorki@user/srk) (Ping timeout: 264 seconds) |
| 2025-10-03 15:18:18 +0200 | byorgey | (~byorgey@user/byorgey) (Ping timeout: 264 seconds) |
| 2025-10-03 15:18:24 +0200 | srk | (~sorki@user/srk) srk |
| 2025-10-03 15:18:30 +0200 | ft | (~ft@p4fc2a225.dip0.t-ipconnect.de) ft |
| 2025-10-03 15:18:33 +0200 | byorgey | (~byorgey@155.138.238.211) |
| 2025-10-03 15:18:33 +0200 | byorgey | (~byorgey@155.138.238.211) (Changing host) |
| 2025-10-03 15:18:33 +0200 | byorgey | (~byorgey@user/byorgey) byorgey |
| 2025-10-03 15:19:24 +0200 | bla | (~bla@91.234.125.131) |
| 2025-10-03 15:20:09 +0200 | ChubaDuba | (~ChubaDuba@5.3.233.76) ChubaDuba |
| 2025-10-03 15:21:01 +0200 | blaa | (~bla@91.234.125.131) (Ping timeout: 264 seconds) |
| 2025-10-03 15:38:52 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-10-03 16:21:34 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
| 2025-10-03 16:22:06 +0200 | <Enrico63> | geekosaur, I've understood what was going on! |
| 2025-10-03 16:30:00 +0200 | <geekosaur> | sigh so still waiting, not that I'm hopeful for much. anyone who can't see that there are actual problems with x11 isn't wworth considering |
| 2025-10-03 16:30:36 +0200 | <Enrico63> | And yes, it's due to mixing threads and processes. |
| 2025-10-03 16:30:37 +0200 | <Enrico63> | Xmobar plugins can be clickable, just in the sense that you can attach some command to be spawned when you click on them; but you can't feed that click back into the plugin. So my plugin does a weird thing to work around the limitation. It uses to click to write into a pipe, while another thread blocks in reading from that pipe. So I have a `cat` |
| 2025-10-03 16:30:37 +0200 | <Enrico63> | process 99.99% of the time blocked waiting for something to be written to the pipe (this is by design, I couldn't think of another way). I've verified that after reproducing the bug, as soon as I echo something into the spurious pipe, cat completes, and the DBus name is freed. |
| 2025-10-03 16:30:38 +0200 | <Enrico63> | Now I suppose an easy fix would be not to spawn a `cat` process to read from the pipe but just an async thread blocking on `readFile` or something. But I'm still curious to understand why `kill -KILL $(pidof xmobar)` results in killing the child `cat` process spawned (hence no bug woudl be triggered), but exiting XMonad leaves that `cat` process |
| 2025-10-03 16:30:38 +0200 | <Enrico63> | orphan |
| 2025-10-03 16:38:21 +0200 | <geekosaur> | you missed two of us explaining that |
| 2025-10-03 16:39:10 +0200 | <geekosaur> | xmonad doesn't kill anything on exit, there's no chance to do so. if you exit the X session then anything woth a connection to the X server will exit, but neither cat nor your notification server has a connection |
| 2025-10-03 16:39:20 +0200 | <geekosaur> | dbus runs continuously so it won't disconnect anything eother |
| 2025-10-03 16:39:47 +0200 | <geekosaur> | (when you mod-q restart, the killing is done by the new xmonad, not the old) |
| 2025-10-03 16:46:07 +0200 | <Enrico63> | Well, what can I say? I'm sorry for not understanding? '=D |
| 2025-10-03 16:50:42 +0200 | <Enrico63> | There's still things I don't quite get yet. Why killing the parent process (i.e. xmobar) of the `cat` process that is causing the problem, also causes `cat` to terminate, whereas exiting the parent process (by exiting X ) doesn't? |
| 2025-10-03 16:51:50 +0200 | <Enrico63> | Is it that kill will look for children processes and kill them too, whereas a process, when exiting, has to actively decide wether to shut down processes it has spawned? |
| 2025-10-03 16:57:57 +0200 | <Enrico63> | No, I'm saying BS, once a process spawns another one it doesn't have a handle on it to control it. Ok I think I understand now. |
| 2025-10-03 16:58:41 +0200 | <Enrico63> | Apologies for not understanding yesterday explanation, but thanks |
| 2025-10-03 17:12:15 +0200 | <liskin> | That sounds like processes spawned from your xmobar inherit it's fds |
| 2025-10-03 17:12:27 +0200 | <liskin> | It's possible to mark fds as close-on-exec |
| 2025-10-03 17:12:44 +0200 | <liskin> | *its |
| 2025-10-03 17:13:21 +0200 | <liskin> | Also I'd probably consider using something else than pipes for that comms |
| 2025-10-03 17:13:38 +0200 | <liskin> | Like, I dunno, dbus since you have that anyway? Or X props. |
| 2025-10-03 17:35:19 +0200 | <Enrico63> | In my usecase a mouse click on the plugin spawns an `echo` that puts some info somewhere, but then another process has to be waiting to read that info. The pipe gave me the advantage that I wouldn't have to poll "is the info there?", because reading from it would block. It felt convenient. |
| 2025-10-03 17:35:19 +0200 | <Enrico63> | That would not be possible with x props, no? |
| 2025-10-03 17:36:03 +0200 | <Enrico63> | The click happens only when I want to dismiss a notification, if any ever comes up. |
| 2025-10-03 17:41:34 +0200 | ChubaDuba | (~ChubaDuba@5.3.233.76) (Quit: WeeChat 4.6.3) |
| 2025-10-03 17:55:52 +0200 | T_X | (~T_X@diktynna.open-mesh.org) (Read error: Connection reset by peer) |
| 2025-10-03 17:56:02 +0200 | T_X | (~T_X@diktynna.open-mesh.org) T_X |
| 2025-10-03 18:14:47 +0200 | ml| | (~ml|@user/ml/x-5298235) (Ping timeout: 244 seconds) |
| 2025-10-03 18:28:56 +0200 | ml| | (~ml|@user/ml/x-5298235) ml| |
| 2025-10-03 19:09:16 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-10-03 19:18:12 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
| 2025-10-03 20:02:38 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-10-03 20:56:50 +0200 | <liskin> | Depends on what's on the other side |
| 2025-10-03 20:57:39 +0200 | <liskin> | Don't think you need to block but also don't know how easy it is to listen for something else than a pipe |
| 2025-10-03 21:15:03 +0200 | zeniegirl | (~EricaLina@user/zengirl) zengirl |
| 2025-10-03 21:16:25 +0200 | zeniegirl | (~EricaLina@user/zengirl) (ERC 5.6.1-git (IRC client for GNU Emacs 31.0.50)) |
| 2025-10-03 23:04:51 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |