2022-02-06 00:07:09 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
2022-02-06 01:11:18 +0100 | <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 01:13:22 +0100 | <geekosaur> | o.O |
2022-02-06 01:16:58 +0100 | <geekosaur> | it means something's drawing to an offscreen window or "bitmap" which doesn't exist or is misconfigured |
2022-02-06 01:17:53 +0100 | <peterstorm[m]> | Interesting 😅 |
2022-02-06 01:17:57 +0100 | <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 01:18:35 +0100 | <peterstorm[m]> | Yeah, cheers, I’ll see to that :) |
2022-02-06 01:28:43 +0100 | seschwar | (~seschwar@user/seschwar) (Quit: :wq) |
2022-02-06 02:01:51 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 256 seconds) |
2022-02-06 02:03:57 +0100 | jao | (~jao@68.235.43.173) |
2022-02-06 02:10:08 +0100 | <peterstorm[m]> | Ah, recompiling xmonad worked, should have thought of that, saw it mentioned in an old thread |
2022-02-06 02:13:46 +0100 | catman | (~catman@user/catman) (Read error: Connection reset by peer) |
2022-02-06 02:15:13 +0100 | <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 02:15:57 +0100 | <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 02:15:58 +0100 | <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 02:16:08 +0100 | <jakeStateless-Fa> | /replicate |
2022-02-06 02:16:13 +0100 | <geekosaur> | if you don't, you could just use sendMessageWithNoRefresh |
2022-02-06 02:16:53 +0100 | <geekosaur> | https://github.com/xmonad/xmonad-contrib/blob/master/XMonad/Util/ExtensibleState.hs |
2022-02-06 02:17:47 +0100 | <jakeStateless-Fa> | keybind -> toggles tag "FS" |
2022-02-06 02:17:47 +0100 | <jakeStateless-Fa> | magnifier modifier -> zooms any focused "FS" window in |
2022-02-06 02:17:47 +0100 | <jakeStateless-Fa> | logHook -> handles adding/removing struts, spacing, and borders |
2022-02-06 02:19:48 +0100 | <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 02:20:20 +0100 | <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 02:20:56 +0100 | <geekosaur> | it's still going to flicker, but only once |
2022-02-06 02:21:47 +0100 | <geekosaur> | hm, actually twice because the smart-spacing stuff will also do a refresh |
2022-02-06 02:22:42 +0100 | <geekosaur> | so you might do the strut with no refresh and let the spacing one refresh for both |
2022-02-06 02:23:52 +0100 | <geekosaur> | data FSState = FSS (Window, Bool); instance ExtensibleState FSState where ... |
2022-02-06 02:24:08 +0100 | <jakeStateless-Fa> | Isn't that what `<+>` will do? Use only one refresh? |
2022-02-06 02:24:27 +0100 | <geekosaur> | technically it should be a Maybe Window with the initial state Nothing, but you can use window id 0 instead |
2022-02-06 02:24:41 +0100 | <geekosaur> | no, <+> has nothing to do with how many refreshes happen |
2022-02-06 02:25:28 +0100 | <geekosaur> | in the logHook <+> is equivalent to >> |
2022-02-06 02:25:35 +0100 | <geekosaur> | (or *> if you prefer) |
2022-02-06 02:26:00 +0100 | <jakeStateless-Fa> | huh, good to know |
2022-02-06 02:26:19 +0100 | <jakeStateless-Fa> | Outside of the logHook though, using `<+>` will speed things up, right? |
2022-02-06 02:26:26 +0100 | <geekosaur> | sendMessage always does a refresh, you are sending one message directly and the smartspacing stuff sends another message |
2022-02-06 02:26:32 +0100 | <geekosaur> | no |
2022-02-06 02:26:58 +0100 | <geekosaur> | manageHooks may make you think that way but that's not really what's going on in them |
2022-02-06 02:27:26 +0100 | <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 02:28:28 +0100 | <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 02:29:40 +0100 | <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 02:30:17 +0100 | <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 02:31:04 +0100 | <jakeStateless-Fa> | I see.. |
2022-02-06 02:32:02 +0100 | <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 02:32:21 +0100 | <geekosaur> | (liskin, any comments if you're around?) |
2022-02-06 02:39:46 +0100 | <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 02:44:59 +0100 | <geekosaur> | right |
2022-02-06 02:45:10 +0100 | <geekosaur> | you can't send messages but you can relay one you've received |
2022-02-06 02:45:20 +0100 | <geekosaur> | (to sublayouts) |
2022-02-06 02:45:53 +0100 | <geekosaur> | and you do *not* want to refresh inside a layout |
2022-02-06 02:46:40 +0100 | <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 02:47:09 +0100 | <geekosaur> | aside from relaying to a sublayout as I mentioned |
2022-02-06 02:49:20 +0100 | <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 03:11:28 +0100 | <liskin> | I don't remember telling anyone to use <+> |
2022-02-06 03:12:21 +0100 | steve__ | (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 256 seconds) |
2022-02-06 03:27:28 +0100 | jao | (~jao@68.235.43.173) (Remote host closed the connection) |
2022-02-06 03:38:11 +0100 | noex | (~null@user/noex) (Ping timeout: 256 seconds) |
2022-02-06 03:42:41 +0100 | noex | (~null@user/noex) |
2022-02-06 04:04:15 +0100 | banc | (banc@gateway/vpn/airvpn/banc) (Ping timeout: 256 seconds) |
2022-02-06 04:22:31 +0100 | banc | (banc@gateway/vpn/airvpn/banc) |
2022-02-06 04:22:57 +0100 | noex | (~null@user/noex) (Ping timeout: 256 seconds) |
2022-02-06 04:23:31 +0100 | noex | (~null@user/noex) |
2022-02-06 04:35:09 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
2022-02-06 04:35:10 +0100 | allbery_b | (~geekosaur@xmonad/geekosaur) |
2022-02-06 04:35:13 +0100 | allbery_b | geekosaur |
2022-02-06 04:37:34 +0100 | jao | (~jao@68.235.43.173) |
2022-02-06 04:39:37 +0100 | td_ | (~td@muedsl-82-207-238-241.citykom.de) (Ping timeout: 256 seconds) |
2022-02-06 04:41:33 +0100 | td_ | (~td@muedsl-82-207-238-099.citykom.de) |
2022-02-06 05:04:55 +0100 | <jakeStateless-Fa> | How does one obtain a relevant `WindowSpace`? |
2022-02-06 05:12:38 +0100 | <jakeStateless-Fa> | Well, I opted for `broadcastMessage`, not sure if that's the right way to go about it 🤷 |
2022-02-06 05:13:33 +0100 | <jakeStateless-Fa> | this' my alt: |
2022-02-06 05:14:21 +0100 | galactic_starfis | (~galactics@2001:470:69fc:105::1:2985) |
2022-02-06 05:14:21 +0100 | <galactic_starfis> | I got the fullscreen hook working! |
2022-02-06 05:18:26 +0100 | <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? |
2022-02-06 05:50:59 +0100 | <galactic_starfis> | ^ I found setTheme |
2022-02-06 06:13:41 +0100 | jao | (~jao@68.235.43.173) (Ping timeout: 256 seconds) |
2022-02-06 06:36:29 +0100 | thunderrd | (~thunderrd@183.182.111.73) (Quit: If it wasn't written down it didn't happen...) |
2022-02-06 07:30:35 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 07:49:19 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
2022-02-06 07:49:43 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
2022-02-06 09:53:53 +0100 | <Solid> | I always chuckle when thinking about how <> = >> for hooks is due to the trivial monoid instance for () |
2022-02-06 09:54:34 +0100 | <Solid> | s/monoid/semigroup/ I suppose |
2022-02-06 10:14:14 +0100 | jludwig | (~justin@user/jludwig) (Read error: Connection reset by peer) |
2022-02-06 10:14:32 +0100 | jludwig | (~justin@user/jludwig) |
2022-02-06 10:17:30 +0100 | jludwig | (~justin@user/jludwig) (Client Quit) |
2022-02-06 10:31:50 +0100 | thunderrd | (~thunderrd@183.182.114.80) (Remote host closed the connection) |
2022-02-06 10:32:53 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 10:35:36 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
2022-02-06 10:53:28 +0100 | jludwig | (~justin@user/jludwig) |
2022-02-06 11:08:01 +0100 | thunderrd | (~thunderrd@183.182.114.80) (Remote host closed the connection) |
2022-02-06 11:08:58 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 11:46:34 +0100 | thunderrd | (~thunderrd@183.182.114.80) (Quit: If it wasn't written down it didn't happen...) |
2022-02-06 11:50:24 +0100 | seschwar | (~seschwar@user/seschwar) |
2022-02-06 11:52:15 +0100 | <galactic_starfis> | I've almost completely decked out a fullscreening procedure. All I need is to setup `Messages` (so that ewmh doesn't need an extra argument), figure out a good way to handle refloating windows, and figure out a decent way to pull whatever decoration `Theme` the user is using out of their layout. |
2022-02-06 11:52:51 +0100 | <geekosaur> | "all" |
2022-02-06 11:53:32 +0100 | <geekosaur> | you can modify a theme via messages but you can't extract it |
2022-02-06 11:54:05 +0100 | <geekosaur> | (and messages areone-way so you can't add a message that tells you the Theme) |
2022-02-06 11:56:19 +0100 | <geekosaur> | and you can't introspect a Layout to find a Theme hidden within |
2022-02-06 11:58:46 +0100 | <galactic_starfis> | An alternate variant of this could use fullFloat instead of magnifier, if the user wanted to draw atop any floating windows too. |
2022-02-06 11:58:58 +0100 | <galactic_starfis> | That'd need a bit more fancywork, but it could be done |
2022-02-06 11:59:24 +0100 | <geekosaur> | it would probably be more reliable |
2022-02-06 11:59:36 +0100 | <galactic_starfis> | It's sort of that way already, but it's missing the easy navigation piece, which's the whole reason I'm doing this. |
2022-02-06 12:00:12 +0100 | <galactic_starfis> | Could I make that module store it in extensible state? |
2022-02-06 12:01:06 +0100 | <geekosaur> | probably yes. the question is what you do if it's not there (i.e. layout isn't Tabbed) |
2022-02-06 12:01:14 +0100 | <galactic_starfis> | mmh, that's inconvenient |
2022-02-06 12:01:45 +0100 | <galactic_starfis> | I had to pass in the theme in many places, the only place that I'm not bothering with is the `ewmh` module - that thing's complex |
2022-02-06 12:02:02 +0100 | <geekosaur> | if I had to do fullscreen via a layout, I'd probably match up the passed rectangle against the screen rectangles (ScreenDetail) and use that instead of trying to hide the struts separately |
2022-02-06 12:02:09 +0100 | <galactic_starfis> | ugh, if I could just fetch the theme, it'd be so much simpler |
2022-02-06 12:02:13 +0100 | <geekosaur> | which is more or less what fullfloat does |
2022-02-06 12:02:38 +0100 | <geekosaur> | that'd also hide tabs |
2022-02-06 12:02:38 +0100 | <galactic_starfis> | hm, though, perhaps I could have the user store the theme in extensible state upon initialization 🤔 |
2022-02-06 12:02:56 +0100 | <galactic_starfis> | so long as they're only using 1 theme, that should work |
2022-02-06 12:06:39 +0100 | <galactic_starfis> | everything works, the theme is the only annoying thing at the moment |
2022-02-06 12:07:54 +0100 | <galactic_starfis> | but perhaps that'd work better, unsure of how I'd do that from within this context, as I thought any layout after struts/decos didn't have the ability to grow the rectangle past that |
2022-02-06 12:09:05 +0100 | <geekosaur> | it has the ability, it's just not recommended. |
2022-02-06 12:10:00 +0100 | <geekosaur> | your biggest problem becomes making sure the stuff under the rectangle remains under it, but there are ways around that too |
2022-02-06 12:14:17 +0100 | <galactic_starfis> | Can I do `do x <- XS.get Something`? I'm trying it right now, it's not working... Is `>>=` strictly necessary in this context? |
2022-02-06 12:15:26 +0100 | <Solid> | XS.get doesn't take an argument |
2022-02-06 12:15:41 +0100 | <Solid> | it learns about what it needs to get purely by its type |
2022-02-06 12:16:46 +0100 | <galactic_starfis> | ah |
2022-02-06 12:17:33 +0100 | <galactic_starfis> | More directly: is there a way to do `do x <- someState`? |
2022-02-06 12:18:11 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
2022-02-06 12:18:32 +0100 | <Solid> | sure, you just need to tell get which type to get; `do x <- XS.get @MyType` or (if it's not abstract) `do (MyType content) <- XS.get` |
2022-02-06 12:26:02 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 12:31:25 +0100 | <galactic_starfis> | ah, thanks! |
2022-02-06 12:32:43 +0100 | <geekosaur> | the parentheses are optional there |
2022-02-06 12:33:32 +0100 | <galactic_starfis> | ^ now that is cool |
2022-02-06 12:33:45 +0100 | <geekosaur> | % do Just x <- listToMaybe [1]; show x |
2022-02-06 12:33:53 +0100 | <galactic_starfis> | now the ewmh module works with it too. |
2022-02-06 12:33:54 +0100 | <geekosaur> | rats, no yahb here |
2022-02-06 12:34:11 +0100 | <geekosaur> | > do Just x <- listToMaybe [1]; show x |
2022-02-06 12:34:13 +0100 | <lambdabot> | error: |
2022-02-06 12:34:13 +0100 | <lambdabot> | • Couldn't match type ‘[]’ with ‘Maybe’ |
2022-02-06 12:34:13 +0100 | <lambdabot> | Expected type: Maybe Char |
2022-02-06 12:34:33 +0100 | <galactic_starfis> | yeah, floating window retention and optional covering support are all that're left to do |
2022-02-06 12:34:44 +0100 | <geekosaur> | > do Just x <- listToMaybe [1]; Just (show x) |
2022-02-06 12:34:45 +0100 | <lambdabot> | error: |
2022-02-06 12:34:45 +0100 | <lambdabot> | • No instance for (Num (Maybe ())) arising from the literal ‘1’ |
2022-02-06 12:34:45 +0100 | <lambdabot> | • In the expression: 1 |
2022-02-06 12:35:08 +0100 | <geekosaur> | really need an IO instance rather than trying to hack it… |
2022-02-06 12:35:11 +0100 | <galactic_starfis> | It's not the cleanest implementation, as that rectangle based one you highlighted is probably better... But it works! |
2022-02-06 12:35:47 +0100 | <galactic_starfis> | Just switched my entire config over to using it. So much better than the fullFloat that ewmh is using |
2022-02-06 12:36:35 +0100 | <galactic_starfis> | I created really awkward stack modification functions a while ago, just to attempt to overcome this problem... Definitely not the way to go. |
2022-02-06 12:37:39 +0100 | <galactic_starfis> | (they didn't really work well) |
2022-02-06 12:37:41 +0100 | steve__ | (~steve@ool-182c2b80.dyn.optonline.net) |
2022-02-06 12:40:25 +0100 | <galactic_starfis> | Anything glaring that I should be doing differently?: https://gitlab.com/mikenrafter/config/-/tree/master/.xmonad/lib/Custom (see Fullscreen.hs, Magnfier.hs, and EwmhDesktops.hs) |
2022-02-06 13:44:24 +0100 | thunderrd | (~thunderrd@183.182.114.80) (Quit: If it wasn't written down it didn't happen...) |
2022-02-06 13:44:55 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 13:46:52 +0100 | thunderrd | (~thunderrd@183.182.114.80) (Client Quit) |
2022-02-06 13:47:16 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 15:05:08 +0100 | thunderrd | (~thunderrd@183.182.114.80) (Remote host closed the connection) |
2022-02-06 15:06:26 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 15:10:12 +0100 | thunderrd | (~thunderrd@183.182.114.80) (Remote host closed the connection) |
2022-02-06 15:14:44 +0100 | Buliarous | (~gypsydang@46.232.210.139) (Ping timeout: 268 seconds) |
2022-02-06 15:31:26 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
2022-02-06 15:31:26 +0100 | allbery_b | (~geekosaur@xmonad/geekosaur) |
2022-02-06 15:31:29 +0100 | allbery_b | geekosaur |
2022-02-06 15:43:08 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 15:46:17 +0100 | mvk | (~mvk@2607:fea8:5cdc:bf00::80f1) (Ping timeout: 240 seconds) |
2022-02-06 15:53:56 +0100 | thunderrd | (~thunderrd@183.182.114.80) (Remote host closed the connection) |
2022-02-06 15:54:52 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 16:34:00 +0100 | catman | (~catman@user/catman) |
2022-02-06 16:46:36 +0100 | mvk | (~mvk@2607:fea8:5cdc:bf00::80f1) |
2022-02-06 16:53:24 +0100 | jao | (~jao@static-68-235-44-10.cust.tzulo.com) |
2022-02-06 18:06:53 +0100 | thunderrd | (~thunderrd@183.182.114.80) (Remote host closed the connection) |
2022-02-06 18:07:55 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 18:28:44 +0100 | thunderrd | (~thunderrd@183.182.114.80) (Remote host closed the connection) |
2022-02-06 18:29:55 +0100 | thunderrd | (~thunderrd@183.182.114.80) |
2022-02-06 19:12:03 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
2022-02-06 19:54:43 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
2022-02-06 20:43:19 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
2022-02-06 20:45:10 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
2022-02-06 21:41:59 +0100 | <galactic_starfis> | I'm trying to add fullscreen support via managehook as well, this' what I've tried, and it's not worked. Pointers? `isFullscreen -?> (\x -> doF $ addFS x )` |
2022-02-06 21:42:17 +0100 | <galactic_starfis> | oh, sorry, whereas addFS is of type `Window -> X ()` |
2022-02-06 21:43:07 +0100 | <geekosaur> | ask >>= doF . addFS |
2022-02-06 21:44:26 +0100 | <geekosaur> | mm, actually, not sure you need doF if you do that.*pokes* |
2022-02-06 21:45:16 +0100 | <geekosaur> | whoops, going to take a bit, ghci is rebuilding the world :/ |
2022-02-06 21:46:10 +0100 | <galactic_starfis> | with doF: `Expected type: Window -> s0 -> s0 Actual type: Window -> X ()` |
2022-02-06 21:46:31 +0100 | <galactic_starfis> | without doF: `Expected type: Query () Actual type: X ()` |
2022-02-06 21:47:04 +0100 | <geekosaur> | ask >>= liftX . addFS, then |
2022-02-06 21:48:50 +0100 | <galactic_starfis> | `• Couldn't match expected type ‘X a0’ with actual type ‘Window -> X ()’` |
2022-02-06 21:49:49 +0100 | <galactic_starfis> | oh wait, no that's when using `$` instead of `.`, it gives this when using `.`: `Expected type: Query (Maybe (Endo WindowSet)) Actual type: Query (Maybe ())` |
2022-02-06 21:51:01 +0100 | <geekosaur> | ask >>= \x -> liftX (?addFS x) >> idHook |
2022-02-06 21:51:01 +0100 | <geekosaur> | :: (?addFS::Window -> X a, Monoid b) => Query b |
2022-02-06 21:51:13 +0100 | <geekosaur> | hardfor me to test since I don't have addFS locally |
2022-02-06 21:51:53 +0100 | <galactic_starfis> | it's present here: https://gitlab.com/mikenrafter/config/-/blob/master/.xmonad/lib/Custom/Fullscreen.hs#L60 |
2022-02-06 21:52:13 +0100 | <geekosaur> | isFullscreen -?> ask >>= \x -> liftX (?addFS x) >> idHook |
2022-02-06 21:52:13 +0100 | <geekosaur> | :: (?addFS::Window -> X a1, Monoid a2) => Query (Maybe a2) |
2022-02-06 21:54:30 +0100 | <geekosaur> | def {manageHook = composeOne [isFullscreen -?> ask >>= \x -> liftX (?addFS x) >> idHook]} |
2022-02-06 21:54:30 +0100 | <geekosaur> | :: (?addFS::Window -> X a) => |
2022-02-06 21:54:30 +0100 | <geekosaur> | XConfig (Choose Tall (Choose (Mirror Tall) Full)) |
2022-02-06 21:54:43 +0100 | <geekosaur> | that looks like it ought work |
2022-02-06 21:56:10 +0100 | Hash | (~Hash@hashsecurity.org) |
2022-02-06 22:00:28 +0100 | Marmota | (~Marmota@2804:7f6:8086:31dc:d3da:cd9f:2c17:5ca6) |
2022-02-06 22:00:58 +0100 | <galactic_starfis> | boom, worked, thanks! |
2022-02-06 22:13:41 +0100 | Marmota | (~Marmota@2804:7f6:8086:31dc:d3da:cd9f:2c17:5ca6) (Quit: Client closed) |
2022-02-06 22:36:49 +0100 | sheb | (~sheb@31.223.228.71) |
2022-02-06 23:21:06 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
2022-02-06 23:37:15 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
2022-02-06 23:45:18 +0100 | Guest54 | (~Guest54@47.153.196.157) |
2022-02-06 23:46:27 +0100 | <Guest54> | Using xmobar I have a com module for playerctl to put title and artist, however when spotify isn't running it says "Could not execute command playerctl, is there anyway to hide this? |
2022-02-06 23:48:11 +0100 | <galactic_starfis> | Use a custom script (bash would work fine), save the output to a local variable, and grep for "Could not execute command playerctl", then if you find it, echo out "", otherwise echo out the saved output. |
2022-02-06 23:50:15 +0100 | <geekosaur> | that's assuming the "Could not execute" is from playerctl, which seems odd. more likely that's the plugin reporting on an error return from playerctl, hence a wrapper script `/usr/bin/playerctl ${1+"$@"} 2>/dev/null || echo` |
2022-02-06 23:51:10 +0100 | <Guest54> | would that be baked in the custom script, or within .xmobarrc |
2022-02-06 23:51:46 +0100 | <geekosaur> | in the custom script. .xmobarrc almost certainly doesn't give you controlover this |
2022-02-06 23:51:53 +0100 | <liskin> | note that playerctl also has --follow, which then doesn't need periodical refresh as it prints additional lines whenever something changes |
2022-02-06 23:51:55 +0100 | <galactic_starfis> | trying to put stuff like that in xmobarrc can be a real pain, probably best to use a custom script |
2022-02-06 23:52:49 +0100 | <galactic_starfis> | --- |
2022-02-06 23:52:49 +0100 | <galactic_starfis> | X.L.Magnifier only magnifies the focused window, meaning when you switch to a floating window, it stops magnifying whatever you were last on. Is there a simple remedy for this? I was thinking perhaps I could tag the focused tiled window, and untag it when it loses focus to another tiled window. And magnify that, only, I'm not sure how I'd get that from just a `Stack` object.. |
2022-02-06 23:53:30 +0100 | <liskin> | (and I'm almost certain playerctl --follow doesn't terminate when the last player goes away, as I've had it running in the background for a year and a half) |
2022-02-06 23:57:37 +0100 | Buliarous | (~gypsydang@46.232.210.139) |