Logs: liberachat/#xmonad
| 2021-10-17 11:22:36 | liskin | has just finished writing the first draft of XMonad.Util.EWMH module \o/ |
| 2021-10-17 11:27:22 | × | humky quits (~humky@user/humky) (Quit: Leaving) |
| 2021-10-17 11:29:07 | → | humky joins (~humky@user/humky) |
| 2021-10-17 11:30:10 | <Solid> | /o/ \o/ \o\ |
| 2021-10-17 11:31:31 | <geekosaur> | w00t |
| 2021-10-17 12:02:39 | → | mestre joins (~mestre@191.177.175.57) |
| 2021-10-17 12:10:11 | <FOSSHuman[m]> | > * <@liskin:libera.chat> has just finished writing the first draft of XMonad.Util.EWMH module \o/ |
| 2021-10-17 12:10:11 | <FOSSHuman[m]> | :)) |
| 2021-10-17 12:10:14 | <lambdabot> | <hint>:1:1: error: parse error on input ‘*’ |
| 2021-10-17 12:17:07 | <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 12:17:14 | <FOSSHuman[m]> | * out today in the manageHook of my config and it |
| 2021-10-17 12:33:26 | <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 12:34:26 | → | wz1000 joins (~zubin@static.11.113.47.78.clients.your-server.de) |
| 2021-10-17 12:40:05 | <FOSSHuman[m]> | * className matching and Util.Hacks trayAbovePanelEventHook to my |
| 2021-10-17 12:46:03 | <liskin> | FOSSHuman[m]: good |
| 2021-10-17 13:31:27 | → | alternateved joins (~user@194.177.28.171) |
| 2021-10-17 14:33:46 | <mc47> | liskin, awesome! |
| 2021-10-17 14:39:13 | → | jonahgs joins (~jonahgs@c-73-9-97-169.hsd1.il.comcast.net) |
| 2021-10-17 14:49:51 | × | jonahgs quits (~jonahgs@c-73-9-97-169.hsd1.il.comcast.net) (Quit: Leaving) |
| 2021-10-17 14:51:17 | <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 14:52:17 | <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 14:52:47 | <geekosaur> | it pretty much tells you; you're supposed to liust any EWMH atoms you support (and their parents, as shown) |
| 2021-10-17 14:54:29 | <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 14:55:43 | <geekosaur> | it means both, but note "The Window Manager is free to honor or reject this request" |
| 2021-10-17 14:56:32 | <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 14:56:33 | <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 14:57:57 | <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 14:59:07 | <liskin> | okay, thx :-) |
| 2021-10-17 14:59:28 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-10-17 14:59:53 | <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 15:01:10 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2021-10-17 15:01:17 | <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 15:01:38 | <geekosaur> | EWMH is a cruddy hacked-up mess |
| 2021-10-17 15:02:58 | <liskin> | well a decent WM surely has its own integrated taskbar! |
| 2021-10-17 15:04:22 | <liskin> | and in our case, _NET_WM_STATE_SKIP_TASKBAR should actually be interpreted by X.H.StatusBar.PP :-) |
| 2021-10-17 15:05:05 | <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 15:05:23 | <liskin> | anyway, back to coding :-) |
| 2021-10-17 15:07:16 | <geekosaur> | I'm also thinking of my X.U.NoTaskbar which should really check first :) |
| 2021-10-17 15:09:57 | <geekosaur> | oh, and PP cares about _SKIP_PAGER not _SKIP_TASKBAR :) |
| 2021-10-17 15:11:06 | <liskin> | uh, does it? I'm grepping for SKIP and only finding X.U.NoTaskbar |
| 2021-10-17 15:11:27 | <liskin> | oh, you probably meant "should care, if anything" |
| 2021-10-17 15:12:14 | <liskin> | (anyway, my mockery about decent WMs having all that integrated still applies :-)) |
| 2021-10-17 15:12:31 | <geekosaur> | yeh |
| 2021-10-17 15:13:13 | <geekosaur> | suppose they don't consider marco a decent WM since it offloads that to applets in mate-panel… |
| 2021-10-17 15:24:08 | → | benin5 joins (~benin@183.82.25.86) |
| 2021-10-17 15:27:41 | × | benin quits (~benin@183.82.25.86) (Ping timeout: 264 seconds) |
| 2021-10-17 15:27:41 | benin5 | is now known as benin |
| 2021-10-17 15:37:14 | <liskin> | jakefromstatefar: https://github.com/xmonad/xmonad-contrib/blob/fa3536b40bc121b6cc724ee393b14b7db44db890/XMonad/Hooks/EwmhDesktops.hs#L186-L191 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 15:37:53 | HelloNewman | is now known as Hash |
| 2021-10-17 15:39:48 | <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 15:41:20 | <geekosaur> | people always look at the big-O and forget the constant factors actually matter |
| 2021-10-17 16:13:04 | <liskin> | oh well, time for stack build criterion I guess :-) |
| 2021-10-17 16:13:37 | <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 16:14:22 | <geekosaur> | if someone has 10000 windows, they have bigger problems than how xmonad will deal with them :) |
| 2021-10-17 16:18:55 | <liskin> | okay, silly me, nub [1..100] takes 70 μs; nub [1..1000] takes 7 ms |
| 2021-10-17 16:19:22 | <liskin> | none of that is in the realm of being perceptible by contemporary humans with contemporary personal computers |
| 2021-10-17 16:20:02 | <geekosaur> | even over a second is dubious; consider how long it'd take a human to mod-shift-C 10000 windows |
| 2021-10-17 16:20:21 | <geekosaur> | 20 seconds, we have a problem. 1s, not sure we do |
| 2021-10-17 16:20:48 | <liskin> | well I didn't mean anyone might actually have 10k windows |
| 2021-10-17 16:21:11 | <liskin> | it's just the first number for which length (nub [1..n]) took noticeable time in ghci :-) |
| 2021-10-17 16:21:20 | <liskin> | (first power of 10, to be precise) |
| 2021-10-17 16:22:03 | liskin | is so silly he really did decide to benchmark stuff by looking at how long it feels to eval in ghci |
| 2021-10-17 17:51:35 | <Solid> | :D |
| 2021-10-17 17:53:43 | <Solid> | I doubt it takes anywhere near as long compiled |
| 2021-10-17 17:54:01 | <Solid> | (ghci really is quite slow) |
| 2021-10-17 17:54:53 | <geekosaur> | hm. has anyone actually looked at the Spiral layout to see if it's doing something really stupid? |
| 2021-10-17 17:55:15 | <geekosaur> | since iirc that was the one cited as being slow with 20 windows |
| 2021-10-17 17:55:59 | <geekosaur> | (personally I consider Spiral a useless demo layout) |
| 2021-10-17 17:57:24 | <geekosaur> | also perhaps this should reuse Direction2D rather than define its own |
| 2021-10-17 17:57:46 | <liskin> | Solid: hm, but nub comes from base, it's not being interpreted, is it? |
| 2021-10-17 17:58:06 | <geekosaur> | mm, maybe not, UDLR is different from NSEW |
| 2021-10-17 17:58:27 | <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 17:58:29 | <liskin> | strange |
| 2021-10-17 17:58:48 | <geekosaur> | I expect t's fusing |
| 2021-10-17 17:59:17 | <geekosaur> | nub (enumFromTo 1 1000) |
| 2021-10-17 17:59:55 | <liskin> | yeah, that might be it, without -O2 it's very close to the number I get in ghci |
| 2021-10-17 18:00:42 | <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 18:00:54 | <Solid> | but again the number are so small that it this will never matter |
| 2021-10-17 18:10:16 | → | catman joins (~catman@user/catman) |
| 2021-10-17 18:32:48 | × | electr0n quits (~electr0n@about/security/founder/electr0n) (Quit: WeeChat 3.3) |
| 2021-10-17 18:33:10 | × | benin quits (~benin@183.82.25.86) (Ping timeout: 252 seconds) |
| 2021-10-17 18:45:09 | × | catman quits (~catman@user/catman) (Quit: WeeChat 3.4-dev) |
| 2021-10-17 18:55:26 | → | catman joins (~catman@user/catman) |
| 2021-10-17 19:14:16 | × | catman quits (~catman@user/catman) (Quit: WeeChat 3.4-dev) |
| 2021-10-17 19:27:15 | → | catman joins (~catman@user/catman) |
| 2021-10-17 19:46:17 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2021-10-17 19:59:31 | × | catman quits (~catman@user/catman) (Ping timeout: 252 seconds) |
| 2021-10-17 20:00:20 | → | catman joins (~catman@user/catman) |
| 2021-10-17 20:06:55 | <jakefromstatefar> | <geekosaur> "since iirc that was the one..." <- No, it was accordion that was slow |
| 2021-10-17 20:11:12 | <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 20:13:14 | <jakefromstatefar> | --- |
| 2021-10-17 20:13:14 | <jakefromstatefar> | Is there a way to completely remove specified windows, that are otherwise `ignored`? |
| 2021-10-17 20:19:14 | × | mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2021-10-17 20:39:55 | × | wonko quits (~wjc@62.115.229.50) (Ping timeout: 268 seconds) |
| 2021-10-17 21:31:35 | <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 21:32:11 | <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 21:33:08 | <geekosaur> | hm, actually with my compton settings I bet 20 (mapped) windows would be slow as well |
| 2021-10-17 21:33:24 | <geekosaur> | mostly because of fading |
| 2021-10-17 21:43:25 | → | cjb joins (~cjb@user/cjb) |
| 2021-10-17 21:46:35 | <jakefromstatefar> | It's unrelated to the prior discussion. |
All times are in UTC.