IRCBrowse

2026/03/08

Newest at the top

2026-03-08 04:28:35 +0100tremon(~tremon@83.80.159.219) (Remote host closed the connection)
2026-03-08 01:59:02 +0100stackdroid18(~stackdroi@user/stackdroid) ()
2026-03-08 00:26:53 +0100elarks(~elarks@user/yerrii) (Quit: WeeChat 4.7.1)
2026-03-08 00:04:38 +0100L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2026-03-07 23:23:18 +0100ChubaDuba(~ChubaDuba@46.147.210.92) (Client Quit)
2026-03-07 23:21:27 +0100ChubaDuba(~ChubaDuba@46.147.210.92) ChubaDuba
2026-03-07 23:21:07 +0100ChubaDuba(~ChubaDuba@46.147.210.92) (Quit: WeeChat 4.8.1)
2026-03-07 22:18:52 +0100 <geekosaur> or maybe just use https://hackage.haskell.org/package/xmonad-contrib-0.18.1/docs/XMonad-Hooks-ToggleHook.html
2026-03-07 22:17:05 +0100Digit(~user@user/digit) (Ping timeout: 252 seconds)
2026-03-07 22:17:02 +0100Digitteknohippie(~user@user/digit) Digit
2026-03-07 22:16:51 +0100 <geekosaur> @eldritchcookie, unless what you want to do is float it (in which case you can just use it directly), you could copy and modify https://hackage.haskell.org/package/xmonad-contrib-0.18.1/docs/src/XMonad.Hooks.FloatNext.html
2026-03-07 21:49:27 +0100 <geekosaur> I think there's a contrib that tries the happy-go-lucky "grab the next window that appears and hope it's not a popup" solution
2026-03-07 21:48:48 +0100 <geekosaur> pretty much
2026-03-07 21:47:40 +0100 <haskellbridge> <e​ldritchcookie> so basically if i can neither use _NET_WM_PID or change the class via commandline flag i am cooked?
2026-03-07 21:46:32 +0100 <geekosaur> there are some other potential (but also potentially unreliable) hacks, such as sending all windows `WM_SAVE_YOURSELF` and then iterating over them looking to see if their `WM_COMMAND` (if any) matches what you want
2026-03-07 21:44:07 +0100 <lambdabot> Unknown command, try @list
2026-03-07 21:44:07 +0100 <geekosaur> @eldritchcookie, you basically don't. X11 (nor Wayland for that matter) doesn't provide any hooks to tie a window to what spawned it, and doing so would probably require the kernel to know about either X11 or Wayland and plumb some cookie through `exec`. `_NET_WM_PID` is the conventional userspace hackaround for this.
2026-03-07 21:41:26 +0100RMSBach(~RMSBach@2603:6013:9b00:a7c8:e7e5:f272:eb86:ddf) RMSBach
2026-03-07 21:41:07 +0100RMSBach(~RMSBach@24.210.9.182) (Ping timeout: 264 seconds)
2026-03-07 21:37:49 +0100 <haskellbridge> <S​olid> eldritchcookie: perhaps you can set a WM_CLASS or something?
2026-03-07 21:36:30 +0100 <haskellbridge> <S​olid> btw, a release is probably the best moment to do this! (i plan on sending an invoice myself in a few days, because as i said i think just having the donations lie there unused feels wrong)
2026-03-07 21:34:17 +0100ChubaDuba(~ChubaDuba@46.147.210.92) ChubaDuba
2026-03-07 21:34:11 +0100 <haskellbridge> <e​ldritchcookie> i probably missed something obvious but how do i get the Window if i want to spawn a program? in the edge case that the app doesn't set _NET_WM_PID i can't do anything without assuming the window is tied exactly to the spawning command, i would accept a solution that needs a ManageHook but i also found none
2026-03-07 21:32:48 +0100ChubaDuba(~ChubaDuba@46.147.210.92) (Quit: WeeChat 4.8.1)
2026-03-07 21:27:11 +0100ChubaDuba(~ChubaDuba@46.147.210.92) ChubaDuba
2026-03-07 21:26:49 +0100ChubaDuba(~ChubaDuba@46.147.210.92) (Quit: WeeChat 4.8.1)
2026-03-07 21:21:33 +0100ChubaDuba(~ChubaDuba@46.147.210.92) ChubaDuba
2026-03-07 21:21:15 +0100ChubaDuba(~ChubaDuba@46.147.210.92) (Client Quit)
2026-03-07 21:17:21 +0100ChubaDuba(~ChubaDuba@46.147.210.92) ChubaDuba
2026-03-07 21:16:41 +0100ChubaDuba(~ChubaDuba@46.147.210.92) (Client Quit)
2026-03-07 21:15:13 +0100ChubaDuba(~ChubaDuba@46.147.210.92) ChubaDuba
2026-03-07 21:14:30 +0100ChubaDuba(~ChubaDuba@46.147.210.92) (Quit: WeeChat 4.8.1)
2026-03-07 21:08:05 +0100 <geekosaur> oh right, I remember: changed it to support `XMONAD_XMESSAGE`. (and I still wonder if we should refactor so core's xmessage wrapper is part of the API, but IIRC most contrib uses of xmessage don't fit how it works)
2026-03-07 21:02:42 +0100 <haskellbridge> <S​olid> i think this has to be done manually, though, so maybe it has to wait for tomorrow (unless you want to take a stab)
2026-03-07 21:02:07 +0100 <haskellbridge> <S​olid> yeah, maybe it's a good idea to bump extras as well in that case
2026-03-07 20:53:23 +0100 <geekosaur> although it's low priority iirc
2026-03-07 20:53:13 +0100 <geekosaur> come to think of it, I think there's something in xmonad-extras I submitted recently along with the CI fixes
2026-03-07 20:52:45 +0100 <geekosaur> do we need to release any of the other dependencies? (I don't recall anything off hand except one, but I think we released that immediately afterward)
2026-03-07 20:50:14 +0100ft(~ft@p4fc2a98c.dip0.t-ipconnect.de) ft
2026-03-07 20:30:46 +0100 <haskellbridge> <S​olid> even xmonad-docs updated without a hitch
2026-03-07 20:30:46 +0100 <haskellbridge> <S​olid> I _think_ everything should be good
2026-03-07 20:11:37 +0100elarks(~elarks@user/yerrii) yerrii
2026-03-07 20:08:10 +0100stackdroid18(~stackdroi@user/stackdroid) stackdroid
2026-03-07 19:53:35 +0100 <geekosaur> (come to think of it, I think the most recent one didn't get recorded so I should go do that now)
2026-03-07 19:52:21 +0100 <geekosaur> (said notes perhaps belong in the wiki; we've started doing that with cabal and it's gradually helping although we're still finding gotchas)
2026-03-07 19:52:10 +0100 <haskellbridge> <S​olid> that is very true :D
2026-03-07 19:51:26 +0100 <geekosaur> take notes: iirc we always manage to miss something or do something out of order ☺
2026-03-07 19:45:09 +0100 <haskellbridge> <S​olid> should hopefully not take all that long
2026-03-07 19:44:52 +0100haskellbridgeS​olid is slowly reminding himself of the release procedure now
2026-03-07 18:58:14 +0100mkoskar(notroot@user/mkoskar) mkoskar