Home liberachat/#xmonad: Logs Calendar

Logs on 2022-09-28 (liberachat/#xmonad)

00:18:58 × jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
00:21:57 jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
00:34:17 sogens joins (~sogens@pa49-182-84-84.pa.qld.optusnet.com.au)
01:07:39 × blaa quits (~bla@79.191.151.138.ipv4.supernova.orange.pl) (Ping timeout: 252 seconds)
01:08:38 bla joins (~bla@79.191.113.111.ipv4.supernova.orange.pl)
02:04:16 × banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 260 seconds)
02:04:25 × sogens quits (~sogens@pa49-182-84-84.pa.qld.optusnet.com.au) (Quit: WeeChat 3.6)
02:09:10 × yosafbridge quits (~yosafbrid@static.38.6.217.95.clients.your-server.de) (Quit: Leaving)
02:15:59 × td_ quits (~td@muedsl-82-207-238-071.citykom.de) (Ping timeout: 265 seconds)
02:17:34 td_ joins (~td@muedsl-82-207-238-028.citykom.de)
02:23:46 banc joins (banc@gateway/vpn/airvpn/banc)
02:25:52 yosafbridge joins (~yosafbrid@static.38.6.217.95.clients.your-server.de)
02:29:53 × bla quits (~bla@79.191.113.111.ipv4.supernova.orange.pl) (Ping timeout: 268 seconds)
02:30:56 blaa joins (~bla@83.24.69.6.ipv4.supernova.orange.pl)
02:48:56 × mvk quits (~mvk@2607:fea8:5ce3:8500::778c) (Ping timeout: 268 seconds)
05:03:15 × jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
05:11:11 jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
05:18:33 <Solid> ChaoticMist[m]: there is a #kmonad channel over at Libera.chat (which should also be bridged to matrix)
05:18:57 <Solid> ChaoticMist[m]: the short answer is that I don't know, since I don't really have a lot of time for the project and David is bopping in and out as always
05:19:22 <Solid> and in the current state (and with his plans for where we're going) I don't think it's wise to do a release right now
05:28:54 × jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
05:30:45 jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
05:38:15 × jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 252 seconds)
06:54:15 QNX is now known as EnchanterTim
07:32:29 chomwitt joins (~chomwitt@2a02:587:dc14:f500:278:be15:4a20:8304)
07:49:41 × dmrz quits (~dmr@c-71-202-36-200.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
08:24:22 Ehllie joins (~Thunderbi@217-67-208-66.itsa.net.pl)
08:28:30 × Ehllie quits (~Thunderbi@217-67-208-66.itsa.net.pl) (Client Quit)
08:39:23 cfricke joins (~cfricke@user/cfricke)
08:50:34 × cfricke quits (~cfricke@user/cfricke) (Quit: WeeChat 3.6)
08:50:43 cfricke joins (~cfricke@user/cfricke)
08:53:14 Ehllie joins (~Thunderbi@217-67-208-66.itsa.net.pl)
08:53:47 × ft quits (~ft@p3e9bc57b.dip0.t-ipconnect.de) (Quit: leaving)
08:54:07 × thunderrd quits (~thunderrd@183.182.111.127) (Ping timeout: 244 seconds)
09:00:14 × liskin[m] quits (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle)
09:16:02 sagax joins (~sagax_nb@user/sagax)
09:16:53 × Ehllie quits (~Thunderbi@217-67-208-66.itsa.net.pl) (Quit: Ehllie)
09:56:38 thyriaen joins (~thyriaen@2a02:8109:8340:686c:7383:e0e2:ad95:9fce)
10:06:09 arslonga[m] joins (~uuuuuuuum@2001:470:69fc:105::1589)
10:46:55 × darkstardevx quits (~darkstard@192.183.207.94) (Ping timeout: 268 seconds)
12:08:03 darkstardevx joins (~darkstard@192.183.207.94)
12:48:43 NONstope[m] joins (~nonstopem@2001:470:69fc:105::2:8d1c)
13:11:28 <geekosaur> hrm. starting to think that bug is related to the weirdie I've been seeing lately
13:11:41 liskin[m] joins (~liskinmat@2001:470:69fc:105::768)
13:11:58 <geekosaur> we haven't made any changes to X.O.windows recently, have we?
13:19:13 <geekosaur> (fwiw: I sometimes have windows that jump around. reliably just after a mod-q, occasionally at other times — except that the ubuntu software update window always does it. I don't think I match that in my manageHook and I'm certain I don't doShift it)
13:36:49 <[Leary]> geekosaur: "that bug"?
13:37:54 <[Leary]> Re windows behaving weird after recompile, one thought is that `read . show` might not be `id` for your layout.
13:48:14 <geekosaur> https://github.com/xmonad/xmonad/issues/422#issuecomment-1260438864
13:48:46 <geekosaur> layout's fine. but first time I switch workspaces the currently focused window goes along with it
13:48:55 <geekosaur> and I have to shift it back
13:49:40 <geekosaur> if I comment out a particular line in my manageHook it stops, but I can't see how the manageHook can be involved in it
13:50:37 <[Leary]> Weird. Show me the line?
13:51:19 <geekosaur> 2 lines, actually, since it wraps. https://github.com/geekosaur/xmonad.hs/blob/skkukuk/xmonad.hs#L161-L162
13:51:36 <geekosaur> but the window is never marked sticky and the manageHook shouldn't be running anyway
13:52:01 <geekosaur> it's *weird*
13:54:13 jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
14:02:52 <[Leary]> geekosaur: So `doF copyToAll` affects the current focus while `doFloatPlace` presumably affects the ManageHook target. Since only one occurs, they should not be the same window. There's no new window (as far as you're concerned) but xmonad thinks there is one---have you checked out what the hook is being given?
14:03:59 <geekosaur> it shouldn't be given anything, unless this is the initial run. but that wouldn't explain the updates window only getting the same behavior
14:04:31 Ehllie joins (~Thunderbi@217-67-208-66.itsa.net.pl)
14:05:03 <geekosaur> also why it would trigger when the condition is false (no windows have STICKY set, I have verified this)
14:05:23 <geekosaur> _NET_WM_STATE_STICKY
14:06:01 <[Leary]> The hook is running; xmonad has to be givin it something. You can catch it and fish it out.
14:07:06 <[Leary]> It sounds to me like there's some phantom window xmonad should be ignoring, but we try to manage it, then it disappears.
14:07:52 <[Leary]> Or something like that.
14:13:23 × Ehllie quits (~Thunderbi@217-67-208-66.itsa.net.pl) (Ping timeout: 248 seconds)
14:21:32 × cfricke quits (~cfricke@user/cfricke) (Quit: WeeChat 3.6)
14:24:25 × hrberg quits (~quassel@171.79-160-161.customer.lyse.net) (Ping timeout: 246 seconds)
14:26:21 <[Leary]> geekosaur: I don't understand how X works without a window manager---in that bug, is it possible that xclock starts before xmonad is ready to catch it, and naively maps itself?
14:26:39 <[Leary]> Since it sounds like the issue there is---rather than not being managed yet---being prematurely mapped.
14:42:49 <geekosaur> I presume PartOf in the systemd unit means it waits until the session is running, but launches it before xmonad
14:43:06 <geekosaur> same thing should happen if you have it in .xinitrc or .xsession before xmonad
14:43:35 <geekosaur> xmonad runs a loop to manage existing windows on startup
14:45:20 <[Leary]> Right, but if it decides that those windows are on an invisible workspace, it won't try to map or unmap them. So if they're already mapped for some reason, they would stay that way.
14:46:04 <[Leary]> Until you switch to the workspace.
14:46:23 <geekosaur> actually, in the normal case it unmaps them because it runs the manageHook on each window it's managing. so the doShift "2" should happen and the window should be unmapped
14:46:28 <geekosaur> this has worked for me in the past
14:47:05 <[Leary]> `doShift "2"` should only unmap if the window was previously visible.
14:47:27 <geekosaur> but it will be, as you just noted, because if there's no wm running it's simply mapped
14:47:47 <geekosaur> then xmonad manages it, shifts it to ws 2, and unmaps it as part of that
14:48:12 <[Leary]> No, here by visible, I mean in a visible workspace. But this is a new window.
14:49:53 <liskin> PartOf mostly just means it will be stopped when the session ends, not that it waits for anything
14:50:25 <liskin> I don't think there's any ordering of xclock/xmonad launch
14:50:34 <liskin> they most likely race each other
14:53:48 <geekosaur> there are no workspaces when the window is mapped; it will become the active workspace when xmonad starts. so everything should work. even if the first thing you do in the startupHook is switch workspaces, because managing is done before running the startupHook
14:55:45 <geekosaur> sadly this means I need to customize ManageDebug to dump the initial manage stuff 😕
14:56:25 <[Leary]> The window is mapped but belongs to no workspace until xmonad manages it. `manage` produces two functions, `g` and `f` from the managehook and it's own insertion logic respectively. But if `g` shifts the window to an invisible workspace, then `windows (g . f)` never sees the window as ever having been anywhere else.
14:57:01 <[Leary]> And hence sees no need to `hide` it.
14:57:18 <geekosaur> reversed, no? but yes, I see that point
14:57:49 <geekosaur> that is, f would be doing the shifting
14:58:02 <geekosaur> but this has worked for me before…
14:58:18 <geekosaur> hm. not sure I've ever done a doShift with it though
14:58:20 <[Leary]> No, `f` puts it in the current workspace, but that's transparently eliminated by the composition.
14:59:00 <[Leary]> Anyway, I think `manage` needs to run `hide` in some circumstances.
14:59:04 <liskin> mapM_ hide (nub (oldvisible ++ newwindows) \\ visible)
14:59:11 <liskin> this should hide it though, shouldn't it?
14:59:52 <liskin> it'll be in newwindows
14:59:59 <liskin> but not in visible
14:59:59 <[Leary]> Hmmm. You might be right.
15:27:05 <geekosaur> modified ManageDebug deployed
15:27:30 <geekosaur> managing new windows happens before the startupHook so I had to change initialValue instead
15:42:04 thunderrd joins (~thunderrd@183.182.115.199)
16:00:13 × liskin[m] quits (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle)
16:45:04 × thunderrd quits (~thunderrd@183.182.115.199) (Remote host closed the connection)
18:18:24 <ChaoticMist[m]> <Solid> "ChaoticMist: there is a #..." <- Good to know, will join that server soon.
19:11:11 hrberg joins (~quassel@171.79-160-161.customer.lyse.net)
19:46:38 dmrz joins (~dmr@c-71-202-36-200.hsd1.ca.comcast.net)
19:55:33 ft joins (~ft@p3e9bc57b.dip0.t-ipconnect.de)
19:58:07 mestre joins (~mestre@191.177.181.194)
21:46:00 sogens joins (sogens@gateway/vpn/protonvpn/sogens)
22:43:31 × chomwitt quits (~chomwitt@2a02:587:dc14:f500:278:be15:4a20:8304) (Ping timeout: 268 seconds)
22:51:24 × nomadxx3 quits (~lanomadx@180-150-32-38.b49620.mel.static.aussiebb.net) (Ping timeout: 265 seconds)
22:55:27 sogens2 joins (~sogens@211.30.49.79)
22:57:40 × sogens quits (sogens@gateway/vpn/protonvpn/sogens) (Ping timeout: 265 seconds)
23:09:16 × sogens2 quits (~sogens@211.30.49.79) (Ping timeout: 265 seconds)
23:10:15 nomadxx3 joins (~lanomadx@208.91.67.130)
23:10:53 sogens2 joins (sogens@gateway/vpn/protonvpn/sogens)
23:22:31 × thyriaen quits (~thyriaen@2a02:8109:8340:686c:7383:e0e2:ad95:9fce) (Quit: Leaving)
23:50:20 × sogens2 quits (sogens@gateway/vpn/protonvpn/sogens) (Quit: WeeChat 3.6)
23:54:49 mvk joins (~mvk@2607:fea8:5ce3:8500::778c)

All times are in UTC on 2022-09-28.