| 2025-08-15 01:43:12 +0200 | tremon | (~tremon@83.80.159.219) (Ping timeout: 252 seconds) |
| 2025-08-15 02:12:19 +0200 | tv | (~tv@user/tv) (Read error: Connection reset by peer) |
| 2025-08-15 02:16:10 +0200 | tremon | (~tremon@83.80.159.219) tremon |
| 2025-08-15 03:01:57 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 260 seconds) |
| 2025-08-15 03:03:11 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-08-15 03:32:17 +0200 | ft | (~ft@p508dba54.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-08-15 03:33:52 +0200 | ft | (~ft@p508db692.dip0.t-ipconnect.de) ft |
| 2025-08-15 04:11:04 +0200 | td_ | (~td@i53870938.versanet.de) (Ping timeout: 260 seconds) |
| 2025-08-15 04:12:46 +0200 | td_ | (~td@i53870931.versanet.de) |
| 2025-08-15 04:21:55 +0200 | tremon | (~tremon@83.80.159.219) (Remote host closed the connection) |
| 2025-08-15 04:28:13 +0200 | weitcis | (~quassel@syn-172-091-071-027.res.spectrum.com) |
| 2025-08-15 04:28:51 +0200 | gauge | (~gauge@user/gauge) (Read error: Connection reset by peer) |
| 2025-08-15 04:32:34 +0200 | gauge | (~gauge@user/gauge) gauge |
| 2025-08-15 05:02:43 +0200 | dpn | (~dpn@121-44-66-107.tpgi.com.au) dpn` |
| 2025-08-15 05:04:56 +0200 | <dpn> | moin - for the life of me I can't figure out why my manageHook is not working with xfce4-notifyd notifications https://gist.github.com/dpnova/b03c7dbb536ddaf731d7bd6d141fdca3 |
| 2025-08-15 05:06:02 +0200 | <geekosaur> | classNames are usually uppercase initial. you could also try XMonad.Hooks.ManageDebug to see what the manageHook actually sees |
| 2025-08-15 05:06:50 +0200 | <dpn> | ah - xprop had both listed... it doesn't work with either |
| 2025-08-15 05:07:00 +0200 | <dpn> | TIL about managedebug, thanks |
| 2025-08-15 05:07:27 +0200 | <geekosaur> | right, the property contains appName and className in that order |
| 2025-08-15 05:07:46 +0200 | <dpn> | i noticed I'm not explicitly starting notifyd myself in my xmonad session rc or my config... I dont think startup order would impact this though |
| 2025-08-15 05:07:57 +0200 | <dpn> | ahh... another TIL thanks! |
| 2025-08-15 05:08:26 +0200 | <haskellbridge> | <iqubic (she/her)> What does XMonad.Action.CopyWindow do? Surely you can't tell XOrg to draw the same window in multiple places on the screen. |
| 2025-08-15 05:09:02 +0200 | <dpn> | and now it's working... i swear it was capitalised when i started trying to figure this out earlier... either way, this explains weirdness with manageHook i've had in the past haha. Thanks heaps for the help! |
| 2025-08-15 05:09:25 +0200 | <geekosaur> | no, it'll only place it at the last place it's told to. but it makes a window "sticky" in the sense that it will be displayed on all workspaces |
| 2025-08-15 05:10:08 +0200 | <geekosaur> | or to specific workspaces (copyWindow copies to a specific workspace, copyToAll copies to all workspaces) |
| 2025-08-15 05:10:22 +0200 | <haskellbridge> | <iqubic (she/her)> That's neat! |
| 2025-08-15 05:12:43 +0200 | <haskellbridge> | <iqubic (she/her)> One thing I still need to do is figure out if it's possible to create a manageHook for Firefox's Picture-In-Picture popout. I want that to float and be in the lower corner and a few other things. I guess the way to handle that would be to xprop the window and check for a property that's different from the main firefox window's properties to isolate that window. |
| 2025-08-15 05:12:52 +0200 | <haskellbridge> | <iqubic (she/her)> I can do that on my own. I have the skills. |
| 2025-08-15 05:15:11 +0200 | <geekosaur> | or you could use debugManageHookOn and press the key sequence you selected before popping it out |
| 2025-08-15 05:15:23 +0200 | <geekosaur> | which is the main reason I wrote ManageDebug |
| 2025-08-15 05:15:26 +0200 | <haskellbridge> | <iqubic (she/her)> Oh, I didn't know about that. |
| 2025-08-15 05:15:40 +0200 | <haskellbridge> | <iqubic (she/her)> dpn: You are importing CopyWindows twice. |
| 2025-08-15 05:15:55 +0200 | <haskellbridge> | <iqubic (she/her)> I'm not sure that's a problem, but it is something with an easy fix. |
| 2025-08-15 05:17:40 +0200 | <dpn> | sorry using catgirl and didn't realise the brige messages were a portal - where's the other end? |
| 2025-08-15 05:17:50 +0200 | <geekosaur> | it's not a problem, and both hlint and I think ghc (with -Wall) will warn you |
| 2025-08-15 05:18:21 +0200 | <haskellbridge> | <iqubic (she/her)> I'm using matrix via Element's Web client. |
| 2025-08-15 05:18:54 +0200 | <dpn> | ahh cool - I really want to use matrix more... usually an up hill battle trying to convince other people to |
| 2025-08-15 05:19:04 +0200 | <haskellbridge> | <iqubic (she/her)> When I use things like debugManageNextWindow, where do the messages get put? Does XMonad have a log file? |
| 2025-08-15 05:19:05 +0200 | <geekosaur> | yes, haskellbridge bridges a number of Haskell IRC channels to matrix.org rooms |
| 2025-08-15 05:19:29 +0200 | <geekosaur> | if you /whois haskellbridge you'll get a list (well, a URL containing a list) |
| 2025-08-15 05:19:49 +0200 | <dpn> | i basically only use irc to come here now - might be more convenient to use matrix. cheers |
| 2025-08-15 05:21:03 +0200 | <haskellbridge> | <iqubic (she/her)> Looking at the code, I see you're just using "trace". But won't that write so stdout? How would I view those messages while xmonad is running? |
| 2025-08-15 05:22:52 +0200 | <geekosaur> | you look at wherever stderr (not stdout; it actually uses the RTS's debugBelch internally iirc) is going. |
| 2025-08-15 05:23:12 +0200 | <haskellbridge> | <iqubic (she/her)> Ah. I se. |
| 2025-08-15 05:23:33 +0200 | <geekosaur> | I've been thinking about how to capture output to a window without having to plumb I/O through the pure parts of a manageHook |
| 2025-08-15 05:29:08 +0200 | <dpn> | being able to summon a window for the log would be pretty amazing |
| 2025-08-15 05:30:03 +0200 | <haskellbridge> | <iqubic (she/her)> geekosaur: Isn't calling "trace" technically doing I/O? |
| 2025-08-15 05:30:31 +0200 | <dpn> | *grabs popcorn* |
| 2025-08-15 05:30:45 +0200 | <haskellbridge> | <iqubic (she/her)> Or is that a different because "trace" is "MonadIO" action and not an "X Monad" action? |
| 2025-08-15 05:31:58 +0200 | <geekosaur> | trace uses unsafePerformIO |
| 2025-08-15 05:32:16 +0200 | <geekosaur> | which is why it has to use debugBelch: you run into problems with locked Handles otherwise |
| 2025-08-15 05:32:49 +0200 | <haskellbridge> | <iqubic (she/her)> Oh.. So that's not actually "real" I/O. Got it. I see now why opening a window for debug output would be hard. |
| 2025-08-15 05:35:49 +0200 | <haskellbridge> | <iqubic (she/her)> I was viewing the source code on the Hackage site and the mouse hover info was showing me the signature for this "trace" https://hackage.haskell.org/package/xmonad-contrib-0.18.1/docs/XMonad-Config-Prime.html#v:trace |
| 2025-08-15 05:36:04 +0200 | <haskellbridge> | <iqubic (she/her)> I think that's not the same "trace" as DebugManage uses. |
| 2025-08-15 05:37:21 +0200 | <geekosaur> | that's a bug in how we have things set up. X.C.Prime is an ancient experiment that went nowhere |
| 2025-08-15 05:37:37 +0200 | <geekosaur> | but haddock insists on linking to everything it exports |
| 2025-08-15 05:38:16 +0200 | <geekosaur> | I think if you use (and can find) the live docs it's been fixed and will go live with the next release |
| 2025-08-15 05:38:25 +0200 | <geekosaur> | I can never remember where they live |
| 2025-08-15 05:38:37 +0200 | <haskellbridge> | <iqubic (she/her)> Is there a new release planned? |
| 2025-08-15 05:40:25 +0200 | <geekosaur> | not currently |
| 2025-08-15 05:41:48 +0200 | <haskellbridge> | <iqubic (she/her)> Not sure if this is the live docs, or just a different domain showing the same haddocks. |
| 2025-08-15 05:41:53 +0200 | <haskellbridge> | <iqubic (she/her)> But I found this: https://xmonad.github.io/xmonad-docs/xmonad-contrib/ |
| 2025-08-15 05:42:50 +0200 | <geekosaur> | that should be it, maybe we do have a different trace in scope |
| 2025-08-15 05:43:28 +0200 | <haskellbridge> | <iqubic (she/her)> https://xmonad.github.io/xmonad-docs/xmonad-contrib/src/XMonad.Hooks.ManageDebug.html#debugManageH… |
| 2025-08-15 05:44:08 +0200 | <haskellbridge> | <iqubic (she/her)> Hovering my mouse over "trace" there shows me "MonadIO m => m ()" as the signature. |
| 2025-08-15 05:44:16 +0200 | <geekosaur> | yeh, I just saw that |
| 2025-08-15 05:44:52 +0200 | <haskellbridge> | <iqubic (she/her)> I'm going to assume this is some weirdness related to X.C.Prime and just not worry about this. |
| 2025-08-15 05:45:23 +0200 | <geekosaur> | hah. it's from XMonad.Core |
| 2025-08-15 05:46:07 +0200 | <geekosaur> | I guess that means I can get away with plumbing a Handle to an xmessage through there after all |
| 2025-08-15 05:46:36 +0200 | <haskellbridge> | <iqubic (she/her)> https://xmonad.github.io/xmonad-docs/xmonad/src/XMonad.Core.html#trace |
| 2025-08-15 05:47:17 +0200 | <haskellbridge> | <iqubic (she/her)> Wait... is that still running unsafePerformIO? I can't tell. |
| 2025-08-15 05:48:34 +0200 | <geekosaur> | "io" is short for liftIO |
| 2025-08-15 05:48:42 +0200 | <geekosaur> | which is why the type has a MonadIO constraint |
| 2025-08-15 05:51:04 +0200 | <haskellbridge> | <iqubic (she/her)> Anyways, what exists now works for me. You don't need to worry about spawning a new window for ManageDebug output unless you want to. |
| 2025-08-15 05:51:17 +0200 | <geekosaur> | I want to |
| 2025-08-15 05:52:07 +0200 | <geekosaur> | I've never been very happy about people having to figure out where their session output is (if it's there at all: some systems cap it via cgroups) to use it |
| 2025-08-15 05:53:29 +0200 | <haskellbridge> | <iqubic (she/her)> I know Haskell well enough to understand the XMonad code, but actually learning all the library functions and types involved to make this work will take me a long while. I've figured out where NixOS put its session output, so I can use this module as it currently is. |
| 2025-08-15 06:17:10 +0200 | haskellbridge | (~hackager@syn-096-028-224-214.res.spectrum.com) (Remote host closed the connection) |
| 2025-08-15 06:17:53 +0200 | haskellbridge | (~hackager@syn-096-028-224-214.res.spectrum.com) hackager |
| 2025-08-15 08:21:19 +0200 | ft | (~ft@p508db692.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-08-15 10:39:27 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 252 seconds) |
| 2025-08-15 12:29:36 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-08-15 13:31:26 +0200 | ft | (~ft@p508db692.dip0.t-ipconnect.de) ft |
| 2025-08-15 14:34:12 +0200 | <liskin> | Hm, the "live" docs probably use old ghc. I should fix that. |
| 2025-08-15 14:34:26 +0200 | <liskin> | Well there's so many things I should do |
| 2025-08-15 15:24:44 +0200 | tv | (~tv@user/tv) tv |
| 2025-08-15 18:04:39 +0200 | Digit | (~user@user/digit) (Read error: Connection reset by peer) |
| 2025-08-15 18:05:43 +0200 | Digit | (~user@user/digit) Digit |
| 2025-08-15 20:05:12 +0200 | werneta | (~werneta@syn-071-083-160-242.res.spectrum.com) werneta |
| 2025-08-15 22:34:12 +0200 | haskellbridge | (~hackager@syn-096-028-224-214.res.spectrum.com) (Remote host closed the connection) |
| 2025-08-15 22:36:31 +0200 | haskellbridge | (~hackager@syn-096-028-224-214.res.spectrum.com) hackager |
| 2025-08-15 22:39:23 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-08-15 23:09:17 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |