| 2022-09-28 00:29:58 +0200 | mikevan[m] | (~mikevanto@2001:470:69fc:105::2:7ef5) (Ping timeout: 246 seconds) |
| 2022-09-28 00:30:10 +0200 | mikevan[m] | (~mikevanto@2001:470:69fc:105::2:7ef5) |
| 2022-09-28 02:18:58 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-09-28 02:21:57 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-09-28 02:34:17 +0200 | sogens | (~sogens@pa49-182-84-84.pa.qld.optusnet.com.au) |
| 2022-09-28 03:07:39 +0200 | blaa | (~bla@79.191.151.138.ipv4.supernova.orange.pl) (Ping timeout: 252 seconds) |
| 2022-09-28 03:08:38 +0200 | bla | (~bla@79.191.113.111.ipv4.supernova.orange.pl) |
| 2022-09-28 04:04:16 +0200 | banc | (banc@gateway/vpn/airvpn/banc) (Ping timeout: 260 seconds) |
| 2022-09-28 04:04:25 +0200 | sogens | (~sogens@pa49-182-84-84.pa.qld.optusnet.com.au) (Quit: WeeChat 3.6) |
| 2022-09-28 04:09:10 +0200 | yosafbridge | (~yosafbrid@static.38.6.217.95.clients.your-server.de) (Quit: Leaving) |
| 2022-09-28 04:15:59 +0200 | td_ | (~td@muedsl-82-207-238-071.citykom.de) (Ping timeout: 265 seconds) |
| 2022-09-28 04:17:34 +0200 | td_ | (~td@muedsl-82-207-238-028.citykom.de) |
| 2022-09-28 04:23:46 +0200 | banc | (banc@gateway/vpn/airvpn/banc) |
| 2022-09-28 04:25:52 +0200 | yosafbridge | (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
| 2022-09-28 04:29:53 +0200 | bla | (~bla@79.191.113.111.ipv4.supernova.orange.pl) (Ping timeout: 268 seconds) |
| 2022-09-28 04:30:56 +0200 | blaa | (~bla@83.24.69.6.ipv4.supernova.orange.pl) |
| 2022-09-28 04:48:56 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) (Ping timeout: 268 seconds) |
| 2022-09-28 07:03:15 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-09-28 07:11:11 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-09-28 07:18:33 +0200 | <Solid> | ChaoticMist[m]: there is a #kmonad channel over at Libera.chat (which should also be bridged to matrix) |
| 2022-09-28 07:18:57 +0200 | <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 |
| 2022-09-28 07:19:22 +0200 | <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 |
| 2022-09-28 07:28:54 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-09-28 07:30:45 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-09-28 07:38:15 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2022-09-28 08:54:15 +0200 | QNX | EnchanterTim |
| 2022-09-28 09:32:29 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:278:be15:4a20:8304) |
| 2022-09-28 09:49:41 +0200 | dmrz | (~dmr@c-71-202-36-200.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 2022-09-28 10:24:22 +0200 | Ehllie | (~Thunderbi@217-67-208-66.itsa.net.pl) |
| 2022-09-28 10:28:30 +0200 | Ehllie | (~Thunderbi@217-67-208-66.itsa.net.pl) (Client Quit) |
| 2022-09-28 10:39:23 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-09-28 10:50:34 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.6) |
| 2022-09-28 10:50:43 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-09-28 10:53:14 +0200 | Ehllie | (~Thunderbi@217-67-208-66.itsa.net.pl) |
| 2022-09-28 10:53:47 +0200 | ft | (~ft@p3e9bc57b.dip0.t-ipconnect.de) (Quit: leaving) |
| 2022-09-28 10:54:07 +0200 | thunderrd | (~thunderrd@183.182.111.127) (Ping timeout: 244 seconds) |
| 2022-09-28 11:00:14 +0200 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle) |
| 2022-09-28 11:16:02 +0200 | sagax | (~sagax_nb@user/sagax) |
| 2022-09-28 11:16:53 +0200 | Ehllie | (~Thunderbi@217-67-208-66.itsa.net.pl) (Quit: Ehllie) |
| 2022-09-28 11:56:38 +0200 | thyriaen | (~thyriaen@2a02:8109:8340:686c:7383:e0e2:ad95:9fce) |
| 2022-09-28 12:06:09 +0200 | arslonga[m] | (~uuuuuuuum@2001:470:69fc:105::1589) |
| 2022-09-28 12:46:55 +0200 | darkstardevx | (~darkstard@192.183.207.94) (Ping timeout: 268 seconds) |
| 2022-09-28 14:08:03 +0200 | darkstardevx | (~darkstard@192.183.207.94) |
| 2022-09-28 14:48:43 +0200 | NONstope[m] | (~nonstopem@2001:470:69fc:105::2:8d1c) |
| 2022-09-28 15:11:28 +0200 | <geekosaur> | hrm. starting to think that bug is related to the weirdie I've been seeing lately |
| 2022-09-28 15:11:41 +0200 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) |
| 2022-09-28 15:11:58 +0200 | <geekosaur> | we haven't made any changes to X.O.windows recently, have we? |
| 2022-09-28 15:19:13 +0200 | <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) |
| 2022-09-28 15:36:49 +0200 | <[Leary]> | geekosaur: "that bug"? |
| 2022-09-28 15:37:54 +0200 | <[Leary]> | Re windows behaving weird after recompile, one thought is that `read . show` might not be `id` for your layout. |
| 2022-09-28 15:48:14 +0200 | <geekosaur> | https://github.com/xmonad/xmonad/issues/422#issuecomment-1260438864 |
| 2022-09-28 15:48:46 +0200 | <geekosaur> | layout's fine. but first time I switch workspaces the currently focused window goes along with it |
| 2022-09-28 15:48:55 +0200 | <geekosaur> | and I have to shift it back |
| 2022-09-28 15:49:40 +0200 | <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 |
| 2022-09-28 15:50:37 +0200 | <[Leary]> | Weird. Show me the line? |
| 2022-09-28 15:51:19 +0200 | <geekosaur> | 2 lines, actually, since it wraps. https://github.com/geekosaur/xmonad.hs/blob/skkukuk/xmonad.hs#L161-L162 |
| 2022-09-28 15:51:36 +0200 | <geekosaur> | but the window is never marked sticky and the manageHook shouldn't be running anyway |
| 2022-09-28 15:52:01 +0200 | <geekosaur> | it's *weird* |
| 2022-09-28 15:54:13 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-09-28 16:02:52 +0200 | <[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? |
| 2022-09-28 16:03:59 +0200 | <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 |
| 2022-09-28 16:04:31 +0200 | Ehllie | (~Thunderbi@217-67-208-66.itsa.net.pl) |
| 2022-09-28 16:05:03 +0200 | <geekosaur> | also why it would trigger when the condition is false (no windows have STICKY set, I have verified this) |
| 2022-09-28 16:05:23 +0200 | <geekosaur> | _NET_WM_STATE_STICKY |
| 2022-09-28 16:06:01 +0200 | <[Leary]> | The hook is running; xmonad has to be givin it something. You can catch it and fish it out. |
| 2022-09-28 16:07:06 +0200 | <[Leary]> | It sounds to me like there's some phantom window xmonad should be ignoring, but we try to manage it, then it disappears. |
| 2022-09-28 16:07:52 +0200 | <[Leary]> | Or something like that. |
| 2022-09-28 16:13:23 +0200 | Ehllie | (~Thunderbi@217-67-208-66.itsa.net.pl) (Ping timeout: 248 seconds) |
| 2022-09-28 16:21:32 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.6) |
| 2022-09-28 16:24:25 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) (Ping timeout: 246 seconds) |
| 2022-09-28 16:26:21 +0200 | <[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? |
| 2022-09-28 16:26:39 +0200 | <[Leary]> | Since it sounds like the issue there is---rather than not being managed yet---being prematurely mapped. |
| 2022-09-28 16:42:49 +0200 | <geekosaur> | I presume PartOf in the systemd unit means it waits until the session is running, but launches it before xmonad |
| 2022-09-28 16:43:06 +0200 | <geekosaur> | same thing should happen if you have it in .xinitrc or .xsession before xmonad |
| 2022-09-28 16:43:35 +0200 | <geekosaur> | xmonad runs a loop to manage existing windows on startup |
| 2022-09-28 16:45:20 +0200 | <[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. |
| 2022-09-28 16:46:04 +0200 | <[Leary]> | Until you switch to the workspace. |
| 2022-09-28 16:46:23 +0200 | <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 |
| 2022-09-28 16:46:28 +0200 | <geekosaur> | this has worked for me in the past |
| 2022-09-28 16:47:05 +0200 | <[Leary]> | `doShift "2"` should only unmap if the window was previously visible. |
| 2022-09-28 16:47:27 +0200 | <geekosaur> | but it will be, as you just noted, because if there's no wm running it's simply mapped |
| 2022-09-28 16:47:47 +0200 | <geekosaur> | then xmonad manages it, shifts it to ws 2, and unmaps it as part of that |
| 2022-09-28 16:48:12 +0200 | <[Leary]> | No, here by visible, I mean in a visible workspace. But this is a new window. |
| 2022-09-28 16:49:53 +0200 | <liskin> | PartOf mostly just means it will be stopped when the session ends, not that it waits for anything |
| 2022-09-28 16:50:25 +0200 | <liskin> | I don't think there's any ordering of xclock/xmonad launch |
| 2022-09-28 16:50:34 +0200 | <liskin> | they most likely race each other |
| 2022-09-28 16:53:48 +0200 | <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 |
| 2022-09-28 16:55:45 +0200 | <geekosaur> | sadly this means I need to customize ManageDebug to dump the initial manage stuff 😕 |
| 2022-09-28 16:56:25 +0200 | <[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. |
| 2022-09-28 16:57:01 +0200 | <[Leary]> | And hence sees no need to `hide` it. |
| 2022-09-28 16:57:18 +0200 | <geekosaur> | reversed, no? but yes, I see that point |
| 2022-09-28 16:57:49 +0200 | <geekosaur> | that is, f would be doing the shifting |
| 2022-09-28 16:58:02 +0200 | <geekosaur> | but this has worked for me before… |
| 2022-09-28 16:58:18 +0200 | <geekosaur> | hm. not sure I've ever done a doShift with it though |
| 2022-09-28 16:58:20 +0200 | <[Leary]> | No, `f` puts it in the current workspace, but that's transparently eliminated by the composition. |
| 2022-09-28 16:59:00 +0200 | <[Leary]> | Anyway, I think `manage` needs to run `hide` in some circumstances. |
| 2022-09-28 16:59:04 +0200 | <liskin> | mapM_ hide (nub (oldvisible ++ newwindows) \\ visible) |
| 2022-09-28 16:59:11 +0200 | <liskin> | this should hide it though, shouldn't it? |
| 2022-09-28 16:59:52 +0200 | <liskin> | it'll be in newwindows |
| 2022-09-28 16:59:59 +0200 | <liskin> | but not in visible |
| 2022-09-28 16:59:59 +0200 | <[Leary]> | Hmmm. You might be right. |
| 2022-09-28 17:27:05 +0200 | <geekosaur> | modified ManageDebug deployed |
| 2022-09-28 17:27:30 +0200 | <geekosaur> | managing new windows happens before the startupHook so I had to change initialValue instead |
| 2022-09-28 17:42:04 +0200 | thunderrd | (~thunderrd@183.182.115.199) |
| 2022-09-28 18:00:13 +0200 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle) |
| 2022-09-28 18:45:04 +0200 | thunderrd | (~thunderrd@183.182.115.199) (Remote host closed the connection) |
| 2022-09-28 20:18:24 +0200 | <ChaoticMist[m]> | <Solid> "ChaoticMist: there is a #..." <- Good to know, will join that server soon. |
| 2022-09-28 21:11:11 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) |
| 2022-09-28 21:46:38 +0200 | dmrz | (~dmr@c-71-202-36-200.hsd1.ca.comcast.net) |
| 2022-09-28 21:55:33 +0200 | ft | (~ft@p3e9bc57b.dip0.t-ipconnect.de) |
| 2022-09-28 21:58:07 +0200 | mestre | (~mestre@191.177.181.194) |
| 2022-09-28 23:46:00 +0200 | sogens | (sogens@gateway/vpn/protonvpn/sogens) |