| 2023-04-17 00:41:39 +0000 | ft | (~ft@87.122.10.136) (Ping timeout: 260 seconds) |
| 2023-04-17 00:43:04 +0000 | ft | (~ft@i59F54987.versanet.de) |
| 2023-04-17 02:09:04 +0000 | td_ | (~td@i53870922.versanet.de) (Ping timeout: 248 seconds) |
| 2023-04-17 02:10:47 +0000 | td_ | (~td@i53870920.versanet.de) |
| 2023-04-17 02:46:29 +0000 | catman | (~catman@user/catman) |
| 2023-04-17 05:00:25 +0000 | catman | (~catman@user/catman) (Ping timeout: 240 seconds) |
| 2023-04-17 05:52:19 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 250 seconds) |
| 2023-04-17 05:54:20 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-04-17 05:58:37 +0000 | catman | (~catman@user/catman) |
| 2023-04-17 06:31:07 +0000 | catman | (~catman@user/catman) (Quit: WeeChat 3.8) |
| 2023-04-17 06:45:37 +0000 | mncheckm | (~mncheck@193.224.205.254) |
| 2023-04-17 07:14:52 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2023-04-17 07:16:53 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-04-17 07:35:27 +0000 | cfricke | (~cfricke@user/cfricke) |
| 2023-04-17 07:47:40 +0000 | thyriaen | (~thyriaen@2a01:aea0:dd4:555f:6245:cbff:fe9f:48b1) |
| 2023-04-17 09:00:06 +0000 | murchadha[m] | (~murdchadh@2001:470:69fc:105::3:3103) (Quit: You have been kicked for being idle) |
| 2023-04-17 09:00:07 +0000 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle) |
| 2023-04-17 09:00:07 +0000 | unclechu | (~unclechu@2001:470:69fc:105::354) (Quit: You have been kicked for being idle) |
| 2023-04-17 09:30:36 +0000 | noze | (~user@2001:41d0:a:21f1::1) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 2023-04-17 09:31:08 +0000 | noze | (~user@2001:41d0:a:21f1::1) |
| 2023-04-17 10:00:50 +0000 | hightower3 | (~hightower@213.149.61.95) |
| 2023-04-17 10:03:01 +0000 | hightower2 | (~hightower@213.149.61.117) (Ping timeout: 240 seconds) |
| 2023-04-17 10:17:23 +0000 | noze | (~user@2001:41d0:a:21f1::1) (Ping timeout: 256 seconds) |
| 2023-04-17 10:22:23 +0000 | noze | (~user@2001:41d0:a:21f1::1) |
| 2023-04-17 10:28:53 +0000 | thyriaen | (~thyriaen@2a01:aea0:dd4:555f:6245:cbff:fe9f:48b1) (Quit: Leaving) |
| 2023-04-17 12:04:48 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 248 seconds) |
| 2023-04-17 14:52:59 +0000 | amenonsen | (~amenonsen@pitta.toroid.org) (Ping timeout: 264 seconds) |
| 2023-04-17 15:01:45 +0000 | sadmax | (~user@64.130.91.66) |
| 2023-04-17 15:11:22 +0000 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.8) |
| 2023-04-17 15:15:30 +0000 | abhixec | (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds) |
| 2023-04-17 15:49:03 +0000 | <JonathanWatson[m> | does anyone know how i can benchmark xmonad? i would like to give xmonad many keypresses via xdotool and see how long it takes xmonad to execute them all, but i don't know how to find out when this is |
| 2023-04-17 15:50:18 +0000 | <JonathanWatson[m> | i changed the NextLayout event to take five seconds and xdotool finishes immediately rather than wait for the five seconds |
| 2023-04-17 15:50:51 +0000 | <geekosaur> | xdotool doesn't know how to wait for results of key actions; it just sends the event and exits |
| 2023-04-17 15:51:04 +0000 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) |
| 2023-04-17 15:51:19 +0000 | unclechu | (~unclechu@2001:470:69fc:105::354) |
| 2023-04-17 15:51:23 +0000 | <geekosaur> | (it doesn't even know what the result would be and therefore what to wait for) |
| 2023-04-17 15:53:25 +0000 | <JonathanWatson[m> | is there anything that could work without modifying xmonad itself? |
| 2023-04-17 15:53:41 +0000 | <geekosaur> | nope |
| 2023-04-17 15:53:42 +0000 | <JonathanWatson[m> | since any change i make probably needs to also be made to 96 other versions of xmonad |
| 2023-04-17 15:55:05 +0000 | <geekosaur> | and you would also need to modify xdotool, since as I said it has no idea of what to wait for. worse, xmonad can't even tell that xdotool sent the event and that it should send some response back; the event will have the `send_event` flag set, but no indication of what sent it |
| 2023-04-17 15:55:14 +0000 | <mc47[m]> | You can probably create a function that takes a label and `X a` and prints the label with how much it took to execute the action to a file or to stderr |
| 2023-04-17 15:55:52 +0000 | <mc47[m]> | Oh and Haskell laziness should be considered as well |
| 2023-04-17 15:56:10 +0000 | <geekosaur> | very little in xmonad is lazy since everything does IO actions… |
| 2023-04-17 15:56:49 +0000 | <mc47[m]> | But you'd need to wrape every action |
| 2023-04-17 15:57:57 +0000 | <JonathanWatson[m> | i think the easiest method for my purposes it to send like 1000 keypresses and then wait for the screen to stop changing for five seconds |
| 2023-04-17 15:58:01 +0000 | <JonathanWatson[m> | and then subtract five |
| 2023-04-17 15:59:14 +0000 | <JonathanWatson[m> | but then i need to make sure that i am sending the keypresses faster than xmonad is handling them and i need to check that that many keypresses can be queued |
| 2023-04-17 15:59:33 +0000 | <JonathanWatson[m> | and i also need to figure out how to actually check that the screen hasn't changed for five seconds |
| 2023-04-17 16:00:03 +0000 | <geekosaur> | that's actually the easiest part: select expose events on the root window and all children |
| 2023-04-17 16:01:26 +0000 | <JonathanWatson[m> | can i do that from outside of xmonad? |
| 2023-04-17 16:01:42 +0000 | <geekosaur> | yes |
| 2023-04-17 16:01:51 +0000 | <geekosaur> | (and must, in fact) |
| 2023-04-17 16:03:42 +0000 | <JonathanWatson[m> | is xmonad an X client? |
| 2023-04-17 16:05:50 +0000 | <geekosaur> | yes |
| 2023-04-17 16:06:04 +0000 | <JonathanWatson[m> | i'm haven't been sure exactly where it comes into the x window manager pipeline since it doesn't seem to be the server but isn't a normal program |
| 2023-04-17 16:06:47 +0000 | <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 +0000 | <JonathanWatson[m> | ok |
| 2023-04-17 16:07:53 +0000 | <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 +0000 | <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 +0000 | <geekosaur> | which is why you don't have to worry about focused windows |
| 2023-04-17 16:09:28 +0000 | <JonathanWatson[m> | oh ok |
| 2023-04-17 16:10:15 +0000 | <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 +0000 | <JonathanWatson[m> | because it has a bit of a delay |
| 2023-04-17 16:10:37 +0000 | <geekosaur> | if all you're doing is timing xdotool, then yes that is exactly what will happen |
| 2023-04-17 16:11:12 +0000 | <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 +0000 | <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 +0000 | <geekosaur> | right, but detecting that is a problem |
| 2023-04-17 16:12:28 +0000 | <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 +0000 | <JonathanWatson[m> | as in detecting that the commands have been executed? |
| 2023-04-17 16:12:37 +0000 | <geekosaur> | yes |
| 2023-04-17 16:13:37 +0000 | sadmax | (~user@64.130.91.66) (Remote host closed the connection) |
| 2023-04-17 16:13:43 +0000 | <geekosaur> | we don't have a hook that is executed just before the core does XNextEvent |
| 2023-04-17 16:13:56 +0000 | <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 +0000 | <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 +0000 | <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 +0000 | <geekosaur> | (double fork(), in fact) |
| 2023-04-17 16:15:53 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-04-17 16:16:33 +0000 | <JonathanWatson[m> | well i was hoping not to time individual commands |
| 2023-04-17 16:16:46 +0000 | <JonathanWatson[m> | but just time how long it takes to do all of them |
| 2023-04-17 16:16:57 +0000 | <JonathanWatson[m> | and then compare that with the time for a potentially slower version of xmonad |
| 2023-04-17 16:38:45 +0000 | berberman_ | (~berberman@user/berberman) (Ping timeout: 256 seconds) |
| 2023-04-17 16:47:22 +0000 | <JonathanWatson[m> | also i have found an easy way to queue the commands now |
| 2023-04-17 16:47:50 +0000 | <JonathanWatson[m> | just send SIGSTOP, send all the commands to the x server with xdotool, then send SIGCONT |
| 2023-04-17 17:52:32 +0000 | amenonsen | (~amenonsen@pitta.toroid.org) |
| 2023-04-17 18:04:11 +0000 | berberman | (~berberman@user/berberman) |
| 2023-04-17 18:45:45 +0000 | kaskal | (~kaskal@213-147-166-209.nat.highway.webapn.at) (Ping timeout: 240 seconds) |
| 2023-04-17 18:51:58 +0000 | catman | (~catman@user/catman) |
| 2023-04-17 19:16:32 +0000 | kaskal | (~kaskal@2001:4bb8:2cc:efb3:2d42:311d:d744:4a5) |
| 2023-04-17 20:41:07 +0000 | catman | (~catman@user/catman) (Ping timeout: 276 seconds) |
| 2023-04-17 21:46:49 +0000 | stellacy | (~stellacy@gateway/tor-sasl/stellacy) |
| 2023-04-17 22:07:32 +0000 | stellacy | (~stellacy@gateway/tor-sasl/stellacy) (Remote host closed the connection) |
| 2023-04-17 22:08:04 +0000 | stellacy | (~stellacy@gateway/tor-sasl/stellacy) |
| 2023-04-17 22:13:07 +0000 | <JonathanWatson[m> | i'm back again |
| 2023-04-17 22:13:40 +0000 | <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 +0000 | <JonathanWatson[m> | allocaXEvent $ \xEventPointer ->... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/ed27ba729d93dc9fe65f6fdea40e9c6388fa…>) |
| 2023-04-17 22:13:59 +0000 | JonathanWatson[m | sent a haskell code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/ed27ba729d93dc9fe65f6fdea40e9c6388fa… |
| 2023-04-17 22:14:55 +0000 | <JonathanWatson[m> | perhaps i need to use the checkTypedWindowEvent function |
| 2023-04-17 22:17:59 +0000 | <geekosaur> | https://hackage.haskell.org/package/X11-1.10.3/docs/Graphics-X11-Xlib-Event.html#v:selectInput |
| 2023-04-17 22:18:10 +0000 | <geekosaur> | you won't get events unless you select for them |
| 2023-04-17 22:18:35 +0000 | <geekosaur> | https://tronche.com/gui/x/xlib/event-handling/XSelectInput.html |
| 2023-04-17 22:19:27 +0000 | <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 +0000 | <geekosaur> | also also, `threadDelay 10000` delays for 10ms |
| 2023-04-17 22:31:21 +0000 | <JonathanWatson[m> | <geekosaur> "also also, `threadDelay 10000..." <- Fine by me |
| 2023-04-17 22:32:47 +0000 | <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 +0000 | <geekosaur> | you want nextEvent, not peekEvent |
| 2023-04-17 22:33:43 +0000 | <JonathanWatson[m> | Yes |
| 2023-04-17 22:34:21 +0000 | <JonathanWatson[m> | unfortunate time for element to start randomly crashing in xmonad |
| 2023-04-17 22:34:45 +0000 | <geekosaur> | huh. I ran it for a while without problems |
| 2023-04-17 22:35:15 +0000 | <JonathanWatson[m> | seems to be working now |
| 2023-04-17 22:35:18 +0000 | <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 +0000 | <JonathanWatson[m> | is there an easy way to get all the windows with the X11 library? |
| 2023-04-17 22:36:11 +0000 | <geekosaur> | queryTree aka XQueryTree() |
| 2023-04-17 22:37:05 +0000 | mncheckm | (~mncheck@193.224.205.254) (Ping timeout: 240 seconds) |
| 2023-04-17 22:37:16 +0000 | <JonathanWatson[m> | interesting |
| 2023-04-17 22:37:25 +0000 | <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 +0000 | <geekosaur> | hm, actually I think that might not work here and you would have to queryTree |
| 2023-04-17 22:37:59 +0000 | <JonathanWatson[m> | ah nice |
| 2023-04-17 22:38:05 +0000 | <JonathanWatson[m> | oh ok |
| 2023-04-17 22:38:39 +0000 | <JonathanWatson[m> | i'll need to use rootWindow to get the window argument for selectInput anyway |
| 2023-04-17 22:38:46 +0000 | <JonathanWatson[m> | or even defaultRootWindow |
| 2023-04-17 22:40:20 +0000 | <JonathanWatson[m> | do i need to use queryTree recursively? |
| 2023-04-17 22:40:44 +0000 | <JonathanWatson[m> | i suppose i only really need to check the xmonad window for expose events |
| 2023-04-17 22:41:09 +0000 | <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 +0000 | <geekosaur> | and xmonad doesn't have a window |
| 2023-04-17 22:42:10 +0000 | <JonathanWatson[m> | oh ok |
| 2023-04-17 22:42:52 +0000 | <JonathanWatson[m> | is exposureMask the mask to use? |
| 2023-04-17 22:44:13 +0000 | <JonathanWatson[m> | looks like it works |
| 2023-04-17 22:44:24 +0000 | <geekosaur> | exposureMask and structureNotifyMask (so you can select an input mask on new windows as they appear) |
| 2023-04-17 22:45:24 +0000 | <JonathanWatson[m> | should i just bitwise OR them together? |
| 2023-04-17 22:45:30 +0000 | <geekosaur> | yes |
| 2023-04-17 22:46:33 +0000 | <JonathanWatson[m> | ok this is my code now... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/4e68c95a37b2a875e79b1288f05d911ea49a…>) |
| 2023-04-17 22:48:12 +0000 | <geekosaur> | don't forget to also set the input mask on the root window |
| 2023-04-17 22:48:39 +0000 | <geekosaur> | so you get notifications for new windows |
| 2023-04-17 22:49:55 +0000 | <JonathanWatson[m> | ok |
| 2023-04-17 22:51:09 +0000 | <geekosaur> | correction: substructureNotifyMask on the root |
| 2023-04-17 22:51:20 +0000 | <geekosaur> | (Notify, not Redirect!) |
| 2023-04-17 22:55:17 +0000 | <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/c5473cdb559f501974d4e9ad3745a0a47497…>) |
| 2023-04-17 22:59:36 +0000 | <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 +0000 | <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 +0000 | <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 +0000 | <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 +0000 | <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 +0000 | <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 +0000 | <geekosaur> | and wm events are not going to be draws anyway |
| 2023-04-17 23:04:47 +0000 | <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 +0000 | <JonathanWatson[m> | so do i only need to select substructureNotifyMask on the root? |
| 2023-04-17 23:06:15 +0000 | <geekosaur> | yes |
| 2023-04-17 23:06:24 +0000 | <geekosaur> | structureNotifyMask on everything else |
| 2023-04-17 23:07:09 +0000 | <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 +0000 | <JonathanWatson[m> | oh ok so i keep expose for checkTypedEvent |
| 2023-04-17 23:07:44 +0000 | <geekosaur> | right but you also want to checktypedEvent for mapNotify |
| 2023-04-17 23:08:01 +0000 | <geekosaur> | and selectInput on the window in question |
| 2023-04-17 23:10:52 +0000 | <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 +0000 | <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 +0000 | <JonathanWatson[m> | i can't see how to get the window for mapNotify |
| 2023-04-17 23:13:15 +0000 | <JonathanWatson[m> | oh get_window probably |
| 2023-04-17 23:13:21 +0000 | <geekosaur> | every event has an `ev_window` |
| 2023-04-17 23:15:11 +0000 | <JonathanWatson[m> | when we get a mapNotify event, what mask do we give the window? |
| 2023-04-17 23:15:36 +0000 | <geekosaur> | structureNotifyMask .|. exposureMask |
| 2023-04-17 23:15:48 +0000 | <geekosaur> | same as for the existing windows when you start up |
| 2023-04-17 23:16:55 +0000 | <geekosaur> | anyway an event is a Haskell record which has multiple fields that you can access in the usual way |
| 2023-04-17 23:17:29 +0000 | <JonathanWatson[m> | ok so this is my new code... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/8de1961fc197cb923ba05f03d0cae1c24793…>) |
| 2023-04-17 23:17:40 +0000 | <geekosaur> | https://hackage.haskell.org/package/X11-1.10.3/docs/Graphics-X11-Xlib-Extras.html look for MapNotifyEvent |
| 2023-04-17 23:18:40 +0000 | <JonathanWatson[m> | oh i see |
| 2023-04-17 23:20:38 +0000 | <JonathanWatson[m> | > <@jjw:matrix.org> ok so this is my new code... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/1fa31d40d7ff8269f48c039938c897c9961c…>) |
| 2023-04-17 23:20:38 +0000 | <JonathanWatson[m> | but its not giving anything anymore |
| 2023-04-17 23:20:40 +0000 | <lambdabot> | <hint>:1:1: error: parse error on input ‘<@’ |
| 2023-04-17 23:20:59 +0000 | <geekosaur> | did you do something like switching workspaces? |
| 2023-04-17 23:21:55 +0000 | <JonathanWatson[m> | i run it in workspace 1 every time and stay in there |
| 2023-04-17 23:23:15 +0000 | <JonathanWatson[m> | very strange |
| 2023-04-17 23:23:36 +0000 | <JonathanWatson[m> | > <@jjw:matrix.org> ok this is my code now... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/0769027e9da25bf11d789efaf2e9714ae49a…>) |
| 2023-04-17 23:23:37 +0000 | <lambdabot> | <hint>:1:1: error: parse error on input ‘<@’ |
| 2023-04-17 23:23:51 +0000 | <JonathanWatson[m> | well it printed some of the expose events |
| 2023-04-17 23:25:00 +0000 | <geekosaur> | you won't see anything |
| 2023-04-17 23:25:11 +0000 | <geekosaur> | as I said, you don't get events at all just for draws |
| 2023-04-17 23:25:28 +0000 | <geekosaur> | Expose means a new (region of a) window has become visible |
| 2023-04-17 23:25:56 +0000 | <geekosaur> | in a tiling wm, you don't get many Expose events unless you close a floating window |
| 2023-04-17 23:26:17 +0000 | <geekosaur> | you will pretty much only get events for opening a new window, closing an existing window, or switching workspaces |
| 2023-04-17 23:26:25 +0000 | <geekosaur> | this is pretty much the nature of tiling wms |
| 2023-04-17 23:26:43 +0000 | <JonathanWatson[m> | well it ran sometimes when i did next layout (alt+space) |
| 2023-04-17 23:26:58 +0000 | <geekosaur> | and when it comes down to it, if your intent is to benchmark a window manager, that's all you really care about |
| 2023-04-17 23:27:15 +0000 | <geekosaur> | right, that'll alter what windows are visible and how |
| 2023-04-17 23:27:36 +0000 | <geekosaur> | but no expose events because we pretty much show either all or none of a window |
| 2023-04-17 23:27:48 +0000 | <geekosaur> | and an expose event is about part of a window |
| 2023-04-17 23:28:55 +0000 | <geekosaur> | well, not entirely true, Tabbed layouts will produce whole-window expose events. but Full won't because it unmaps instead of hiding |
| 2023-04-17 23:31:32 +0000 | <JonathanWatson[m> | oh ok |
| 2023-04-17 23:31:44 +0000 | malook | (~Thunderbi@46.52.55.36) |
| 2023-04-17 23:32:08 +0000 | <JonathanWatson[m> | so i think i should also detect unmaps |
| 2023-04-17 23:33:11 +0000 | <JonathanWatson[m> | i have checkTypedEvent display mapRequest xEventPointer but its never true |
| 2023-04-17 23:33:46 +0000 | <JonathanWatson[m> | i suppose i want to check for unmapNotify |
| 2023-04-17 23:36:51 +0000 | <JonathanWatson[m> | i think there is a flaw in my code |
| 2023-04-17 23:36:56 +0000 | <JonathanWatson[m> | "The XCheckTypedEvent() function searches the event queue and then any events available on the server connection for the first event that matches the specified type. If it finds a match, XCheckTypedEvent() removes that event, copies it into the specified XEvent structure, and returns True . The other events in the queue are not discarded. If the event is not available, XCheckTypedEvent() returns False , and the output buffer will have |
| 2023-04-17 23:36:56 +0000 | <JonathanWatson[m> | been flushed." |
| 2023-04-17 23:37:15 +0000 | <JonathanWatson[m> | so it doesn't actually check the event from nextevent but actually checks the whole queue |
| 2023-04-17 23:37:44 +0000 | <JonathanWatson[m> | and the second checkTypedEvent never happens if there's an expose event at any point in the queue |
| 2023-04-17 23:39:12 +0000 | <geekosaur> | hm, right |
| 2023-04-17 23:40:44 +0000 | <geekosaur> | well, except the second part is wrong, it will first look for expose events and give you the first it finds, then it will look for MapNotify, then you want to look for UnmapNotify, then you want to nextEvent to clear the topmost event which is apparently none of the above |
| 2023-04-17 23:40:46 +0000 | <geekosaur> | then loop |
| 2023-04-17 23:41:00 +0000 | catman | (~catman@user/catman) |
| 2023-04-17 23:42:51 +0000 | <JonathanWatson[m> | this is my latest iteration... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/d5fe7d114c25baed420f096ac9133a7a2525…>) |
| 2023-04-17 23:43:09 +0000 | <JonathanWatson[m> | i don't think nextEvent is needed at all |
| 2023-04-17 23:43:16 +0000 | <JonathanWatson[m> | ? |
| 2023-04-17 23:43:45 +0000 | <JonathanWatson[m> | not sure what "output buffer will have been flushed" means |
| 2023-04-17 23:45:16 +0000 | <geekosaur> | if none of the `checkTypedEvent`s gave you an event then you need to possibly discard an event |
| 2023-04-17 23:45:34 +0000 | <geekosaur> | because there are other events you might receive that aren't the ones you're looking for |
| 2023-04-17 23:46:32 +0000 | <JonathanWatson[m> | yeah i'm thinking i can just run flush if all of them return false |
| 2023-04-17 23:49:27 +0000 | <geekosaur> | o.O I wonder if they actually mean the input queue; there's no "output buffer" |
| 2023-04-17 23:52:07 +0000 | <geekosaur> | actually, hm, in that case you would in fact not be able to do the second check (and the whole thing becomes difficult at best) |
| 2023-04-17 23:52:21 +0000 | <JonathanWatson[m> | yes |
| 2023-04-17 23:53:03 +0000 | <geekosaur> | https://tronche.com/gui/x/xlib/event-handling/manipulating-event-queue/XMaskEvent.html |
| 2023-04-17 23:54:07 +0000 | <JonathanWatson[m> | probably better |
| 2023-04-17 23:54:13 +0000 | <geekosaur> | and, well, I don't think you so much care about the actual event tyepe except insofar as you need to XSelectInput on a MapNotify |
| 2023-04-17 23:54:54 +0000 | <geekosaur> | any of the StructureNotifyMask/SubstructureNotifyMask/ExposureMask events indicate window manager activity |
| 2023-04-17 23:55:34 +0000 | <JonathanWatson[m> | i am wondering what is the difference between XMaskEvent and XCheckMaskEvent |
| 2023-04-17 23:55:54 +0000 | <geekosaur> | https://tronche.com/gui/x/xlib/event-handling/manipulating-event-queue/selecting-using-window-or-e… |
| 2023-04-17 23:58:07 +0000 | <geekosaur> | the remaining issue is finding out when activity from xmonad has ended. the classic but not really Haskell solution is you select() on the server socket with a timeout, and track the time when each select() returns so you know when all the activity finished |
| 2023-04-17 23:59:07 +0000 | <geekosaur> | the more Haskelly equivalent is to do the X stuff in a thread with results posted to a Chan, and the main program kills the thread after the timeout (see the async library) |