Logs: liberachat/#xmonad
| 2021-12-20 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 |
| 2021-12-20 21:46:13 | <kwer[m]> | So in essence we would just have a "big frame", right? |
| 2021-12-20 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) |
| 2021-12-20 21:46:39 | <geekosaur> | kwer[m], yes but programs will fail to expect that the same way they fail to expect no frame |
| 2021-12-20 21:47:02 | <geekosaur> | in particular I expect to discover new and exciting failure modes for JVM canvases :) |
| 2021-12-20 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 |
| 2021-12-20 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 |
| 2021-12-20 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" |
| 2021-12-20 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 |
| 2021-12-20 21:50:44 | <kwer[m]> | geekosaur: Yes indeed |
| 2021-12-20 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 |
| 2021-12-20 21:52:33 | <geekosaur> | and then xmonad ends up out of sync wiht it |
| 2021-12-20 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? |
| 2021-12-20 21:54:02 | <isovector1> | kwer[m]: afaict the basic statusbar machinery isnt working at all |
| 2021-12-20 21:54:23 | × | sagax quits (~sagax_nb@user/sagax) (Ping timeout: 250 seconds) |
| 2021-12-20 21:54:35 | <isovector1> | like withSB seems to do nothing |
| 2021-12-20 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? |
| 2021-12-20 21:57:03 | <geekosaur> | isovector1, I'd check the session log (.xsession-errors, usually) for any error messages |
| 2021-12-20 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 |
| 2021-12-20 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 |
| 2021-12-20 21:58:30 | <kwer[m]> | Oh that's interesting, I didn't know that. |
| 2021-12-20 21:59:13 | <geekosaur> | this is the race that can only be fixed by changing xmonad's core |
| 2021-12-20 22:01:40 | <isovector1> | "xmobar: eof at an early stage" |
| 2021-12-20 22:02:23 | <geekosaur> | o.O I thought that was an xmobar bug that had been fixed some time ago |
| 2021-12-20 22:07:55 | <kwer[m]> | isovector1: What does your `main` function look like? |
| 2021-12-20 22:09:16 | <isovector1> | https://gist.github.com/isovector/c99a77da4a0645ba7cf59b34c1c9e6fc#file-xmonad-hs-L280-L306 |
| 2021-12-20 22:12:02 | <kwer[m]> | I only see one status bar there. Didn't you say the problem occurs when you have multiple? |
| 2021-12-20 22:12:14 | <isovector1> | no |
| 2021-12-20 22:12:32 | <isovector1> | the problem occurs when i use Xmonad.Hooks.StatusBar |
| 2021-12-20 22:12:41 | <kwer[m]> | Ah gotcha |
| 2021-12-20 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 |
| 2021-12-20 22:13:08 | × | isovector1 quits (~isovector@172.103.216.166.cable.tpia.cipherkey.com) (Remote host closed the connection) |
| 2021-12-20 22:13:19 | <geekosaur> | whoops? |
| 2021-12-20 22:14:13 | → | isovector1 joins (~isovector@172.103.216.166) |
| 2021-12-20 22:14:23 | <isovector1> | accidentally killed xmonad forcefully :) |
| 2021-12-20 22:14:31 | <kwer[m]> | :D |
| 2021-12-20 22:15:14 | <isovector1> | okay so looks like removing StdinReader from xmobar gets it to start properly |
| 2021-12-20 22:15:59 | <isovector1> | but now it just says Updating... and doesn't show me my workspaces |
| 2021-12-20 22:17:13 | <isovector1> | user error :) |
| 2021-12-20 22:17:27 | <isovector1> | okay great! got it running on one screen. back to where i started :) |
| 2021-12-20 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 |
| 2021-12-20 22:17:50 | geekosaur | was just about to mention that |
| 2021-12-20 22:18:03 | <geekosaur> | the *second* one gets withSB |
| 2021-12-20 22:18:10 | × | steve___ quits (~steve@public-gprs384252.centertel.pl) (Quit: Lost terminal) |
| 2021-12-20 22:18:15 | <geekosaur> | the first one needs withEasySB to do the basic plumbing |
| 2021-12-20 22:18:28 | <isovector1> | yeah the docs are not particularly amenable to skimming |
| 2021-12-20 22:21:08 | <isovector1> | okay everything is up and running |
| 2021-12-20 22:21:09 | <isovector1> | thanks all |
| 2021-12-20 22:21:12 | <kwer[m]> | Haha, yeah, all the time I've lost that way sigh. But glad to hear it's working now! |
| 2021-12-20 22:23:37 | <isovector1> | does xmobarrc get parsed as an actual hs file? can i do like where bindings? |
| 2021-12-20 22:23:52 | <isovector1> | my assumption is that it's just being `read` |
| 2021-12-20 22:24:20 | <geekosaur> | it just looks like haskell |
| 2021-12-20 22:24:34 | <geekosaur> | although xmobar has a mode where it can be configured in actual haskell |
| 2021-12-20 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. |
| 2021-12-20 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 |
| 2021-12-20 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 |
| 2021-12-20 22:29:13 | <geekosaur> | mm, actually the spec says if the window's on the bottom it should stay there |
| 2021-12-20 22:29:23 | <geekosaur> | now the question is whether xorg obeys the spec :) |
| 2021-12-20 22:29:26 | <isovector1> | yall have a prefer tray? |
| 2021-12-20 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? |
| 2021-12-20 22:29:39 | <geekosaur> | but if it's tru then we could get away with this without a core change |
| 2021-12-20 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. |
| 2021-12-20 22:32:35 | <isovector1> | kwer[m]: sounds good to me. does it show the tray on multiple screens? |
| 2021-12-20 22:32:57 | <kwer[m]> | Hmm, never tried that |
| 2021-12-20 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 |
| 2021-12-20 22:33:28 | <geekosaur> | too many programs make specific assumptions about reparenting |
| 2021-12-20 22:33:48 | <geekosaur> | and an xmonad which does reparenting could break things much worse than one which never reparents |
| 2021-12-20 22:33:54 | <kwer[m]> | I can imagine |
| 2021-12-20 22:33:57 | <geekosaur> | *does weird reparenting |
| 2021-12-20 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? |
| 2021-12-20 22:38:40 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3) |
| 2021-12-20 22:45:11 | × | mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2021-12-20 22:45:57 | <geekosaur> | yes |
| 2021-12-20 22:46:11 | <geekosaur> | and ignore CrossingEvents for the focused screen |
| 2021-12-20 22:46:19 | <geekosaur> | since we're already there |
| 2021-12-20 22:46:36 | <geekosaur> | althoiugh possibly it's not worth ignoring them |
| 2021-12-20 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 |
| 2021-12-20 22:48:35 | × | isovector1 quits (~isovector@172.103.216.166) (Quit: Leaving) |
| 2021-12-20 22:49:59 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-12-20 22:50:19 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2021-12-20 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 |
| 2021-12-20 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 |
| 2021-12-20 23:00:04 | × | seschwar quits (~seschwar@user/seschwar) (Quit: :wq) |
| 2021-12-20 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) |
| 2021-12-20 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) |
| 2021-12-20 23:21:26 | <geekosaur> | There's an existing utility function to create windows in XMonad.Util.XUtils, although it only creates InputOutput windows |
| 2021-12-20 23:21:38 | <geekosaur> | you could however copy that code to create an InputOnly window |
| 2021-12-20 23:22:26 | <kwer[m]> | Ah see, I knew you'd have some good input. Thanks, I'll have a look! |
| 2021-12-20 23:56:37 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2021-12-20 23:58:42 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2021-12-21 00:01:52 | × | MrElendig quits (~Urist@archlinux/op/MrElendig) (Quit: ww3 starting) |
| 2021-12-21 00:03:28 | → | MrElendig joins (~Urist@archlinux/op/MrElendig) |
| 2021-12-21 01:15:39 | × | defjam quits (~eb0t@90.210.94.161) (Ping timeout: 250 seconds) |
| 2021-12-21 01:21:18 | → | defjam joins (~eb0t@90.198.61.46) |
| 2021-12-21 01:50:28 | × | abhixec quits (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Quit: leaving) |
| 2021-12-21 02:07:17 | × | aplainzetakind quits (~johndoe@captainludd.powered.by.lunarbnc.net) (Ping timeout: 268 seconds) |
| 2021-12-21 02:13:29 | → | berberman_ joins (~berberman@user/berberman) |
| 2021-12-21 02:14:32 | × | berberman quits (~berberman@user/berberman) (Ping timeout: 240 seconds) |
| 2021-12-21 03:02:01 | → | aplainzetakind joins (~johndoe@captainludd.powered.by.lunarbnc.net) |
| 2021-12-21 03:02:57 | × | banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 240 seconds) |
All times are in UTC.