IRCBrowse

2021/10/17

2021-10-17 00:14:21 +0200wonko(~wjc@62.115.229.50) (Ping timeout: 268 seconds)
2021-10-17 00:33:04 +0200dschrempf(~dominik@070-207.dynamic.dsl.fonira.net)
2021-10-17 00:33:13 +0200dschrempf(~dominik@070-207.dynamic.dsl.fonira.net) (Client Quit)
2021-10-17 00:44:30 +0200alternateved(~user@194.177.28.164) (Ping timeout: 260 seconds)
2021-10-17 00:50:54 +0200seschwar(~seschwar@user/seschwar) (Quit: :wq)
2021-10-17 01:24:30 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-10-17 01:44:12 +0200 <davve> hey, this is my layout hook https://paste.ofcode.org/wNDqTY4q8S3EsrCgVJcZS3 it works as i want except for that i dont want to avoid struts for Full, how would someone haskell savvy do it differently?
2021-10-17 01:44:33 +0200 <davve> s/differently//
2021-10-17 01:46:42 +0200 <davve> s/savvy/knowledgable/
2021-10-17 01:47:19 +0200 <geekosaur> thi is slightly weird since you have spacing in there twice
2021-10-17 01:47:33 +0200 <davve> oh
2021-10-17 01:47:41 +0200 <davve> i didnt realize that :)
2021-10-17 01:47:46 +0200 <geekosaur> but that actually shows you how to do it, since you use tiled on both the cases you also want avoidStruts on
2021-10-17 01:48:16 +0200 <geekosaur> then noBorders Full becomes (noBorders . avoidStrutsOn []) Full
2021-10-17 01:48:52 +0200 <geekosaur> and you also want smartBorders in the definition of tiled rather than outside, since you want the noBorders instead on the Full
2021-10-17 01:49:56 +0200 <davve> thank you, just taking a few minutes to digest
2021-10-17 01:57:47 +0200 <davve> think i misspoke. i actually want to Not avoid struts
2021-10-17 01:58:48 +0200 <davve> -_-
2021-10-17 01:59:55 +0200 <davve> which is what makes it more difficult, since i have (what i thought was nicely defined!) general definition of the layout
2021-10-17 01:59:59 +0200 <geekosaur> that's why it's avoidStrutsOnb []
2021-10-17 02:00:36 +0200 <geekosaur> the way the strut stuff is designed, you have to have the layout modifier there. but you're telling it to avoid struts nowhere
2021-10-17 02:01:00 +0200 <geekosaur> this also means you can mod-b (or whatever) to turn them on temporarily
2021-10-17 02:01:17 +0200 <davve> I see
2021-10-17 02:01:20 +0200mestre(~mestre@191.177.175.57) (Quit: leaving)
2021-10-17 02:02:44 +0200 <geekosaur> anyway I'd put the stuff I want to apply to the tiled layouts in tiled (none of them will be affected by Mirror so that's not an issue) and put the other ones (noBorders, avoidStrutsOn []) on Full
2021-10-17 02:05:04 +0200 <geekosaur> hm, actually I wonder if that's true. avoidStruts might do something weird inside Mirror
2021-10-17 02:05:44 +0200s(~s@24.16.46.64)
2021-10-17 02:05:57 +0200s(~s@24.16.46.64) (Client Quit)
2021-10-17 02:39:25 +0200tomsmeding(~tomsmedin@tomsmeding.com) (Quit: ZNC 1.8.2 - https://znc.in)
2021-10-17 02:39:55 +0200tomsmeding(~tomsmedin@tomsmeding.com)
2021-10-17 02:52:39 +0200allbery_b(~geekosaur@xmonad/geekosaur)
2021-10-17 02:52:39 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b)))
2021-10-17 02:52:42 +0200allbery_bgeekosaur
2021-10-17 04:02:47 +0200banc(banc@gateway/vpn/airvpn/banc) (Ping timeout: 264 seconds)
2021-10-17 04:10:43 +0200catman(~catman@user/catman) (Quit: WeeChat 3.4-dev)
2021-10-17 04:15:29 +0200catman(~catman@user/catman)
2021-10-17 04:23:59 +0200banc(banc@gateway/vpn/airvpn/banc)
2021-10-17 04:28:29 +0200HashHelloNewman
2021-10-17 04:36:05 +0200catman(~catman@user/catman) (Remote host closed the connection)
2021-10-17 06:49:01 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Ping timeout: 268 seconds)
2021-10-17 07:38:58 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
2021-10-17 07:53:05 +0200geekosaur(~geekosaur@xmonad/geekosaur)
2021-10-17 08:18:06 +0200benin(~benin@183.82.25.86)
2021-10-17 09:24:59 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 264 seconds)
2021-10-17 09:44:13 +0200wonko(~wjc@62.115.229.50)
2021-10-17 10:17:48 +0200allbery_b(~geekosaur@xmonad/geekosaur)
2021-10-17 10:17:48 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b)))
2021-10-17 10:17:51 +0200allbery_bgeekosaur
2021-10-17 10:34:29 +0200humky(~humky@user/humky)
2021-10-17 10:55:39 +0200mc47(~mc47@xmonad/TheMC47)
2021-10-17 11:08:58 +0200seschwar(~seschwar@user/seschwar)
2021-10-17 11:14:30 +0200alternateved(~user@194.177.28.164)
2021-10-17 11:26:11 +0200benin(~benin@183.82.25.86) (Ping timeout: 264 seconds)
2021-10-17 11:28:09 +0200benin(~benin@183.82.25.86)
2021-10-17 11:34:10 +0200wz1000(~zubin@static.11.113.47.78.clients.your-server.de) (Ping timeout: 252 seconds)
2021-10-17 12:37:25 +0200Solitary(~Solitary@user/solitary) (Ping timeout: 252 seconds)
2021-10-17 12:38:43 +0200Solitary(~Solitary@user/solitary)
2021-10-17 12:48:09 +0200td_(~td@94.134.91.73)
2021-10-17 13:12:23 +0200alternateved(~user@194.177.28.164) (Ping timeout: 264 seconds)
2021-10-17 13:22:36 +0200liskinhas just finished writing the first draft of XMonad.Util.EWMH module \o/
2021-10-17 13:27:22 +0200humky(~humky@user/humky) (Quit: Leaving)
2021-10-17 13:29:07 +0200humky(~humky@user/humky)
2021-10-17 13:30:10 +0200 <Solid> /o/ \o/ \o\
2021-10-17 13:31:31 +0200 <geekosaur> w00t
2021-10-17 14:02:39 +0200mestre(~mestre@191.177.175.57)
2021-10-17 14:10:11 +0200 <FOSSHuman[m]> > * <@liskin:libera.chat> has just finished writing the first draft of XMonad.Util.EWMH module \o/
2021-10-17 14:10:11 +0200 <FOSSHuman[m]> :))
2021-10-17 14:10:14 +0200 <lambdabot> <hint>:1:1: error: parse error on input ‘*’
2021-10-17 14:17:07 +0200 <FOSSHuman[m]> <liskin> "oh, that may not be an overrider..." <- Tried this out today and it worked in combination with the Util.Hacks trayAbovePanelEventHook...
2021-10-17 14:17:14 +0200 <FOSSHuman[m]> * out today in the manageHook of my config and it
2021-10-17 14:33:26 +0200 <FOSSHuman[m]> <liskin> "oh, that may not be an overrider..." <- Just added a manageHook with doLower and stalonetray className matching to my config and it seems to work for now, as a temporary solution...
2021-10-17 14:34:26 +0200wz1000(~zubin@static.11.113.47.78.clients.your-server.de)
2021-10-17 14:40:05 +0200 <FOSSHuman[m]> * className matching and Util.Hacks trayAbovePanelEventHook to my
2021-10-17 14:46:03 +0200 <liskin> FOSSHuman[m]: good
2021-10-17 15:31:27 +0200alternateved(~user@194.177.28.171)
2021-10-17 16:33:46 +0200 <mc47> liskin, awesome!
2021-10-17 16:39:13 +0200jonahgs(~jonahgs@c-73-9-97-169.hsd1.il.comcast.net)
2021-10-17 16:49:51 +0200jonahgs(~jonahgs@c-73-9-97-169.hsd1.il.comcast.net) (Quit: Leaving)
2021-10-17 16:51:17 +0200 <liskin> geekosaur: do you happen to know what exactly is meant by "hints" in the specification for _NET_SUPPORTED (https://specifications.freedesktop.org/wm-spec/latest/ar01s03.html#idm45623294106896)?
2021-10-17 16:52:17 +0200 <liskin> like e.g. with _NET_NUMBER_OF_DESKTOPS (https://specifications.freedesktop.org/wm-spec/latest/ar01s03.html#idm45623294103328), does having _NET_NUMBER_OF_DESKTOPS in _NET_SUPPORTED mean the WM supports both the property and the client message?
2021-10-17 16:52:47 +0200 <geekosaur> it pretty much tells you; you're supposed to liust any EWMH atoms you support (and their parents, as shown)
2021-10-17 16:54:29 +0200 <geekosaur> basically anything named in the ICCCM, which EWMH builds upon, is a hint. window managers are free to ignore or interpret the hints as they see fit, and clients must accept it
2021-10-17 16:55:43 +0200 <geekosaur> it means both, but note "The Window Manager is free to honor or reject this request"
2021-10-17 16:56:32 +0200 <liskin> so if we "reject" it by simply not having any code to handle it, that means we support it, and we should list _NET_NUMBER_OF_DESKTOPS in _NET_SUPPORTED, which we haven't for years?
2021-10-17 16:56:33 +0200 <geekosaur> so if you list it in _NET_SUPPORTED it doesn't actually claim you will do anything with the desktop message
2021-10-17 16:57:57 +0200 <geekosaur> right. the spec tells us what we SHOULD/MUST do *if* we respond to it, but doesn't require us to support it even if we advertise it. this is admittedly something of a weakness in EWMH, but then it gets many things related to pager / WM communication fairly wrong
2021-10-17 16:59:07 +0200 <liskin> okay, thx :-)
2021-10-17 16:59:28 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
2021-10-17 16:59:53 +0200 <liskin> (I probably shouldn't waste much time on this, as we haven't even had _NET_WM_STATE_DEMANDS_ATTENTION for all those years and only last month someone complained)
2021-10-17 17:01:10 +0200geekosaur(~geekosaur@xmonad/geekosaur)
2021-10-17 17:01:17 +0200 <geekosaur> see for example _NET_WM_STATE_SKIP_TASKBAR which is supposed to be set in _NET_SUPPORTED and owned by _NET_WM_STATE, but _NET_SUPPORTED and _NET_WM_STATE belong to the WM while _NET_WM_STATE_SKIP_TASKBAR belongs to the taskbar
2021-10-17 17:01:38 +0200 <geekosaur> EWMH is a cruddy hacked-up mess
2021-10-17 17:02:58 +0200 <liskin> well a decent WM surely has its own integrated taskbar!
2021-10-17 17:04:22 +0200 <liskin> and in our case, _NET_WM_STATE_SKIP_TASKBAR should actually be interpreted by X.H.StatusBar.PP :-)
2021-10-17 17:05:05 +0200 <liskin> (and we can now, indeed, have X.H.StatusBar announce its support for _NET_WM_STATE_SKIP_TASKBAR, if we wanted to do something like that)
2021-10-17 17:05:23 +0200 <liskin> anyway, back to coding :-)
2021-10-17 17:07:16 +0200 <geekosaur> I'm also thinking of my X.U.NoTaskbar which should really check first :)
2021-10-17 17:09:57 +0200 <geekosaur> oh, and PP cares about _SKIP_PAGER not _SKIP_TASKBAR :)
2021-10-17 17:11:06 +0200 <liskin> uh, does it? I'm grepping for SKIP and only finding X.U.NoTaskbar
2021-10-17 17:11:27 +0200 <liskin> oh, you probably meant "should care, if anything"
2021-10-17 17:12:14 +0200 <liskin> (anyway, my mockery about decent WMs having all that integrated still applies :-))
2021-10-17 17:12:31 +0200 <geekosaur> yeh
2021-10-17 17:13:13 +0200 <geekosaur> suppose they don't consider marco a decent WM since it offloads that to applets in mate-panel…
2021-10-17 17:24:08 +0200benin5(~benin@183.82.25.86)
2021-10-17 17:27:41 +0200benin(~benin@183.82.25.86) (Ping timeout: 264 seconds)
2021-10-17 17:27:41 +0200benin5benin
2021-10-17 17:37:14 +0200 <liskin> jakefromstatefar: https://github.com/xmonad/xmonad-contrib/blob/fa3536b40bc121b6cc724ee393b14b7db44db890/XMonad/Hook… is O(n²) with n being the total number of windows across all workspaces so this probably contributes to the slowness somehow (still, one should start with a profiler, not by optimizing random bits of code…)
2021-10-17 17:37:53 +0200HelloNewmanHash
2021-10-17 17:39:48 +0200 <Solid> I mean, anything with nub in it is technically O(n^2) but, as we found out, up until 15 or so windows this is faster than nubOrd and friends :)
2021-10-17 17:41:20 +0200 <geekosaur> people always look at the big-O and forget the constant factors actually matter
2021-10-17 18:13:04 +0200 <liskin> oh well, time for stack build criterion I guess :-)
2021-10-17 18:13:37 +0200 <liskin> (nub [1..10000] takes over a second here in ghci, but a hundred might very well be under a millisec, true)
2021-10-17 18:14:22 +0200 <geekosaur> if someone has 10000 windows, they have bigger problems than how xmonad will deal with them :)
2021-10-17 18:18:55 +0200 <liskin> okay, silly me, nub [1..100] takes 70 μs; nub [1..1000] takes 7 ms
2021-10-17 18:19:22 +0200 <liskin> none of that is in the realm of being perceptible by contemporary humans with contemporary personal computers
2021-10-17 18:20:02 +0200 <geekosaur> even over a second is dubious; consider how long it'd take a human to mod-shift-C 10000 windows
2021-10-17 18:20:21 +0200 <geekosaur> 20 seconds, we have a problem. 1s, not sure we do
2021-10-17 18:20:48 +0200 <liskin> well I didn't mean anyone might actually have 10k windows
2021-10-17 18:21:11 +0200 <liskin> it's just the first number for which length (nub [1..n]) took noticeable time in ghci :-)
2021-10-17 18:21:20 +0200 <liskin> (first power of 10, to be precise)
2021-10-17 18:22:03 +0200liskinis so silly he really did decide to benchmark stuff by looking at how long it feels to eval in ghci
2021-10-17 19:51:35 +0200 <Solid> :D
2021-10-17 19:53:43 +0200 <Solid> I doubt it takes anywhere near as long compiled
2021-10-17 19:54:01 +0200 <Solid> (ghci really is quite slow)
2021-10-17 19:54:53 +0200 <geekosaur> hm. has anyone actually looked at the Spiral layout to see if it's doing something really stupid?
2021-10-17 19:55:15 +0200 <geekosaur> since iirc that was the one cited as being slow with 20 windows
2021-10-17 19:55:59 +0200 <geekosaur> (personally I consider Spiral a useless demo layout)
2021-10-17 19:57:24 +0200 <geekosaur> also perhaps this should reuse Direction2D rather than define its own
2021-10-17 19:57:46 +0200 <liskin> Solid: hm, but nub comes from base, it's not being interpreted, is it?
2021-10-17 19:58:06 +0200 <geekosaur> mm, maybe not, UDLR is different from NSEW
2021-10-17 19:58:27 +0200 <liskin> that being said, compiled with -O2 and :: Int, nub [1..1000] takes 2.3 ms, which is not an order of magnitude faster, but it's more than twice as fast
2021-10-17 19:58:29 +0200 <liskin> strange
2021-10-17 19:58:48 +0200 <geekosaur> I expect t's fusing
2021-10-17 19:59:17 +0200 <geekosaur> nub (enumFromTo 1 1000)
2021-10-17 19:59:55 +0200 <liskin> yeah, that might be it, without -O2 it's very close to the number I get in ghci
2021-10-17 20:00:42 +0200 <Solid> well the first thing I can see in spiral is that it uses a fibonacci implementation that has a space leak :)
2021-10-17 20:00:54 +0200 <Solid> but again the number are so small that it this will never matter
2021-10-17 20:10:16 +0200catman(~catman@user/catman)
2021-10-17 20:32:48 +0200electr0n(~electr0n@about/security/founder/electr0n) (Quit: WeeChat 3.3)
2021-10-17 20:33:10 +0200benin(~benin@183.82.25.86) (Ping timeout: 252 seconds)
2021-10-17 20:45:09 +0200catman(~catman@user/catman) (Quit: WeeChat 3.4-dev)
2021-10-17 20:55:26 +0200catman(~catman@user/catman)
2021-10-17 21:14:16 +0200catman(~catman@user/catman) (Quit: WeeChat 3.4-dev)
2021-10-17 21:27:15 +0200catman(~catman@user/catman)
2021-10-17 21:46:17 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2021-10-17 21:59:31 +0200catman(~catman@user/catman) (Ping timeout: 252 seconds)
2021-10-17 22:00:20 +0200catman(~catman@user/catman)
2021-10-17 22:06:55 +0200 <jakefromstatefar> <geekosaur> "since iirc that was the one..." <- No, it was accordion that was slow
2021-10-17 22:11:12 +0200 <jakefromstatefar> I think (important preface) that it's the quick resizing of so many windows (in conjunction with modern picom's stupidity)
2021-10-17 22:13:14 +0200 <jakefromstatefar> ---
2021-10-17 22:13:14 +0200 <jakefromstatefar> Is there a way to completely remove specified windows, that are otherwise `ignored`?
2021-10-17 22:19:14 +0200mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2021-10-17 22:39:55 +0200wonko(~wjc@62.115.229.50) (Ping timeout: 268 seconds)
2021-10-17 23:31:35 +0200 <geekosaur> I don't understand the question. xmonad should unmap any window that's not visible, and xmonad core knows nothing whatsoever about markBoring.
2021-10-17 23:32:11 +0200 <geekosaur> if you mean doIgnore-d, xmonad neither maps nor unmaps thoise, nor does anything else with them; it's up to their owning app to manage them
2021-10-17 23:33:08 +0200 <geekosaur> hm, actually with my compton settings I bet 20 (mapped) windows would be slow as well
2021-10-17 23:33:24 +0200 <geekosaur> mostly because of fading
2021-10-17 23:43:25 +0200cjb(~cjb@user/cjb)
2021-10-17 23:46:35 +0200 <jakefromstatefar> It's unrelated to the prior discussion.
2021-10-17 23:47:05 +0200 <jakefromstatefar> I'm just wondering if there's a way to override ignored windows, so that under certain criteria, they're never displayed at all.
2021-10-17 23:48:50 +0200 <liskin> jakefromstatefar: https://xmonad.github.io/xmonad-docs/xmonad-contrib-0.16.999/XMonad-Hooks-ManageHelpers.html#v:doH…
2021-10-17 23:57:34 +0200 <geekosaur> "under certain criteria" seems like a problem, since there'd be no way to get them back without the app's active involvement
2021-10-17 23:59:40 +0200 <liskin> xdotool windowmap might help?