| 2026-02-16 00:07:46 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2026-02-16 02:37:54 +0100 | hightower3 | (~hightower@dh207-112-152.xnet.hr) hightower2 |
| 2026-02-16 03:06:44 +0100 | hightower3 | (~hightower@dh207-112-152.xnet.hr) (Remote host closed the connection) |
| 2026-02-16 03:07:02 +0100 | hightower3 | (~hightower@dh207-112-152.xnet.hr) hightower2 |
| 2026-02-16 03:23:06 +0100 | hightower4 | (~hightower@dh207-112-152.xnet.hr) hightower2 |
| 2026-02-16 03:25:20 +0100 | hightower3 | (~hightower@dh207-112-152.xnet.hr) (Ping timeout: 245 seconds) |
| 2026-02-16 04:11:51 +0100 | td_ | (~td@i53870902.versanet.de) (Ping timeout: 244 seconds) |
| 2026-02-16 04:14:01 +0100 | td_ | (~td@i5387093C.versanet.de) td_ |
| 2026-02-16 04:17:42 +0100 | <ghormoon> | can i somehow ban window border based on window name? or even on that a window pro "STEAM_GAME(CARDINAL)" exists in general? I have an issue with som fullscreen windows that the border blinks ... even if set the layout to a borderless variant before moving the window there |
| 2026-02-16 04:21:03 +0100 | <geekosaur> | https://hackage.haskell.org/package/xmonad-contrib-0.18.1/docs/XMonad-Hooks-BorderPerWindow.html |
| 2026-02-16 04:25:23 +0100 | <geekosaur> | matching on a property of type CARDINAL will probably require custom code, I think there's only a canned version for strings |
| 2026-02-16 04:28:32 +0100 | <ghormoon> | i'll do it by the name for now ... but I'm missing some syntax sugar, i tried to edit my main line, but that won't work: main = xmonad $ actionQueue =<< myStatusBar (withUrgencyHook NoUrgencyHook defaults) |
| 2026-02-16 04:28:43 +0100 | <ghormoon> | previously it was just: main = xmonad =<< myStatusBar (withUrgencyHook NoUrgencyHook defaults) |
| 2026-02-16 04:34:08 +0100 | <geekosaur> | correct, the precedences are wrng for what ypu were doing. `main = xmonad =<< actionQueue <$> myStatusBar (withUrgencyHook NoUrgencyHook defaults)` |
| 2026-02-16 04:37:05 +0100 | <ghormoon> | thanks, that helps |
| 2026-02-16 04:39:50 +0100 | <ghormoon> | ok, minor thing, the specific cborder settings get forgotten if i restart xmonad, but that's not gonna happen often unless i'm trying to tweak something, so it's not improtant to fix :D |
| 2026-02-16 04:41:26 +0100 | <geekosaur> | report that; there might be a way around it |
| 2026-02-16 04:42:40 +0100 | <ghormoon> | yeah the per-window action obviously doesn't run again |
| 2026-02-16 04:43:13 +0100 | <ghormoon> | but the other tasks like doShift don't run either |
| 2026-02-16 04:44:09 +0100 | <geekosaur> | yeh, but I'm thinking we save them by ID in persistent XS and reapply them on restart. also would require a delete-window hook to clean up, but conveniently `actionQueue` is a combinator so we can hide it in there without changing types or usage ☺ |
| 2026-02-16 04:47:34 +0100 | <geekosaur> | and yes, none of the manageHook things run on restart, they only run when a new window is mapped |
| 2026-02-16 04:48:12 +0100 | <geekosaur> | there are things you don't want to get repeated on restart, for example a manageHook moves a window to some workspace but then you manually move it somewhere else |
| 2026-02-16 04:48:26 +0100 | <geekosaur> | you don't want that to get undone on restart |
| 2026-02-16 04:50:01 +0100 | <ghormoon> | yeah so the question is, if this should be re-run or not, but it would make sense to, right |
| 2026-02-16 04:51:02 +0100 | <ghormoon> | btw theoretically, xmonad can run only one x session or more? thinking if i could possibly have some way to switch around some windows to dgpu without some heavy pains |
| 2026-02-16 04:52:11 +0100 | <geekosaur> | it's the other way around. an X session can only run a single window manager |
| 2026-02-16 04:52:48 +0100 | <geekosaur> | you could arrange to run a second X session via a display manager, but it's not possible to move windows between X sessions (X server limitation) |
| 2026-02-16 04:53:37 +0100 | <ghormoon> | yeah not to move windows between, but to be able to switch to desktops that have windows in the other x session |
| 2026-02-16 04:54:18 +0100 | <ghormoon> | have both sets of workspaces in one xmonad ... not important, just thinking :D |
| 2026-02-16 04:56:29 +0100 | <ghormoon> | but i guess i'd have to have two separate xmonad instances running and just switch around those some other way |
| 2026-02-16 05:06:41 +0100 | <geekosaur> | right |
| 2026-02-16 05:07:53 +0100 | <geekosaur> | and "some other way" is CTRL-ALT-Fn (beware of modern keyboards which require an extra keypress for the function keys) where the first X session is F1 (or F2 if Wayland is also running) and the second F2 (resp. F3) |
| 2026-02-16 05:08:43 +0100 | <geekosaur> | although with Xkb you can redefine those keys, but you'll probably have to write your own Xkb modifier and install it manually |
| 2026-02-16 05:14:52 +0100 | <geekosaur> | I don't think any existing window mnager has the ability to connect to multiple display servers and keep track of what's running on each display server. in xmonad's case it would mean multiple StackSets and some way to switch between them (and lose compatibility, since switching between them would be Linux specific but we have users on NetBSD (where xmonad originated) and FreeBSD |
| 2026-02-16 05:22:05 +0100 | <geekosaur> | there was at one point a proof of concept ov moving windows between display servers. they discovered that the only way to do it reliably was to save the entire event stream sent to the display server and replay it when moving (recreating, really) the window. this got very slow for long-lived windows and used a lot of memory/disk for the saved event stream |