Logs: liberachat/#xmonad
| 2023-04-17 16:06:47 | <geekosaur> | the only thing that makes a window manager special is that it selects SubstructureRedirectMask on the root window and all children. it's a bit hacky |
| 2023-04-17 16:07:17 | <JonathanWatson[m> | ok |
| 2023-04-17 16:07:53 | <JonathanWatson[m> | now i assume when i use xdotool to send keys they get sent to the x server and then the x server sends them to the x clients like xmonad to be consumed |
| 2023-04-17 16:08:57 | <geekosaur> | correct, with one small modification: xmonad uses passive key grabs, so when the server receives one of the grabbed keys it gives xmonad a full keyboard drab and sends all key events including the triggering event to it |
| 2023-04-17 16:09:25 | <geekosaur> | which is why you don't have to worry about focused windows |
| 2023-04-17 16:09:28 | <JonathanWatson[m> | oh ok |
| 2023-04-17 16:10:15 | <JonathanWatson[m> | my worry is that if i just run xdotool many times then the time taken for the benchmark to finish is the amount of time it takes xdotool to send that |
| 2023-04-17 16:10:25 | <JonathanWatson[m> | because it has a bit of a delay |
| 2023-04-17 16:10:37 | <geekosaur> | if all you're doing is timing xdotool, then yes that is exactly what will happen |
| 2023-04-17 16:11:12 | <JonathanWatson[m> | but if i could just send all of the keypresses to the x server at once and have them queued, then the limiting factor would just be the amount of time it takes for the x server to send the commands to xmonad and xmonad to execute them |
| 2023-04-17 16:11:43 | <JonathanWatson[m> | although the x server sending the commands might still be a limiting factor but i feel like less so? |
| 2023-04-17 16:11:46 | <geekosaur> | right, but detecting that is a problem |
| 2023-04-17 16:12:28 | <geekosaur> | they'll just sit in the AF_UNIX socket connecting xmonad to the X server until consumed by XNextEvent |
| 2023-04-17 16:12:33 | <JonathanWatson[m> | as in detecting that the commands have been executed? |
| 2023-04-17 16:12:37 | <geekosaur> | yes |
| 2023-04-17 16:13:37 | × | sadmax quits (~user@64.130.91.66) (Remote host closed the connection) |
| 2023-04-17 16:13:43 | <geekosaur> | we don't have a hook that is executed just before the core does XNextEvent |
| 2023-04-17 16:13:56 | <JonathanWatson[m> | well i hope that once i stop queuing them, the display will keep flashing until all of the commands have been handled (at least no delays for more than five seconds) |
| 2023-04-17 16:14:11 | <geekosaur> | but if the key you send switches workspaces you could use an xmonad.hs which logs the time in its logHook or something |
| 2023-04-17 16:14:59 | <geekosaur> | note that it won't work well to time something that does a spawn because xmonad does a fork() to spawn the command and you won't get any timing after that |
| 2023-04-17 16:15:14 | <geekosaur> | (double fork(), in fact) |
| 2023-04-17 16:15:53 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-04-17 16:16:33 | <JonathanWatson[m> | well i was hoping not to time individual commands |
| 2023-04-17 16:16:46 | <JonathanWatson[m> | but just time how long it takes to do all of them |
| 2023-04-17 16:16:57 | <JonathanWatson[m> | and then compare that with the time for a potentially slower version of xmonad |
| 2023-04-17 16:38:45 | × | berberman_ quits (~berberman@user/berberman) (Ping timeout: 256 seconds) |
| 2023-04-17 16:47:22 | <JonathanWatson[m> | also i have found an easy way to queue the commands now |
| 2023-04-17 16:47:50 | <JonathanWatson[m> | just send SIGSTOP, send all the commands to the x server with xdotool, then send SIGCONT |
| 2023-04-17 17:52:32 | → | amenonsen joins (~amenonsen@pitta.toroid.org) |
| 2023-04-17 18:04:11 | → | berberman joins (~berberman@user/berberman) |
| 2023-04-17 18:45:45 | × | kaskal quits (~kaskal@213-147-166-209.nat.highway.webapn.at) (Ping timeout: 240 seconds) |
| 2023-04-17 18:51:58 | → | catman joins (~catman@user/catman) |
| 2023-04-17 19:16:32 | → | kaskal joins (~kaskal@2001:4bb8:2cc:efb3:2d42:311d:d744:4a5) |
| 2023-04-17 20:41:07 | × | catman quits (~catman@user/catman) (Ping timeout: 276 seconds) |
| 2023-04-17 21:46:49 | → | stellacy joins (~stellacy@gateway/tor-sasl/stellacy) |
| 2023-04-17 22:07:32 | × | stellacy quits (~stellacy@gateway/tor-sasl/stellacy) (Remote host closed the connection) |
| 2023-04-17 22:08:04 | → | stellacy joins (~stellacy@gateway/tor-sasl/stellacy) |
| 2023-04-17 22:13:07 | <JonathanWatson[m> | i'm back again |
| 2023-04-17 22:13:40 | <JonathanWatson[m> | does anyone know how i can listen to expose events? i wrote this script to run separately but its not printing anything |
| 2023-04-17 22:13:43 | <JonathanWatson[m> | allocaXEvent $ \xEventPointer ->... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/ed27ba729d93dc9fe65f6fdea40e9c6388fa4b41>) |
| 2023-04-17 22:13:59 | JonathanWatson[m | sent a haskell code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/ed27ba729d93dc9fe65f6fdea40e9c6388fa4b41 |
| 2023-04-17 22:14:55 | <JonathanWatson[m> | perhaps i need to use the checkTypedWindowEvent function |
| 2023-04-17 22:17:59 | <geekosaur> | https://hackage.haskell.org/package/X11-1.10.3/docs/Graphics-X11-Xlib-Event.html#v:selectInput |
| 2023-04-17 22:18:10 | <geekosaur> | you won't get events unless you select for them |
| 2023-04-17 22:18:35 | <geekosaur> | https://tronche.com/gui/x/xlib/event-handling/XSelectInput.html |
| 2023-04-17 22:19:27 | <geekosaur> | also that program is going to loop forever on the first event it receives because peekEvent leaves it queued |
| 2023-04-17 22:21:36 | <geekosaur> | also also, `threadDelay 10000` delays for 10ms |
| 2023-04-17 22:31:21 | <JonathanWatson[m> | <geekosaur> "also also, `threadDelay 10000..." <- Fine by me |
| 2023-04-17 22:32:47 | <JonathanWatson[m> | <geekosaur> "also that program is going to..." <- I thought that the normal method would consume the events and stop them happening but fortunately not |
| 2023-04-17 22:33:03 | <geekosaur> | you want nextEvent, not peekEvent |
| 2023-04-17 22:33:43 | <JonathanWatson[m> | Yes |
| 2023-04-17 22:34:21 | <JonathanWatson[m> | unfortunate time for element to start randomly crashing in xmonad |
| 2023-04-17 22:34:45 | <geekosaur> | huh. I ran it for a while without problems |
| 2023-04-17 22:35:15 | <JonathanWatson[m> | seems to be working now |
| 2023-04-17 22:35:18 | <geekosaur> | although I guess I was running the webapp instead of the standalone one (I have more than enough JS engines running as it is) |
| 2023-04-17 22:35:41 | <JonathanWatson[m> | is there an easy way to get all the windows with the X11 library? |
| 2023-04-17 22:36:11 | <geekosaur> | queryTree aka XQueryTree() |
| 2023-04-17 22:37:05 | × | mncheckm quits (~mncheck@193.224.205.254) (Ping timeout: 240 seconds) |
| 2023-04-17 22:37:16 | <JonathanWatson[m> | interesting |
| 2023-04-17 22:37:25 | <geekosaur> | but if this is for XSelectInput you want to omit the do_not_propagate flag and select on the root window |
| 2023-04-17 22:37:57 | <geekosaur> | hm, actually I think that might not work here and you would have to queryTree |
| 2023-04-17 22:37:59 | <JonathanWatson[m> | ah nice |
| 2023-04-17 22:38:05 | <JonathanWatson[m> | oh ok |
| 2023-04-17 22:38:39 | <JonathanWatson[m> | i'll need to use rootWindow to get the window argument for selectInput anyway |
| 2023-04-17 22:38:46 | <JonathanWatson[m> | or even defaultRootWindow |
| 2023-04-17 22:40:20 | <JonathanWatson[m> | do i need to use queryTree recursively? |
| 2023-04-17 22:40:44 | <JonathanWatson[m> | i suppose i only really need to check the xmonad window for expose events |
| 2023-04-17 22:41:09 | <geekosaur> | you shouldn't need to because it's no longer common for programs to create inner server-side windows; that is slow and inflexible |
| 2023-04-17 22:41:21 | <geekosaur> | and xmonad doesn't have a window |
| 2023-04-17 22:42:10 | <JonathanWatson[m> | oh ok |
| 2023-04-17 22:42:52 | <JonathanWatson[m> | is exposureMask the mask to use? |
| 2023-04-17 22:44:13 | <JonathanWatson[m> | looks like it works |
| 2023-04-17 22:44:24 | <geekosaur> | exposureMask and structureNotifyMask (so you can select an input mask on new windows as they appear) |
| 2023-04-17 22:45:24 | <JonathanWatson[m> | should i just bitwise OR them together? |
| 2023-04-17 22:45:30 | <geekosaur> | yes |
| 2023-04-17 22:46:33 | <JonathanWatson[m> | ok this is my code now... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/4e68c95a37b2a875e79b1288f05d911ea49a33a6>) |
| 2023-04-17 22:48:12 | <geekosaur> | don't forget to also set the input mask on the root window |
| 2023-04-17 22:48:39 | <geekosaur> | so you get notifications for new windows |
| 2023-04-17 22:49:55 | <JonathanWatson[m> | ok |
| 2023-04-17 22:51:09 | <geekosaur> | correction: substructureNotifyMask on the root |
| 2023-04-17 22:51:20 | <geekosaur> | (Notify, not Redirect!) |
| 2023-04-17 22:55:17 | <JonathanWatson[m> | plus state monad for actually telling when an expose event is new... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/c5473cdb559f501974d4e9ad3745a0a47497bf8b>) |
| 2023-04-17 22:59:36 | <geekosaur> | that's slightly wrong. you want substructureNotifyMask on the root, but structureNotifyMask on the child windows. you also want to watch for MapWindow events that you receive and select exposureMask .|. structureNotifyMask on them |
| 2023-04-17 23:00:03 | <geekosaur> | (you don't need to know about window deletion, the corresponding event mask will go away by itself) |
| 2023-04-17 23:00:47 | <geekosaur> | come to think of it I don't think you need structureNotifyMask on the children at all, since you don't care about resizes and such |
| 2023-04-17 23:01:15 | <geekosaur> | just the substructureNotifyMask on the root so you can select expose events on new windows as they appear |
| 2023-04-17 23:02:42 | <geekosaur> | mm, and … I am suddenly thinking Expose isn't sent on random draws, and is likely to be useless in a tiled wm unless a floating window is closed |
| 2023-04-17 23:03:35 | <geekosaur> | you may only care about MapRequest and UnmapRequest because no event is sent at all when something draws in a window, unless that part of the window is hidden and then it gets a NoExpose event |
| 2023-04-17 23:03:59 | <geekosaur> | and wm events are not going to be draws anyway |
| 2023-04-17 23:04:47 | <geekosaur> | so, hm. https://tronche.com/gui/x/xlib/events/processing-overview.html#StructureNotifyMask is probably what you care about as the only things xmonad will affect about windows |
| 2023-04-17 23:06:10 | <JonathanWatson[m> | so do i only need to select substructureNotifyMask on the root? |
| 2023-04-17 23:06:15 | <geekosaur> | yes |
| 2023-04-17 23:06:24 | <geekosaur> | structureNotifyMask on everything else |
| 2023-04-17 23:07:09 | <geekosaur> | expose events will be received for those layouts that cover up windows instead of unmapping them (example of the former is simpleTabbed, example of the latter is Full) |
| 2023-04-17 23:07:25 | <JonathanWatson[m> | oh ok so i keep expose for checkTypedEvent |
| 2023-04-17 23:07:44 | <geekosaur> | right but you also want to checktypedEvent for mapNotify |
| 2023-04-17 23:08:01 | <geekosaur> | and selectInput on the window in question |
| 2023-04-17 23:10:52 | <geekosaur> | if you want something that's sanely measurable, you probably want to load a couple of workspaces with windows (say, xterms) and switch between them |
| 2023-04-17 23:11:40 | <geekosaur> | this will be the slowest because it causes a full run of X.O.windows on the newly revealed workspace, and that will do a full run of the layout |
| 2023-04-17 23:11:55 | <JonathanWatson[m> | i can't see how to get the window for mapNotify |
All times are in UTC.