Add a method to get the Window of the target of the event without having to know the event.

[JCBurnside]

In at least version 0.9.0 there is no easy method to simply check if a given event is supposed to be handled by a window without first matching the event and extracting it from there. I propose adding a function on the x11rb::protocol::Event enum to ease this process that would look similar to

fn get_targeted_id(&self) -> Option<x11rb::protocol::Window>

returning Option since not all events are specific to a window.

[psychon]

Puh, that's a complicated request. The existing XML from xcb-proto does not provide that kind of information, so someone would have to go through all X11 extensions and figure out which events have a relevant window field...

A quick (over-)estimate indicates this is a big job: (But the following also contains replies and requests and I guess most window fields are in those).

$ grep type=\"WINDOW * | wc -l
237
$ grep type=\"WINDOW *  | cut -f1 -d: | uniq -c | sort -n
      1 dri3.xml
      1 xv.xml
      2 dri2.xml
      2 xkb.xml
      2 xtest.xml
      3 screensaver.xml
      3 xprint.xml
      4 xselinux.xml
      6 xinerama.xml
      9 composite.xml
      9 present.xml
     10 shape.xml
     11 xfixes.xml
     26 randr.xml
     49 xinput.xml
     99 xproto.xml

Would this really save much code in library users? Personally, I would code event handling as first matching on the specific event and inside the per-event code would I then look up some window if I need it. This approach also would save a bit of work: Events which are ignored will not cause the right window state to be looked up.

[notgull]

This could work, possibly. There’s a specific field in every event (can’t remember it off of the top of my head) that is reserved for the "target" resource, and this is always at the same index in every event.

[psychon]

Huh? That's the first time I hear about that. A quick look into https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html didn't find anything like that. A quick look into libxcb's xproto.h makes me doubt that a lot:

typedef struct xcb_key_press_event_t {
    uint8_t         response_type;
    xcb_keycode_t   detail;
    uint16_t        sequence;
    xcb_timestamp_t time;
    xcb_window_t    root;
    xcb_window_t    event;
    xcb_window_t    child;
[...]

typedef struct xcb_focus_in_event_t {
    uint8_t      response_type;
    uint8_t      detail;
    uint16_t     sequence;
    xcb_window_t event;
    uint8_t      mode;
    uint8_t      pad0[3];
} xcb_focus_in_event_t;

The event field of a FocusIn event is at the same byte offset as the time field of a KeyPress event.