Logs on 2021-12-20 (liberachat/#xmonad)
| 00:37:49 | × | obimod quits (~obimod@gateway/vpn/pia/obimod) (Ping timeout: 240 seconds) |
| 00:52:17 | → | obimod joins (~obimod@gateway/vpn/pia/obimod) |
| 02:20:06 | × | steve__ quits (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 256 seconds) |
| 02:53:15 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 02:55:46 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 03:03:44 | × | banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 256 seconds) |
| 03:20:07 | × | td_ quits (~td@muedsl-82-207-238-128.citykom.de) (Ping timeout: 268 seconds) |
| 03:21:23 | → | td_ joins (~td@94.134.91.10) |
| 03:24:20 | → | banc joins (banc@gateway/vpn/airvpn/banc) |
| 03:39:27 | × | Nahra quits (~user@static.161.95.99.88.clients.your-server.de) (Remote host closed the connection) |
| 03:42:57 | × | terrorjack quits (~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat) |
| 03:45:22 | → | terrorjack joins (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 03:52:32 | × | catman quits (~catman@user/catman) (Quit: WeeChat 3.4-rc1) |
| 03:54:15 | → | catman joins (~catman@user/catman) |
| 04:14:22 | × | abhixec quits (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Read error: Connection reset by peer) |
| 04:30:00 | → | abhixec joins (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) |
| 04:41:46 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 04:43:38 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 04:44:27 | × | jludwig quits (~justin@user/jludwig) (Read error: Connection reset by peer) |
| 04:46:32 | × | catman quits (~catman@user/catman) (Read error: Connection reset by peer) |
| 04:47:25 | → | jludwig joins (~justin@user/jludwig) |
| 04:48:33 | × | jludwig quits (~justin@user/jludwig) (Client Quit) |
| 04:54:55 | → | catman joins (~catman@user/catman) |
| 04:57:27 | → | jludwig joins (~justin@user/jludwig) |
| 06:27:12 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 06:27:56 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Client Quit) |
| 06:36:10 | × | obimod quits (~obimod@gateway/vpn/pia/obimod) (Ping timeout: 260 seconds) |
| 06:38:07 | → | obimod joins (~obimod@gateway/vpn/pia/obimod) |
| 07:39:42 | × | obimod quits (~obimod@gateway/vpn/pia/obimod) (Ping timeout: 256 seconds) |
| 08:11:57 | × | mvk quits (~mvk@2607:fea8:5cdd:f000::917a) (Ping timeout: 240 seconds) |
| 08:15:34 | → | obimod joins (~obimod@gateway/vpn/pia/obimod) |
| 08:17:18 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 08:42:29 | → | cfricke joins (~cfricke@user/cfricke) |
| 08:44:34 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3) |
| 09:08:45 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 09:09:32 | × | cfricke quits (~cfricke@user/cfricke) (Ping timeout: 240 seconds) |
| 09:10:38 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 09:11:35 | → | cfricke joins (~cfricke@user/cfricke) |
| 09:17:25 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 09:17:35 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 10:18:59 | → | Guest41 joins (~Guest41@2001:818:e6b0:dc00:5bdd:c700:4598:fbea) |
| 10:19:11 | ← | Guest41 parts (~Guest41@2001:818:e6b0:dc00:5bdd:c700:4598:fbea) () |
| 11:09:19 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 11:15:17 | × | ft quits (~ft@shell.chaostreff-dortmund.de) (Quit: leaving) |
| 11:15:28 | → | ft joins (~ft@shell.chaostreff-dortmund.de) |
| 11:41:17 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Ping timeout: 240 seconds) |
| 12:42:22 | → | ebray187 joins (~ebray187@2800:150:129:17c4:224:1dff:fed5:599e) |
| 13:00:14 | × | benin quits (~benin@183.82.27.121) (Ping timeout: 260 seconds) |
| 13:02:52 | → | benin joins (~benin@183.82.27.121) |
| 13:06:08 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 13:08:11 | × | cfricke quits (~cfricke@user/cfricke) (Quit: WeeChat 3.3) |
| 13:34:12 | × | obimod quits (~obimod@gateway/vpn/pia/obimod) (Remote host closed the connection) |
| 13:34:32 | → | obimod joins (~obimod@gateway/vpn/pia/obimod) |
| 15:50:19 | → | mc47 joins (~mc47@xmonad/TheMC47) |
| 16:26:41 | → | seschwar joins (~seschwar@user/seschwar) |
| 16:28:45 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 16:30:26 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 17:46:38 | → | mvk joins (~mvk@2607:fea8:5cdd:f000::917a) |
| 17:51:32 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Quit: Leaving) |
| 17:52:37 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 18:18:20 | × | obimod quits (~obimod@gateway/vpn/pia/obimod) (Ping timeout: 256 seconds) |
| 18:18:39 | → | obimod joins (~obimod@gateway/vpn/pia/obimod) |
| 18:22:24 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3) |
| 18:29:29 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 18:32:06 | × | benin quits (~benin@183.82.27.121) (Quit: The Lounge - https://thelounge.chat) |
| 18:52:15 | → | steve__ joins (~steve@ool-182c2b80.dyn.optonline.net) |
| 19:35:00 | × | ectospasm quits (~ectospasm@user/ectospasm) (Quit: WeeChat 3.3) |
| 19:47:53 | → | steve___ joins (~steve@public-gprs384252.centertel.pl) |
| 20:03:22 | × | samhh quits (7569f027cf@2604:bf00:561:2000::e4) (Read error: Connection reset by peer) |
| 20:03:29 | → | samhh_ joins (7569f027cf@2604:bf00:561:2000::e4) |
| 20:03:44 | samhh_ | is now known as samhh |
| 20:16:28 | → | ectospasm joins (~ectospasm@user/ectospasm) |
| 20:45:57 | × | obimod quits (~obimod@gateway/vpn/pia/obimod) (Ping timeout: 240 seconds) |
| 20:47:00 | <geekosaur> | noex, I've thought some more about that screen boundaries thing. I think it's not really solvable :( |
| 20:47:24 | <geekosaur> | the suggestion I had earlier is subject to two async race conditions and a TOCTOU |
| 20:48:39 | <geekosaur> | the first async race can be fixed by putting InoutOnly windows over all screens and ignoring CrossingEvents for xmonad's idea of the current screen. the second requires a core change to avoid, the restackWindows call in X.O.Windows needs to know about the InputOnly screen so it stays on top |
| 20:50:11 | <geekosaur> | but then we have the last problem: we never get CrossingEvents for user windows because they all go to the InputOnly window, so now we have to monitor events on that and focus the window under it — which means delayed response and potential flickering, and degrades to monitoring mouse movement always worst-case |
| 20:52:01 | → | Guest99 joins (~Guest99@2600:1700:3790:39c0::3e) |
| 20:52:13 | × | Guest99 quits (~Guest99@2600:1700:3790:39c0::3e) (Client Quit) |
| 21:00:27 | → | obimod joins (~obimod@gateway/vpn/pia/obimod) |
| 21:33:35 | <kwer[m]> | Hmm that's a shame. I'm not at all an expert on X11 (and I'm barely familiar with it) but if we are allowing to change stuff in core and if I understand things correctly, instead of overlaying an InputOnly window over every screen and then trying to route inputs through, wouldn't it be possible to instead have one workspace-root window per workspace and make each other window on that workspace a child of it? |
| 21:36:55 | <geekosaur> | that is possible but will confuse a lot of programs even more than they already are by a nonreparenting window manager :) |
| 21:37:19 | <geekosaur> | also any program that expects its top level window to be a top level window |
| 21:38:24 | <geekosaur> | hypothetically we could put the focus-screen window on the bottom instead of the top, but that still leaves the other two issues plus raises some questions about how this interacts with docks and desktop windows |
| 21:41:15 | <geekosaur> | and desktop windows may not work as an alternative to the InputOnly window because at least some desktop managers spread it over all screens (since they assume the window manager manages all screens as a single workspace) |
| 21:42:26 | <kwer[m]> | Haha, I can only imagine how much cursing there must be as a developer of one of those programs when your users start reporting issues with fringe window managers :D. |
| 21:42:26 | <kwer[m]> | But wouldn't it actually more resemble what a reparenting window manager does if one made the top-level window of each application a child of the workspace-root? Pardon my ignorance if I'm misunderstanding what a reparenting WM does |
| 21:43:39 | → | isovector1 joins (~isovector@172.103.216.166.cable.tpia.cipherkey.com) |
| 21:44:34 | <geekosaur> | the problem is a reparenting wm only puts a frame around the window, not the whole root window |
| 21:44:34 | <isovector1> | i'm trying to use Xmonad.Hooks.StatusBar to run xmobar, but it just silently doesn't start xmobar |
| 21:44:40 | <isovector1> | any suggestions for how to diagnose the problem? |
| 21:45:05 | <geekosaur> | and this will badly confuse programs like the JVM, which expect to skipthe frame window to figure out where to draw on a canvas window |
| 21:45:08 | <isovector1> | everything was working fine with the old loghook based setup, but i wanted to get the status bar on every screen |
| 21:46:13 | <kwer[m]> | So in essence we would just have a "big frame", right? |
| 21:46:17 | <geekosaur> | isovector1, I don't really know the StatusBar stuff (and can't use it since I talk to my status bar over dbus) |
| 21:46:39 | <geekosaur> | kwer[m], yes but programs will fail to expect that the same way they fail to expect no frame |
| 21:47:02 | <geekosaur> | in particular I expect to discover new and exciting failure modes for JVM canvases :) |
| 21:47:56 | <geekosaur> | also I'm nt sure "make parent of" is even necessary; just having it underneath should be enough, without confusing other programs in the process |
| 21:48:30 | <geekosaur> | still would need to hack X.O.windows to force the window to be on the bottom (instead of the top) of the z-order |
| 21:49:26 | <kwer[m]> | Ah I understand your point now. Yeah, it seems a bit risky to put a change like that in core then. Especially if you say that one can expect a lot of applications breaking that were doing just fine for years. And there's no way one could so something like that in contrib? Like just do that yourself and add a logHook that reparents whenever you're moving a window to another workspace? At least then it would be kind of "at your own risk" |
| 21:50:27 | <kwer[m]> | geekosaur: Yeah, I thought the same but I didn't see any CrossingEvents triggered for clipped windows when I tried |
| 21:50:44 | <kwer[m]> | geekosaur: Yes indeed |
| 21:52:23 | <geekosaur> | the logHook has a race condition. during the short period of time between the restackWindows in X.O.windows and the logHook, the mouse may be moved in a way which requires either your reparenting thing or just having the InputOnly window in the correct z-order |
| 21:52:33 | <geekosaur> | and then xmonad ends up out of sync wiht it |
| 21:52:35 | <kwer[m]> | <isovector1> "everything was working fine with..." <- I'm not using xmobar myself but I assume you've had a look at https://xmonad.github.io/xmonad-docs/xmonad-contrib/XMonad-Hooks-StatusBar.html#g:3? |
| 21:54:02 | <isovector1> | kwer[m]: afaict the basic statusbar machinery isnt working at all |
| 21:54:23 | × | sagax quits (~sagax_nb@user/sagax) (Ping timeout: 250 seconds) |
| 21:54:35 | <isovector1> | like withSB seems to do nothing |
| 21:56:31 | <kwer[m]> | geekosaur: Ah I see the problem. I can't say that I'm very familiar with how asynchronous things in xmonad are. I just assumed everything was single threaded and events handled in order but I guess then it's some kind of interrupt based system? |
| 21:57:03 | <geekosaur> | isovector1, I'd check the session log (.xsession-errors, usually) for any error messages |
| 21:57:38 | <geekosaur> | kwer[m], the problem is not with xmonad as such. the problem is that mouse movement is completely asynchronous and on most systems processed on the gpu instead of the cpu |
| 21:58:24 | <geekosaur> | so mouse actions and resulting events happen at any time regardless of xmonad's state, and if xmonad has not yet had a chance to set up to receive an event it wants, it will lose |
| 21:58:30 | <kwer[m]> | Oh that's interesting, I didn't know that. |
| 21:59:13 | <geekosaur> | this is the race that can only be fixed by changing xmonad's core |
| 22:01:40 | <isovector1> | "xmobar: eof at an early stage" |
| 22:02:23 | <geekosaur> | o.O I thought that was an xmobar bug that had been fixed some time ago |
| 22:07:55 | <kwer[m]> | isovector1: What does your `main` function look like? |
| 22:09:16 | <isovector1> | https://gist.github.com/isovector/c99a77da4a0645ba7cf59b34c1c9e6fc#file-xmonad-hs-L280-L306 |
| 22:12:02 | <kwer[m]> | I only see one status bar there. Didn't you say the problem occurs when you have multiple? |
| 22:12:14 | <isovector1> | no |
| 22:12:32 | <isovector1> | the problem occurs when i use Xmonad.Hooks.StatusBar |
| 22:12:41 | <kwer[m]> | Ah gotcha |
| 22:12:45 | <geekosaur> | no, they said they switched to StatusBar so they could set up multiple, but can't get it to work at all |
| 22:13:08 | × | isovector1 quits (~isovector@172.103.216.166.cable.tpia.cipherkey.com) (Remote host closed the connection) |
| 22:13:19 | <geekosaur> | whoops? |
| 22:14:13 | → | isovector1 joins (~isovector@172.103.216.166) |
| 22:14:23 | <isovector1> | accidentally killed xmonad forcefully :) |
| 22:14:31 | <kwer[m]> | :D |
| 22:15:14 | <isovector1> | okay so looks like removing StdinReader from xmobar gets it to start properly |
| 22:15:59 | <isovector1> | but now it just says Updating... and doesn't show me my workspaces |
| 22:17:13 | <isovector1> | user error :) |
| 22:17:27 | <isovector1> | okay great! got it running on one screen. back to where i started :) |
| 22:17:34 | <kwer[m]> | I'm just taking wild guesses here but I see you're using `withSB` and not `withEasySB`. There is a little paragraph below that saying that you need to properly set up xmobar for that |
| 22:17:50 | geekosaur | was just about to mention that |
| 22:18:03 | <geekosaur> | the *second* one gets withSB |
| 22:18:10 | × | steve___ quits (~steve@public-gprs384252.centertel.pl) (Quit: Lost terminal) |
| 22:18:15 | <geekosaur> | the first one needs withEasySB to do the basic plumbing |
| 22:18:28 | <isovector1> | yeah the docs are not particularly amenable to skimming |
| 22:21:08 | <isovector1> | okay everything is up and running |
| 22:21:09 | <isovector1> | thanks all |
| 22:21:12 | <kwer[m]> | Haha, yeah, all the time I've lost that way sigh. But glad to hear it's working now! |
| 22:23:37 | <isovector1> | does xmobarrc get parsed as an actual hs file? can i do like where bindings? |
| 22:23:52 | <isovector1> | my assumption is that it's just being `read` |
| 22:24:20 | <geekosaur> | it just looks like haskell |
| 22:24:34 | <geekosaur> | although xmobar has a mode where it can be configured in actual haskell |
| 22:24:51 | <kwer[m]> | <geekosaur> "so mouse actions and resulting..." <- Sorry for being dense but can you give me a concrete example of what could happen in this race condition? I do understand what you're saying about `windows` and see that it does call `restackWindows` but I can't quite picture the problem. Specifically, if I hit Mod+1 to move a window to workspace 1 manually, we're also calling `windows` and there doesn't seem to be a problem with that. |
| 22:26:08 | <geekosaur> | there isn't one currently. there would be if we placed an additional window just to capture CrossingEvents, because it would not be restacked with the others and its resulting position would be indeterminate |
| 22:26:56 | <geekosaur> | it could end up on top (and then moving the mouse into windows on that screen would fail) or on bottom (where we want it) or potentially somewhere in the middle since its position wasn't specified in the restacking |
| 22:29:13 | <geekosaur> | mm, actually the spec says if the window's on the bottom it should stay there |
| 22:29:23 | <geekosaur> | now the question is whether xorg obeys the spec :) |
| 22:29:26 | <isovector1> | yall have a prefer tray? |
| 22:29:28 | <kwer[m]> | Ahhhh, now I see what you mean. But surely, in my approach with reparenting that wouldn't be an issue, right? I thought children are always hiding their parents, no? |
| 22:29:39 | <geekosaur> | but if it's tru then we could get away with this without a core change |
| 22:31:50 | <kwer[m]> | isovector1: I just use trayer. Picked it a long time ago (more or less randomly) and just stuck with it because it does its job and I never had any issues. |
| 22:32:35 | <isovector1> | kwer[m]: sounds good to me. does it show the tray on multiple screens? |
| 22:32:57 | <kwer[m]> | Hmm, never tried that |
| 22:33:13 | <geekosaur> | child windows are clipped to their parent's bounding box, which is near enough the same thing. I still suspect we discover new failure modes for reparenting if you try that, so I'd prefer to try the other first |
| 22:33:28 | <geekosaur> | too many programs make specific assumptions about reparenting |
| 22:33:48 | <geekosaur> | and an xmonad which does reparenting could break things much worse than one which never reparents |
| 22:33:54 | <kwer[m]> | I can imagine |
| 22:33:57 | <geekosaur> | *does weird reparenting |
| 22:36:41 | <kwer[m]> | So to summarise what you're suggesting: Put an InputOnly window at the bottom of each screen and monitor CrossingEvents for those to figure out which screen the mouse is on? |
| 22:38:40 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3) |
| 22:45:11 | × | mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 22:45:57 | <geekosaur> | yes |
| 22:46:11 | <geekosaur> | and ignore CrossingEvents for the focused screen |
| 22:46:19 | <geekosaur> | since we're already there |
| 22:46:36 | <geekosaur> | althoiugh possibly it's not worth ignoring them |
| 22:48:17 | <kwer[m]> | Yeah, that's really a minor question, I think. First I'll have to figure out how to set these things up properly. Lots of digging to do in the X11 documentation |
| 22:48:35 | × | isovector1 quits (~isovector@172.103.216.166) (Quit: Leaving) |
| 22:49:59 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 22:50:19 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 22:51:23 | <geekosaur> | well, actually we ignore them because it'll always be a crossing-out and won't tell us enough enough to know where it's going to; a CrossingEvent on another screen, on the other hand, tells us we just crossed into it |
| 22:52:19 | <geekosaur> | so if we paid attention to a CrossingEvent on the focused screen we might force focus back to the screen you just left, whoops |
| 23:00:04 | × | seschwar quits (~seschwar@user/seschwar) (Quit: :wq) |
| 23:18:53 | <kwer[m]> | geekosaur: I hope you don't mind me asking but I'm kind of struggling to create an empty window (not even thinking about InputOnly yet) from within xmonad as I don't really have low-level X11 experience. If it's too much hassle, I'm sure I can figure it out by myself as well but my guess is that you might be able to point... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/494cdce39b62a60fa47e24762e4f9f7ecfde52ee) |
| 23:19:08 | <kwer[m]> | * geekosaur: I hope you don't mind me asking but I'm kind of struggling to create an empty window (not even thinking about InputOnly yet) from within xmonad as I don't really have low-level X11 experience. If it's too much hassle, I'm sure I can figure it out by myself as well but my guess is that you might be able to... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/7cb1c97cf732b39e2416a576364440ca04b1e314) |
| 23:21:26 | <geekosaur> | There's an existing utility function to create windows in XMonad.Util.XUtils, although it only creates InputOutput windows |
| 23:21:38 | <geekosaur> | you could however copy that code to create an InputOnly window |
| 23:22:26 | <kwer[m]> | Ah see, I knew you'd have some good input. Thanks, I'll have a look! |
| 23:56:37 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 23:58:42 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
All times are in UTC on 2021-12-20.