| 2023-01-01 00:01:57 +0100 | Janoo | (~username@c-bc15225c.010-598-73746f7.bbcust.telenor.se) () |
| 2023-01-01 01:00:48 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:4bae:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 2023-01-01 02:11:20 +0100 | k` | (~user@2605:a601:a60d:5400:7c8d:c18:bab3:ff90) |
| 2023-01-01 02:12:43 +0100 | <k`> | can anyone who uses nixos tell me whether there's any way to actually use `services.xserver.windowManager.xmonad.config` ? |
| 2023-01-01 02:27:15 +0100 | <k`> | It seems to compile properly when you include all the required imports in extraPackages, but changing the config and then running `nixos-rebuild switch` does not seem to actually change the xmonad settings. |
| 2023-01-01 03:21:27 +0100 | k` | (~user@2605:a601:a60d:5400:7c8d:c18:bab3:ff90) (Remote host closed the connection) |
| 2023-01-01 04:03:06 +0100 | banc | (banc@gateway/vpn/protonvpn/banc) (Ping timeout: 272 seconds) |
| 2023-01-01 04:17:02 +0100 | td_ | (~td@83.135.9.29) (Ping timeout: 272 seconds) |
| 2023-01-01 04:18:23 +0100 | td_ | (~td@83.135.9.35) |
| 2023-01-01 04:24:30 +0100 | banc | (banc@gateway/vpn/protonvpn/banc) |
| 2023-01-01 04:56:53 +0100 | tremon | (~tremon@83-85-213-108.cable.dynamic.v4.ziggo.nl) (Quit: getting boxed in) |
| 2023-01-01 04:58:49 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 260 seconds) |
| 2023-01-01 05:00:42 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-01-01 07:04:27 +0100 | jabuxas | (~jabuxas@user/jabuxas) (Ping timeout: 248 seconds) |
| 2023-01-01 07:06:08 +0100 | jabuxas | (~jabuxas@user/jabuxas) |
| 2023-01-01 10:00:12 +0100 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle) |
| 2023-01-01 12:28:41 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-01-01 12:49:43 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-01-01 12:57:10 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-01-01 13:47:07 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:4bae:6245:cbff:fe9f:48b1) |
| 2023-01-01 13:47:39 +0100 | <thyriaen> | can i spawn windows always on first monitor no matter which has focus ? |
| 2023-01-01 13:47:52 +0100 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) |
| 2023-01-01 13:52:48 +0100 | <thyriaen> | to clarify - i want to spawn it on the current workspace that is active on my first monitor even if my 2nd one has focus |
| 2023-01-01 13:54:38 +0100 | <thyriaen> | my workspaces are withScreens |
| 2023-01-01 13:55:06 +0100 | <thyriaen> | i use the IndependentScreens layout |
| 2023-01-01 14:03:54 +0100 | <thyriaen> | and i want to use that whole thing in a scratchpad |
| 2023-01-01 14:07:42 +0100 | <Solid> | thyriaen: as in, all windows? In that case, just a simple manageHook would do |
| 2023-01-01 14:08:17 +0100 | <thyriaen> | no |
| 2023-01-01 14:08:22 +0100 | <thyriaen> | just one specific window |
| 2023-01-01 14:08:37 +0100 | <Solid> | as long as you can match on it, that should be fine as well |
| 2023-01-01 14:08:58 +0100 | <thyriaen> | Solid, how do i do that ? |
| 2023-01-01 14:09:36 +0100 | <thyriaen> | Solid, https://paste.tomsmeding.com/IdS9qZ2M I want to change my scratchpad to always be on currently active workspace of the main screen |
| 2023-01-01 14:10:21 +0100 | <thyriaen> | Solid, and some other windows i can identify by className for example or replace the spawn command |
| 2023-01-01 14:16:01 +0100 | <Solid> | it's probably more complicated for scratchpads, since once you summon them once they just get moved to another workspace and the manageHook isn't executed after that |
| 2023-01-01 14:16:18 +0100 | <Solid> | but for normal windows you can just do something like "appName =? "my-query" --> doShift . fromJust =<< liftX (screenWorkspace 0)" |
| 2023-01-01 14:19:10 +0100 | <thyriaen> | Solid, ok thanks |
| 2023-01-01 14:19:13 +0100 | <thyriaen> | and for scratchpads ? |
| 2023-01-01 14:28:10 +0100 | <Solid> | mh, I reckon you'd need to check for that in a logHook or something |
| 2023-01-01 14:28:17 +0100 | <Solid> | but it's probably going to be a bit annoying |
| 2023-01-01 14:30:25 +0100 | <thyriaen> | ic |
| 2023-01-01 14:50:01 +0100 | <geekosaur> | scratchpads have associated manageHooks, you should be able to do that in that and drop the matcher because the scratchpad stuff already does the matching |
| 2023-01-01 14:52:31 +0100 | <geekosaur> | you do it where you have the `customFloating` stuff now, and combine them with `<>` |
| 2023-01-01 14:52:53 +0100 | <geekosaur> | thyriaen ^^ |
| 2023-01-01 14:53:45 +0100 | <Solid> | geekosaur: that'd only work on the first invocation |
| 2023-01-01 14:53:57 +0100 | <geekosaur> | mm, true |
| 2023-01-01 14:54:14 +0100 | <Solid> | btw, happy new year :) |
| 2023-01-01 14:56:21 +0100 | <geekosaur> | happy new year to you too |
| 2023-01-01 14:56:38 +0100 | <geekosaur> | no control at all over later invocations, they pop up on the focused workspace |
| 2023-01-01 14:58:18 +0100 | <thyriaen> | Year ( Happy New ) |
| 2023-01-01 14:58:21 +0100 | <Solid> | could probably save the window ID to some state in the manageHook and then check against that in the logHook |
| 2023-01-01 14:59:14 +0100 | <thyriaen> | geekosaur, good to have you around |
| 2023-01-01 15:00:18 +0100 | <geekosaur> | can't use the `logHook` for this unless you've applied those patches Leary submitted; it'd cause an infinite loop |
| 2023-01-01 15:00:52 +0100 | <Solid> | oh, right, moving would involve invoking `windows` |
| 2023-01-01 17:02:19 +0100 | <a[m]1> | When using nerd fonts with the pango format, my bar doesn't show. Would anyone know why? |
| 2023-01-01 17:03:28 +0100 | <a[m]1> | I fixed it, but now changing the font seems to do nothin |
| 2023-01-01 18:06:28 +0100 | tremon | (~tremon@83-85-213-108.cable.dynamic.v4.ziggo.nl) |
| 2023-01-01 18:10:21 +0100 | <thyriaen> | when I use picom with xmonad - only my chrome browser gets transparent borders - any ideas is this known ? |
| 2023-01-01 18:24:19 +0100 | jimfarrand[m] | (~jimfarran@2001:470:69fc:105::2:eab7) |
| 2023-01-01 18:27:13 +0100 | <geekosaur[m]> | Sounds like you're on 0.17.0 |
| 2023-01-01 18:27:59 +0100 | <geekosaur[m]> | Upgrade |
| 2023-01-01 18:33:22 +0100 | <thyriaen> | OH ! |
| 2023-01-01 18:33:55 +0100 | <thyriaen> | geekosaur[m], i am on 17.0 yes |
| 2023-01-01 18:35:02 +0100 | <thyriaen> | geekosaur[m], not packaged with fedora on a higher version ;/ |
| 2023-01-01 18:37:12 +0100 | <geekosaur[m]> | Isn't there some way to subscribe to a pre-release channel with dnf? |
| 2023-01-01 18:37:28 +0100 | <thyriaen> | there is fedora-rawhide but they also just have 17.0 |
| 2023-01-01 18:38:38 +0100 | <geekosaur[m]> | Then you're stuck unless you switch to cabal or git |
| 2023-01-01 18:38:55 +0100 | <thyriaen> | cabal? |
| 2023-01-01 18:39:14 +0100 | <thyriaen> | do you know when to expect fedora inclusion of 17.1 ? |
| 2023-01-01 18:39:47 +0100 | <thyriaen> | geekosaur[m], how do i install with cabal ? |
| 2023-01-01 18:40:16 +0100 | <geekosaur[m]> | No clue, I'm an Ubuntu user |
| 2023-01-01 18:41:58 +0100 | <geekosaur[m]> | Instructions for cabal or stack should be in the install documents on the website. I'm at my sister's house occasionally looking at my phone so can't help much right now |
| 2023-01-01 18:42:12 +0100 | <geekosaur[m]> | Will be back home later today |
| 2023-01-01 18:42:14 +0100 | <thyriaen> | geekosaur[m], thanks - take care :p |
| 2023-01-01 18:48:24 +0100 | <jimfarrand[m]> | Installing via Cabal is a moderately adventurous endeavour. It's not impossible, but it's also not really optimised for end-users of software. |
| 2023-01-01 18:48:24 +0100 | <jimfarrand[m]> | First step is to get a working GHC environment. |
| 2023-01-01 18:48:24 +0100 | <jimfarrand[m]> | https://www.haskell.org/cabal/ |
| 2023-01-01 18:50:46 +0100 | <geekosaur[m]> | There's also stack which makes it somewhat simpler. But it's tempting to say that if you're putting in the effort, might as well go all the way and build from git |
| 2023-01-01 18:52:56 +0100 | jimfarrand[m] | jifarra[m] |
| 2023-01-01 19:54:18 +0100 | <HB[m]> | https://xmonad.org/INSTALL.html#build-using-stack I have used these instructions with great success |
| 2023-01-01 20:18:33 +0100 | <geekosaur> | Okay, I'm back home if you still need help |
| 2023-01-01 20:26:10 +0100 | <HB[m]> | Hey happy new year! 🙂 |
| 2023-01-01 20:27:13 +0100 | <geekosaur> | happy new year! |
| 2023-01-01 20:38:18 +0100 | <thyriaen> | How can i get the xprop from the frame drawn by "maim" ? |
| 2023-01-01 20:41:55 +0100 | <HB[m]> | The frame that you draw yourself with the mouse? |
| 2023-01-01 20:42:19 +0100 | <thyriaen> | HB[m], aye |
| 2023-01-01 20:42:36 +0100 | <thyriaen> | that's why it will be difficult to click it with the xprop command :p |
| 2023-01-01 20:42:45 +0100 | <HB[m]> | Well, the mouse is busy, so xprop isn't going to work. |
| 2023-01-01 20:43:12 +0100 | <geekosaur> | if you mean the border xmonad draws, that is inside the maim window so just click that |
| 2023-01-01 20:43:34 +0100 | <geekosaur> | if it's drawing a separate frame, that should also be inside (properties are set on top level windows) |
| 2023-01-01 20:44:47 +0100 | <thyriaen> | geekosaur, no i mean the thing that maim draws |
| 2023-01-01 20:46:50 +0100 | <geekosaur> | oh, the screenshot thing? that's override-redirect so you can't do much with it from xmonad |
| 2023-01-01 20:47:07 +0100 | <geekosaur> | what did you want to do with it? |
| 2023-01-01 20:47:07 +0100 | <HB[m]> | So when you use scrot or another screenshot program, it lets you draw an area on screen with mouse, the rectangle which it takes a shot of. |
| 2023-01-01 20:47:18 +0100 | <HB[m]> | He wants to get xprop for that rectangle. |
| 2023-01-01 20:47:21 +0100 | <HB[m]> | * that rectangle. I think. |
| 2023-01-01 20:47:40 +0100 | <geekosaur> | right, so that is override-redirect and not visible to xmonad |
| 2023-01-01 20:47:56 +0100 | <geekosaur> | and very likely has no properties anyway |
| 2023-01-01 20:47:59 +0100 | <HB[m]> | There you go |
| 2023-01-01 20:48:50 +0100 | <geekosaur> | I am looking at https://github.com/naelstrof/maim now |
| 2023-01-01 20:53:54 +0100 | <geekosaur> | (moreover, in most cases it's done a screen grab so xmonad couldn't do anything even if it had the window id) |
| 2023-01-01 21:14:45 +0100 | Forkk | (~forkk@li926-228.members.linode.com) (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2023-01-01 21:15:11 +0100 | Forkk | (~forkk@li926-228.members.linode.com) |
| 2023-01-01 21:49:10 +0100 | abhixec | (~abhinav@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2023-01-01 21:55:35 +0100 | abhixec | (~abhinav@c-67-169-139-16.hsd1.ca.comcast.net) (Ping timeout: 265 seconds) |
| 2023-01-01 22:09:54 +0100 | <thyriaen> | geekosaur, i want picom to not draw a shadow on the border :p |
| 2023-01-01 22:11:48 +0100 | <thyriaen> | HB[m], and for this i need to identify it somehow for example the window class or something |
| 2023-01-01 22:12:00 +0100 | <thyriaen> | i know by trial and error that the type is normal but that doesn't help me |
| 2023-01-01 22:16:43 +0100 | <geekosaur> | I strongly suspect that without delving into the code for maim and finding a property it sets (if any), you'll need: shadow-exclude = [ override_redirect@: ] |
| 2023-01-01 22:18:07 +0100 | <geekosaur> | (if you have other shadow-exclude items, add that to the list instead of specifying it separately) |
| 2023-01-01 22:21:41 +0100 | <thyriaen> | what does override_redirect@: do ? |
| 2023-01-01 22:23:00 +0100 | <thyriaen> | apart from generating a syntax error :p |
| 2023-01-01 22:26:53 +0100 | <thyriaen> | not sure how to properly integrate it into the config file but starting picom with picom --shadow-exclude="override_redirect = true" does the trick |
| 2023-01-01 22:27:31 +0100 | <thyriaen> | geekosaur, what does it do ? |
| 2023-01-01 22:29:33 +0100 | <geekosaur> | interesting, I wonder if they changed the syntax in later versions (I'm running a very early one that still calls itself compton) |
| 2023-01-01 22:30:45 +0100 | <geekosaur> | `override_redirect@:` means match override-redirect windows without frames; the colon is reported by the documentation to be required, and is normally followed by a type but built-in things like override_redirect don't have types |
| 2023-01-01 22:32:40 +0100 | <thyriaen> | i see |
| 2023-01-01 22:32:42 +0100 | <geekosaur> | I may have missed part of it, also |
| 2023-01-01 22:33:18 +0100 | <geekosaur> | picom configuration is fairly complicated |
| 2023-01-01 22:33:19 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-01-01 22:33:21 +0100 | <thyriaen> | https://wiki.archlinux.org/title/Picom_ well here i got the syntax from |
| 2023-01-01 22:33:57 +0100 | <thyriaen> | since i have an array for the focus-exclude in my config file i decided better not mess with it and use it as argument |
| 2023-01-01 22:34:15 +0100 | <thyriaen> | hang on |
| 2023-01-01 22:34:31 +0100 | <thyriaen> | geekosaur, does that mean that polybar will also not have a shadow ? |
| 2023-01-01 22:34:34 +0100 | <geekosaur> | I just dug through maim and the slop library it uses for selection, and it sets no properties on the selection window |
| 2023-01-01 22:34:51 +0100 | <thyriaen> | also rofi lost it's shadow :/ |
| 2023-01-01 22:34:53 +0100 | <thyriaen> | but i want it |
| 2023-01-01 22:35:13 +0100 | <geekosaur> | then you have a problem because there's no properties to match against |
| 2023-01-01 22:35:23 +0100 | <geekosaur> | although, hm… |
| 2023-01-01 22:39:31 +0100 | <geekosaur> | override_redirect = true && !_NET_WM_WINDOW_TYPE:32a |
| 2023-01-01 22:39:55 +0100 | <geekosaur> | hopefully that matches override-redirect windows that don't have a window type set |
| 2023-01-01 22:40:24 +0100 | <thyriaen> | what is the type 32a ? |
| 2023-01-01 22:40:32 +0100 | <geekosaur> | 32-bit atom |
| 2023-01-01 22:40:44 +0100 | <thyriaen> | i will try it real quick :p |
| 2023-01-01 22:40:55 +0100 | <geekosaur> | you can use xlsatoms to see the defined atoms |
| 2023-01-01 22:41:10 +0100 | <geekosaur> | the "32" should be optional since it's the default size of atoms |
| 2023-01-01 22:41:58 +0100 | <thyriaen> | i think something has to be escaped |
| 2023-01-01 22:42:37 +0100 | <thyriaen> | unfortunately rofi still has no shadow |
| 2023-01-01 22:42:48 +0100 | <thyriaen> | i escaped the \1 |
| 2023-01-01 22:42:50 +0100 | <thyriaen> | \! |
| 2023-01-01 22:43:01 +0100 | <geekosaur> | oh, yes, some shells will require that |
| 2023-01-01 22:43:25 +0100 | <geekosaur> | I set stuff in the config file so I don't have to worry about shell issues |
| 2023-01-01 22:44:02 +0100 | <thyriaen> | my rofi window also doesnt have a window type |
| 2023-01-01 22:44:13 +0100 | <geekosaur> | you would have to xprop rofi to find out what properties it has that we might check for |
| 2023-01-01 22:44:16 +0100 | <thyriaen> | can we do the same approach but use wm_class ? |
| 2023-01-01 22:44:45 +0100 | <geekosaur> | sure, use !WM_CLASS:s instead of !_NET_WM_WINDOW_TYPE:32a |
| 2023-01-01 22:45:12 +0100 | <thyriaen> | xD |
| 2023-01-01 22:45:15 +0100 | <thyriaen> | turns out |
| 2023-01-01 22:45:22 +0100 | <thyriaen> | this maim border has a wm_class |
| 2023-01-01 22:45:42 +0100 | <thyriaen> | but rofi now has a shadow again but so does the border |
| 2023-01-01 22:45:45 +0100 | <geekosaur> | hm, I couldn't find any properties being set on the window |
| 2023-01-01 22:46:09 +0100 | <geekosaur> | !WM_NAME:s maybe? |
| 2023-01-01 22:46:36 +0100 | <thyriaen> | werks |
| 2023-01-01 22:46:49 +0100 | <thyriaen> | neat ! thanks |
| 2023-01-01 22:46:52 +0100 | <thyriaen> | one more question |
| 2023-01-01 22:48:03 +0100 | <thyriaen> | i know this is out of scope of this channel but, i have rounded rounded corners in rofi -- however picom things these rounded transparent corners in rofi "still exsists" so it draws the shadow around this imaginary squared off window |
| 2023-01-01 22:48:28 +0100 | <thyriaen> | that is an exceptionally bad description |
| 2023-01-01 22:49:52 +0100 | <geekosaur> | --detect-rounded-corners? |
| 2023-01-01 22:49:57 +0100 | <thyriaen> | already active |
| 2023-01-01 22:50:19 +0100 | <geekosaur> | that saitd it looks from the docs I have that there is no actual solution, the best you can do is just disable shadows for those windows |
| 2023-01-01 22:50:43 +0100 | <geekosaur> | --shadow-ignore-shaped |
| 2023-01-01 22:51:22 +0100 | <thyriaen> | i think a better workaround would be to make it squared and let picom do the rounding of the corners |
| 2023-01-01 22:51:37 +0100 | <thyriaen> | https://paste.tomsmeding.com/XYCNiCrq |
| 2023-01-01 22:51:52 +0100 | <thyriaen> | maybe you find an improvement that wokrs around this issue |
| 2023-01-01 22:53:01 +0100 | <geekosaur> | like I said, I have a very early version of picom. it doesn't know how to round corners itself |
| 2023-01-01 22:53:11 +0100 | <thyriaen> | ah ok |
| 2023-01-01 22:53:16 +0100 | <thyriaen> | well thanks for your help anyways |
| 2023-01-01 22:53:21 +0100 | <thyriaen> | fixed my main issue :p |
| 2023-01-01 23:21:36 +0100 | Lin[m] | Chilli[m] |
| 2023-01-01 23:50:59 +0100 | de-vri-es | (~de-vri-es@voyager.de-vri.es) (Quit: Bathrobe!) |
| 2023-01-01 23:51:28 +0100 | de-vri-es | (~de-vri-es@voyager.de-vri.es) |
| 2023-01-01 23:57:12 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:4bae:6245:cbff:fe9f:48b1) (Quit: Leaving) |