IRCBrowse

2021/12/20

2021-12-20 00:26:59 +0100seschwar(~seschwar@user/seschwar) (Quit: :wq)
2021-12-20 00:41:15 +0100geekosaur(~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
2021-12-20 00:42:55 +0100geekosaur(~geekosaur@xmonad/geekosaur)
2021-12-20 01:37:49 +0100obimod(~obimod@gateway/vpn/pia/obimod) (Ping timeout: 240 seconds)
2021-12-20 01:52:17 +0100obimod(~obimod@gateway/vpn/pia/obimod)
2021-12-20 03:20:06 +0100steve__(~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 256 seconds)
2021-12-20 03:53:15 +0100geekosaur(~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
2021-12-20 03:55:46 +0100geekosaur(~geekosaur@xmonad/geekosaur)
2021-12-20 04:03:44 +0100banc(banc@gateway/vpn/airvpn/banc) (Ping timeout: 256 seconds)
2021-12-20 04:20:07 +0100td_(~td@muedsl-82-207-238-128.citykom.de) (Ping timeout: 268 seconds)
2021-12-20 04:21:23 +0100td_(~td@94.134.91.10)
2021-12-20 04:24:20 +0100banc(banc@gateway/vpn/airvpn/banc)
2021-12-20 04:39:27 +0100Nahra(~user@static.161.95.99.88.clients.your-server.de) (Remote host closed the connection)
2021-12-20 04:42:57 +0100terrorjack(~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat)
2021-12-20 04:45:22 +0100terrorjack(~terrorjac@2a01:4f8:1c1e:509a::1)
2021-12-20 04:52:32 +0100catman(~catman@user/catman) (Quit: WeeChat 3.4-rc1)
2021-12-20 04:54:15 +0100catman(~catman@user/catman)
2021-12-20 05:14:22 +0100abhixec(~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
2021-12-20 05:30:00 +0100abhixec(~abhixec@c-67-169-139-16.hsd1.ca.comcast.net)
2021-12-20 05:41:46 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 256 seconds)
2021-12-20 05:43:38 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2021-12-20 05:44:27 +0100jludwig(~justin@user/jludwig) (Read error: Connection reset by peer)
2021-12-20 05:46:32 +0100catman(~catman@user/catman) (Read error: Connection reset by peer)
2021-12-20 05:47:25 +0100jludwig(~justin@user/jludwig)
2021-12-20 05:48:33 +0100jludwig(~justin@user/jludwig) (Client Quit)
2021-12-20 05:54:55 +0100catman(~catman@user/catman)
2021-12-20 05:57:27 +0100jludwig(~justin@user/jludwig)
2021-12-20 07:27:12 +0100dschrempf(~dominik@070-207.dynamic.dsl.fonira.net)
2021-12-20 07:27:56 +0100dschrempf(~dominik@070-207.dynamic.dsl.fonira.net) (Client Quit)
2021-12-20 07:36:10 +0100obimod(~obimod@gateway/vpn/pia/obimod) (Ping timeout: 260 seconds)
2021-12-20 07:38:07 +0100obimod(~obimod@gateway/vpn/pia/obimod)
2021-12-20 08:39:42 +0100obimod(~obimod@gateway/vpn/pia/obimod) (Ping timeout: 256 seconds)
2021-12-20 09:11:57 +0100mvk(~mvk@2607:fea8:5cdd:f000::917a) (Ping timeout: 240 seconds)
2021-12-20 09:15:34 +0100obimod(~obimod@gateway/vpn/pia/obimod)
2021-12-20 09:17:18 +0100dschrempf(~dominik@070-207.dynamic.dsl.fonira.net)
2021-12-20 09:42:29 +0100cfricke(~cfricke@user/cfricke)
2021-12-20 09:44:34 +0100dschrempf(~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3)
2021-12-20 10:08:45 +0100geekosaur(~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
2021-12-20 10:09:32 +0100cfricke(~cfricke@user/cfricke) (Ping timeout: 240 seconds)
2021-12-20 10:10:38 +0100geekosaur(~geekosaur@xmonad/geekosaur)
2021-12-20 10:11:35 +0100cfricke(~cfricke@user/cfricke)
2021-12-20 10:17:25 +0100geekosaur(~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
2021-12-20 10:17:35 +0100geekosaur(~geekosaur@xmonad/geekosaur)
2021-12-20 11:18:59 +0100Guest41(~Guest41@2001:818:e6b0:dc00:5bdd:c700:4598:fbea)
2021-12-20 11:19:11 +0100Guest41(~Guest41@2001:818:e6b0:dc00:5bdd:c700:4598:fbea) ()
2021-12-20 12:09:19 +0100dschrempf(~dominik@070-207.dynamic.dsl.fonira.net)
2021-12-20 12:15:17 +0100ft(~ft@shell.chaostreff-dortmund.de) (Quit: leaving)
2021-12-20 12:15:28 +0100ft(~ft@shell.chaostreff-dortmund.de)
2021-12-20 12:41:17 +0100dschrempf(~dominik@070-207.dynamic.dsl.fonira.net) (Ping timeout: 240 seconds)
2021-12-20 13:42:22 +0100ebray187(~ebray187@2800:150:129:17c4:224:1dff:fed5:599e)
2021-12-20 14:00:14 +0100benin(~benin@183.82.27.121) (Ping timeout: 260 seconds)
2021-12-20 14:02:52 +0100benin(~benin@183.82.27.121)
2021-12-20 14:06:08 +0100dschrempf(~dominik@070-207.dynamic.dsl.fonira.net)
2021-12-20 14:08:11 +0100cfricke(~cfricke@user/cfricke) (Quit: WeeChat 3.3)
2021-12-20 14:34:12 +0100obimod(~obimod@gateway/vpn/pia/obimod) (Remote host closed the connection)
2021-12-20 14:34:32 +0100obimod(~obimod@gateway/vpn/pia/obimod)
2021-12-20 16:50:19 +0100mc47(~mc47@xmonad/TheMC47)
2021-12-20 17:26:41 +0100seschwar(~seschwar@user/seschwar)
2021-12-20 17:28:45 +0100geekosaur(~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
2021-12-20 17:30:26 +0100geekosaur(~geekosaur@xmonad/geekosaur)
2021-12-20 18:46:38 +0100mvk(~mvk@2607:fea8:5cdd:f000::917a)
2021-12-20 18:51:32 +0100geekosaur(~geekosaur@xmonad/geekosaur) (Quit: Leaving)
2021-12-20 18:52:37 +0100geekosaur(~geekosaur@xmonad/geekosaur)
2021-12-20 19:18:20 +0100obimod(~obimod@gateway/vpn/pia/obimod) (Ping timeout: 256 seconds)
2021-12-20 19:18:39 +0100obimod(~obimod@gateway/vpn/pia/obimod)
2021-12-20 19:22:24 +0100dschrempf(~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3)
2021-12-20 19:29:29 +0100dschrempf(~dominik@070-207.dynamic.dsl.fonira.net)
2021-12-20 19:32:06 +0100benin(~benin@183.82.27.121) (Quit: The Lounge - https://thelounge.chat)
2021-12-20 19:52:15 +0100steve__(~steve@ool-182c2b80.dyn.optonline.net)
2021-12-20 20:35:00 +0100ectospasm(~ectospasm@user/ectospasm) (Quit: WeeChat 3.3)
2021-12-20 20:47:53 +0100steve___(~steve@public-gprs384252.centertel.pl)
2021-12-20 21:03:22 +0100samhh(7569f027cf@2604:bf00:561:2000::e4) (Read error: Connection reset by peer)
2021-12-20 21:03:29 +0100samhh_(7569f027cf@2604:bf00:561:2000::e4)
2021-12-20 21:03:44 +0100samhh_samhh
2021-12-20 21:16:28 +0100ectospasm(~ectospasm@user/ectospasm)
2021-12-20 21:45:57 +0100obimod(~obimod@gateway/vpn/pia/obimod) (Ping timeout: 240 seconds)
2021-12-20 21:47:00 +0100 <geekosaur> noex, I've thought some more about that screen boundaries thing. I think it's not really solvable :(
2021-12-20 21:47:24 +0100 <geekosaur> the suggestion I had earlier is subject to two async race conditions and a TOCTOU
2021-12-20 21:48:39 +0100 <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
2021-12-20 21:50:11 +0100 <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
2021-12-20 21:52:01 +0100Guest99(~Guest99@2600:1700:3790:39c0::3e)
2021-12-20 21:52:13 +0100Guest99(~Guest99@2600:1700:3790:39c0::3e) (Client Quit)
2021-12-20 22:00:27 +0100obimod(~obimod@gateway/vpn/pia/obimod)
2021-12-20 22:33:35 +0100 <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?
2021-12-20 22:36:55 +0100 <geekosaur> that is possible but will confuse a lot of programs even more than they already are by a nonreparenting window manager :)
2021-12-20 22:37:19 +0100 <geekosaur> also any program that expects its top level window to be a top level window
2021-12-20 22:38:24 +0100 <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
2021-12-20 22:41:15 +0100 <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)
2021-12-20 22:42:26 +0100 <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.
2021-12-20 22:42:26 +0100 <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
2021-12-20 22:43:39 +0100isovector1(~isovector@172.103.216.166.cable.tpia.cipherkey.com)
2021-12-20 22:44:34 +0100 <geekosaur> the problem is a reparenting wm only puts a frame around the window, not the whole root window
2021-12-20 22:44:34 +0100 <isovector1> i'm trying to use Xmonad.Hooks.StatusBar to run xmobar, but it just silently doesn't start xmobar
2021-12-20 22:44:40 +0100 <isovector1> any suggestions for how to diagnose the problem?
2021-12-20 22:45:05 +0100 <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
2021-12-20 22:45:08 +0100 <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 22:46:13 +0100 <kwer[m]> So in essence we would just have a "big frame", right?
2021-12-20 22:46:17 +0100 <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 22:46:39 +0100 <geekosaur> kwer[m], yes but programs will fail to expect that the same way they fail to expect no frame
2021-12-20 22:47:02 +0100 <geekosaur> in particular I expect to discover new and exciting failure modes for JVM canvases :)
2021-12-20 22:47:56 +0100 <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 22:48:30 +0100 <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 22:49:26 +0100 <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 22:50:27 +0100 <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 22:50:44 +0100 <kwer[m]> geekosaur: Yes indeed
2021-12-20 22:52:23 +0100 <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 22:52:33 +0100 <geekosaur> and then xmonad ends up out of sync wiht it
2021-12-20 22:52:35 +0100 <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 22:54:02 +0100 <isovector1> kwer[m]: afaict the basic statusbar machinery isnt working at all
2021-12-20 22:54:23 +0100sagax(~sagax_nb@user/sagax) (Ping timeout: 250 seconds)
2021-12-20 22:54:35 +0100 <isovector1> like withSB seems to do nothing
2021-12-20 22:56:31 +0100 <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 22:57:03 +0100 <geekosaur> isovector1, I'd check the session log (.xsession-errors, usually) for any error messages
2021-12-20 22:57:38 +0100 <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 22:58:24 +0100 <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 22:58:30 +0100 <kwer[m]> Oh that's interesting, I didn't know that.
2021-12-20 22:59:13 +0100 <geekosaur> this is the race that can only be fixed by changing xmonad's core
2021-12-20 23:01:40 +0100 <isovector1> "xmobar: eof at an early stage"
2021-12-20 23:02:23 +0100 <geekosaur> o.O I thought that was an xmobar bug that had been fixed some time ago
2021-12-20 23:07:55 +0100 <kwer[m]> isovector1: What does your `main` function look like?
2021-12-20 23:09:16 +0100 <isovector1> https://gist.github.com/isovector/c99a77da4a0645ba7cf59b34c1c9e6fc#file-xmonad-hs-L280-L306
2021-12-20 23:12:02 +0100 <kwer[m]> I only see one status bar there. Didn't you say the problem occurs when you have multiple?
2021-12-20 23:12:14 +0100 <isovector1> no
2021-12-20 23:12:32 +0100 <isovector1> the problem occurs when i use Xmonad.Hooks.StatusBar
2021-12-20 23:12:41 +0100 <kwer[m]> Ah gotcha
2021-12-20 23:12:45 +0100 <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 23:13:08 +0100isovector1(~isovector@172.103.216.166.cable.tpia.cipherkey.com) (Remote host closed the connection)
2021-12-20 23:13:19 +0100 <geekosaur> whoops?
2021-12-20 23:14:13 +0100isovector1(~isovector@172.103.216.166)
2021-12-20 23:14:23 +0100 <isovector1> accidentally killed xmonad forcefully :)
2021-12-20 23:14:31 +0100 <kwer[m]> :D
2021-12-20 23:15:14 +0100 <isovector1> okay so looks like removing StdinReader from xmobar gets it to start properly
2021-12-20 23:15:59 +0100 <isovector1> but now it just says Updating... and doesn't show me my workspaces
2021-12-20 23:17:13 +0100 <isovector1> user error :)
2021-12-20 23:17:27 +0100 <isovector1> okay great! got it running on one screen. back to where i started :)
2021-12-20 23:17:34 +0100 <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 23:17:50 +0100geekosaurwas just about to mention that
2021-12-20 23:18:03 +0100 <geekosaur> the *second* one gets withSB
2021-12-20 23:18:10 +0100steve___(~steve@public-gprs384252.centertel.pl) (Quit: Lost terminal)
2021-12-20 23:18:15 +0100 <geekosaur> the first one needs withEasySB to do the basic plumbing
2021-12-20 23:18:28 +0100 <isovector1> yeah the docs are not particularly amenable to skimming
2021-12-20 23:21:08 +0100 <isovector1> okay everything is up and running
2021-12-20 23:21:09 +0100 <isovector1> thanks all
2021-12-20 23:21:12 +0100 <kwer[m]> Haha, yeah, all the time I've lost that way sigh. But glad to hear it's working now!
2021-12-20 23:23:37 +0100 <isovector1> does xmobarrc get parsed as an actual hs file? can i do like where bindings?
2021-12-20 23:23:52 +0100 <isovector1> my assumption is that it's just being `read`
2021-12-20 23:24:20 +0100 <geekosaur> it just looks like haskell
2021-12-20 23:24:34 +0100 <geekosaur> although xmobar has a mode where it can be configured in actual haskell
2021-12-20 23:24:51 +0100 <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 23:26:08 +0100 <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 23:26:56 +0100 <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 23:29:13 +0100 <geekosaur> mm, actually the spec says if the window's on the bottom it should stay there
2021-12-20 23:29:23 +0100 <geekosaur> now the question is whether xorg obeys the spec :)
2021-12-20 23:29:26 +0100 <isovector1> yall have a prefer tray?
2021-12-20 23:29:28 +0100 <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 23:29:39 +0100 <geekosaur> but if it's tru then we could get away with this without a core change
2021-12-20 23:31:50 +0100 <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 23:32:35 +0100 <isovector1> kwer[m]: sounds good to me. does it show the tray on multiple screens?
2021-12-20 23:32:57 +0100 <kwer[m]> Hmm, never tried that
2021-12-20 23:33:13 +0100 <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 23:33:28 +0100 <geekosaur> too many programs make specific assumptions about reparenting
2021-12-20 23:33:48 +0100 <geekosaur> and an xmonad which does reparenting could break things much worse than one which never reparents
2021-12-20 23:33:54 +0100 <kwer[m]> I can imagine
2021-12-20 23:33:57 +0100 <geekosaur> *does weird reparenting
2021-12-20 23:36:41 +0100 <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 23:38:40 +0100dschrempf(~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3)
2021-12-20 23:45:11 +0100mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2021-12-20 23:45:57 +0100 <geekosaur> yes
2021-12-20 23:46:11 +0100 <geekosaur> and ignore CrossingEvents for the focused screen
2021-12-20 23:46:19 +0100 <geekosaur> since we're already there
2021-12-20 23:46:36 +0100 <geekosaur> althoiugh possibly it's not worth ignoring them
2021-12-20 23:48:17 +0100 <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 23:48:35 +0100isovector1(~isovector@172.103.216.166) (Quit: Leaving)
2021-12-20 23:49:59 +0100geekosaur(~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
2021-12-20 23:50:19 +0100geekosaur(~geekosaur@xmonad/geekosaur)
2021-12-20 23:51:23 +0100 <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 23:52:19 +0100 <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