Logs: liberachat/#xmonad
| 2022-02-05 19:28:51 | <geekosaur> | look at line 262, as I said, its result type is in the X monad, so it can get at the focused window |
| 2022-02-05 19:28:58 | <geekosaur> | yours must also be in the X monad |
| 2022-02-05 19:32:44 | <geekosaur> | then, since onlyFullscreen is in X, line 230 must change to: onlyFullscreen z (applyMagnifier z) r s wrs >>= magnifyAt k |
| 2022-02-05 19:34:59 | <jakeStateless-Fa> | ah, I see |
| 2022-02-05 19:36:12 | <jakeStateless-Fa> | I figured something simpler out though, I'd overlooked the `s` variable, that was of type `Stack a`, unlike `wrs` which was of type `[(Window,Rectangle)]`, and therefore I could run `X.Stackset`s `focus` on it. That did the trick |
| 2022-02-05 19:45:25 | <geekosaur> | I think you still need an X context in onlyFullscreen for hasTag though? |
| 2022-02-05 19:49:15 | <jakeStateless-Fa> | I believe it's getting passed in through magnifyAt, not 100% sure, but it's compiling and working 🤷. |
| 2022-02-05 20:06:11 | → | banc joins (banc@gateway/vpn/airvpn/banc) |
| 2022-02-05 20:12:17 | <jakeStateless-Fa> | https://0bin.net/paste/zMqHfmsm#ZDxF2U8Cfidlxt12ZHvuL9nBnJBmNuptIxq89pawOvK - using this in my loghook causes infinite recursion, boredr flickering, and an unresponsive xmonad (though I can still use the window I was last focused on, and still switch to different vTTYs) |
| 2022-02-05 20:13:38 | <jakeStateless-Fa> | border* , those messages must trigger the log hook, I'm guessing, how would I go about keeping a small amount of state (a bool) allowing me to prevent the infinite recursion? |
| 2022-02-05 20:13:52 | <geekosaur> | it's the sendMessage |
| 2022-02-05 20:15:46 | <geekosaur> | I, uh, don't see why you'd have it say "this is fullscreen, unfullscreen it"/"this is not fullscreen, fullscreen it" unconditionally in a logHook, to be honest |
| 2022-02-05 20:16:16 | <geekosaur> | isn't the FS tag the state? or do I misunderstand its purpose? |
| 2022-02-05 20:19:34 | <jakeStateless-Fa> | the FS tag applies to a window, so when that window's focused, it'll fullscreen (magnifier + removal of struts, borders, and spacing) |
| 2022-02-05 20:20:04 | <jakeStateless-Fa> | you're still allowed to move freely between windows though |
| 2022-02-05 20:20:08 | <jakeStateless-Fa> | by design |
| 2022-02-05 20:20:27 | <jakeStateless-Fa> | So, if you switch to a non-fullscreen window right after a fullscreened one, then the struts and spacing will still be gone. |
| 2022-02-05 20:20:49 | <jakeStateless-Fa> | and vice versa (if you untoggle, or if the prior scenario didn't happen) |
| 2022-02-05 20:21:10 | <jakeStateless-Fa> | Is there a way for me to query the layout, so I can know when those changes are already applied? |
| 2022-02-05 20:24:51 | <jakeStateless-Fa> | I could just tie this to a keybind, but if they switch windows via another method, it'll get out of sync. |
| 2022-02-05 20:25:10 | <jakeStateless-Fa> | or if the window closes / really any focus change |
| 2022-02-05 20:26:36 | <jakeStateless-Fa> | Ooh, instead of querying for the changes (which may not work for everyone, depending upon their layouts) is there a way I can identify what change occurred? If so, filtering for focus change would be the simplest, and most optimized way to do this. |
| 2022-02-05 20:37:58 | <geekosaur> | not easily. logHook is executed any time `windows` is and there's no way it can know what e.g. a manageHook did |
| 2022-02-05 20:41:37 | <geekosaur> | I think there's something that tracks the current workspace and triggers when it changes, but it does so by stuffing its idea of the current workspace in XS and comparing every time the logHook runs |
| 2022-02-05 20:42:20 | <geekosaur> | conceivably you could handle the focused window the same way; I don't think we provide a way to change the focused window on a non-focused workspace |
| 2022-02-05 21:22:41 | × | sogens quits (~sogens@pa49-197-132-249.pa.qld.optusnet.com.au) (Quit: WeeChat 3.4) |
| 2022-02-05 21:23:00 | → | sogens joins (~sogens@pa49-197-132-249.pa.qld.optusnet.com.au) |
| 2022-02-05 23:07:09 | × | mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-02-06 00:11:18 | <peterstorm[m]> | BadDrawable (invalid PixMap) errors, what do those mean? Just started getting them after the nvidia driver got updates on nixos |
| 2022-02-06 00:13:22 | <geekosaur> | o.O |
| 2022-02-06 00:16:58 | <geekosaur> | it means something's drawing to an offscreen window or "bitmap" which doesn't exist or is misconfigured |
| 2022-02-06 00:17:53 | <peterstorm[m]> | Interesting 😅 |
| 2022-02-06 00:17:57 | <geekosaur> | since X11 hands such drawing off to the video driver, it would make some sense that an nvidia update could cause that. guess you need to roll it back and maybe pin it |
| 2022-02-06 00:18:35 | <peterstorm[m]> | Yeah, cheers, I’ll see to that :) |
| 2022-02-06 00:28:43 | × | seschwar quits (~seschwar@user/seschwar) (Quit: :wq) |
| 2022-02-06 01:01:51 | × | jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2022-02-06 01:03:57 | → | jao joins (~jao@68.235.43.173) |
| 2022-02-06 01:10:08 | <peterstorm[m]> | Ah, recompiling xmonad worked, should have thought of that, saw it mentioned in an old thread |
| 2022-02-06 01:13:46 | × | catman quits (~catman@user/catman) (Read error: Connection reset by peer) |
| 2022-02-06 01:15:13 | <jakeStateless-Fa> | <geekosaur> "I think there's something that..." <- OK, so keeping an int in state, to decrement and watch for the sendMessage modifications is probably the best route here. |
| 2022-02-06 01:15:57 | <jakeStateless-Fa> | I've hardly touched the internals of state management, so is there a module that does something like this for me to go and copy? |
| 2022-02-06 01:15:58 | <geekosaur> | do you actually require a refresh to happen with those messages? (I'm still quite confused as to what you're trying to do there.) |
| 2022-02-06 01:16:08 | <jakeStateless-Fa> | /replicate |
| 2022-02-06 01:16:13 | <geekosaur> | if you don't, you could just use sendMessageWithNoRefresh |
| 2022-02-06 01:16:53 | <geekosaur> | https://github.com/xmonad/xmonad-contrib/blob/master/XMonad/Util/ExtensibleState.hs |
| 2022-02-06 01:17:47 | <jakeStateless-Fa> | keybind -> toggles tag "FS" |
| 2022-02-06 01:17:47 | <jakeStateless-Fa> | magnifier modifier -> zooms any focused "FS" window in |
| 2022-02-06 01:17:47 | <jakeStateless-Fa> | logHook -> handles adding/removing struts, spacing, and borders |
| 2022-02-06 01:19:48 | <geekosaur> | ok, you actually need it to refresh there. so you need to store state including (a) the focused window (b) whether you activated your changes or not |
| 2022-02-06 01:20:20 | <geekosaur> | if the focused window changes then you need to undo them (then potentially redo them on the new focused window if it has the FS tag) |
| 2022-02-06 01:20:56 | <geekosaur> | it's still going to flicker, but only once |
| 2022-02-06 01:21:47 | <geekosaur> | hm, actually twice because the smart-spacing stuff will also do a refresh |
| 2022-02-06 01:22:42 | <geekosaur> | so you might do the strut with no refresh and let the spacing one refresh for both |
| 2022-02-06 01:23:52 | <geekosaur> | data FSState = FSS (Window, Bool); instance ExtensibleState FSState where ... |
| 2022-02-06 01:24:08 | <jakeStateless-Fa> | Isn't that what `<+>` will do? Use only one refresh? |
| 2022-02-06 01:24:27 | <geekosaur> | technically it should be a Maybe Window with the initial state Nothing, but you can use window id 0 instead |
| 2022-02-06 01:24:41 | <geekosaur> | no, <+> has nothing to do with how many refreshes happen |
| 2022-02-06 01:25:28 | <geekosaur> | in the logHook <+> is equivalent to >> |
| 2022-02-06 01:25:35 | <geekosaur> | (or *> if you prefer) |
| 2022-02-06 01:26:00 | <jakeStateless-Fa> | huh, good to know |
| 2022-02-06 01:26:19 | <jakeStateless-Fa> | Outside of the logHook though, using `<+>` will speed things up, right? |
| 2022-02-06 01:26:26 | <geekosaur> | sendMessage always does a refresh, you are sending one message directly and the smartspacing stuff sends another message |
| 2022-02-06 01:26:32 | <geekosaur> | no |
| 2022-02-06 01:26:58 | <geekosaur> | manageHooks may make you think that way but that's not really what's going on in them |
| 2022-02-06 01:27:26 | <geekosaur> | *nothing* in a manageHook does a refresh, the manageHook is fed to X.O.windows which does a refresh after processing it |
| 2022-02-06 01:28:28 | <geekosaur> | (after running the manageHook on any new windows that have been created, removing any windows that have been deleted, moving any windows that have been moved/resized, etc.) |
| 2022-02-06 01:29:40 | <jakeStateless-Fa> | Liskin told me a while back (perhaps I merely remember incorrectly) that I should be using `<+>` when calling things from a keybind, as it has some (speed?) advantages over `>>` in that scenario |
| 2022-02-06 01:30:17 | <geekosaur> | <+> is basically "use the linker that makes the most sense for the current context". for a manageHook that is <>, for a monadic context it's >>, it's several other things in other contexts. (in fact they're all monoids so it's all <>) |
| 2022-02-06 01:31:04 | <jakeStateless-Fa> | I see.. |
| 2022-02-06 01:32:02 | <geekosaur> | I can't seeit being much faster unless <> is actually *> instead of >> and even then it should be minimal. <+> is more about convenience, I'd say |
| 2022-02-06 01:32:21 | <geekosaur> | (liskin, any comments if you're around?) |
| 2022-02-06 01:39:46 | <jakeStateless-Fa> | I mean, I definitely don't want to (plus, I probably can't) be sending messages from within the layout itself, right? |
| 2022-02-06 01:44:59 | <geekosaur> | right |
| 2022-02-06 01:45:10 | <geekosaur> | you can't send messages but you can relay one you've received |
| 2022-02-06 01:45:20 | <geekosaur> | (to sublayouts) |
| 2022-02-06 01:45:53 | <geekosaur> | and you do *not* want to refresh inside a layout |
| 2022-02-06 01:46:40 | <geekosaur> | actually I'm not sure sending a message is even meaningful inside a layout because you'd just receive it back |
| 2022-02-06 01:47:09 | <geekosaur> | aside from relaying to a sublayout as I mentioned |
| 2022-02-06 01:49:20 | <geekosaur> | hm, well in this case it'd be intercepted by avoidStruts I guess. but you still can't do that because it'd alter the screen rectangle you received. so yes, Bad Idea |
| 2022-02-06 02:11:28 | <liskin> | I don't remember telling anyone to use <+> |
| 2022-02-06 02:12:21 | × | steve__ quits (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 256 seconds) |
| 2022-02-06 02:27:28 | × | jao quits (~jao@68.235.43.173) (Remote host closed the connection) |
| 2022-02-06 02:38:11 | × | noex quits (~null@user/noex) (Ping timeout: 256 seconds) |
| 2022-02-06 02:42:41 | → | noex joins (~null@user/noex) |
| 2022-02-06 03:04:15 | × | banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 256 seconds) |
| 2022-02-06 03:22:31 | → | banc joins (banc@gateway/vpn/airvpn/banc) |
| 2022-02-06 03:22:57 | × | noex quits (~null@user/noex) (Ping timeout: 256 seconds) |
| 2022-02-06 03:23:31 | → | noex joins (~null@user/noex) |
| 2022-02-06 03:35:09 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2022-02-06 03:35:10 | → | allbery_b joins (~geekosaur@xmonad/geekosaur) |
| 2022-02-06 03:35:13 | allbery_b | is now known as geekosaur |
| 2022-02-06 03:37:34 | → | jao joins (~jao@68.235.43.173) |
| 2022-02-06 03:39:37 | × | td_ quits (~td@muedsl-82-207-238-241.citykom.de) (Ping timeout: 256 seconds) |
| 2022-02-06 03:41:33 | → | td_ joins (~td@muedsl-82-207-238-099.citykom.de) |
| 2022-02-06 04:04:55 | <jakeStateless-Fa> | How does one obtain a relevant `WindowSpace`? |
| 2022-02-06 04:12:38 | <jakeStateless-Fa> | Well, I opted for `broadcastMessage`, not sure if that's the right way to go about it 🤷 |
| 2022-02-06 04:13:33 | <jakeStateless-Fa> | this' my alt: |
| 2022-02-06 04:14:21 | → | galactic_starfis joins (~galactics@2001:470:69fc:105::1:2985) |
| 2022-02-06 04:14:21 | <galactic_starfis> | I got the fullscreen hook working! |
| 2022-02-06 04:18:26 | <galactic_starfis> | Is there a way to modify window decorations via messages? Or some other way after the fact, allowing me to hide tabs when in fullscreen? |
All times are in UTC.