-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wew sometimes doesn't catch an event #3
Comments
Here's the fix (that works for me): master...onodera-punpun:master#diff-0fd277e6661666192c9be11af76b25ddL99 |
@onodera-punpun It fixed it, thanks! |
Since a few commits, Now regarding @onodera-punpun "fix". As of this explanation, your "fix" will only make |
I am using the version before today's commit. Can it be because I'm running on a VM, making it unreliable? |
It might be. Which WM are you running? À dim. août 2 00:27:44 2015 GMT+0200, João Pedro a écrit :
Envoyé depuis mon Jolla |
I meant VM, not WM. Anyway, I'm using VirtualBox v4.3.28 r100309 on Windows 8.1 Pro 64 bits. |
I had this happen to me as well (using today's git). Because of that, I experimented a little and found out that detail is only 2 for a transition between a window border and a window content of the same window ID. All other values of detail are actual transitions between windows (window content to other window content, window border to root window, etc) that should send an enter or leave event. Also, the transition between window border to window content (of the same window ID, detail == 2) sends an xdg_leave_notify_event even though the transition is in the direction of the inside of the window I made a small fork with a patch for this, here is the diff Behavior with current master: Transitions between overlapping windows don't send enter or leave events. Transitions from and to the root window work fine. Transitions directly from the root window to the window content (e.g. by moving the mouse very fast) also don't work. Behavior with my fork: All transitions except window border to/from window content (of the same window ID) send leave and enter events. |
Wow, that is an awesome job you did there to figure out what the detail is. I tried to figure it out myself, but it seems that I failed miserably. Thank you for sorting this out, I'll update wew's behavior to include this. À sam. août 8 18:48:50 2015 GMT+0200, Ferdi265 a écrit :
Envoyé depuis mon Jolla |
I just read your diff, but couldn't test it. firs it means the ENTER event will be sent twice each time the cursor enters a window? (enters border AND enters content). If yes, then it bother me as it should only trigger it once. For the user, the cursor only enters the "window", so there shouldn't be 2 events. I'll troubleshoot this. Also, c++ comments are forbidden by c99 standards. Prefer block comments instead. Good.job otherwise, it really helps as wew will niw be able to notice when entering a window from another window, which is something that I couldn't figure out how to do. |
It seems that the border is kind of a sub-window thing (don't really know how Xlib and xcb work, so this is just guesswork). Interestingly the border is treated as if it were just another window (with the exception of having special detail values for events). when you transition from the border to the content, you don't enter the content, you "leave the border". I think it is quite weird myself, but I guess it could kind of be used to implement resize-when-dragging-on-border-like things. Also: figuring this out was a few hours of work, I was confused too at first, but then I tried to map every event to a mouse action until I figured it out. Thanks for the tip with the comments. I'll update my fork and submit a PR. |
To clarify: (only tested with windows that have borders, setting window border to 0px behaves the same way, but I don't know how windows that never had borders in the first place behave. From my research, they should behave correctly though) When the mouse enters the window (from the root window, passing the border), the following happens in order: The mouse enters the border, an ENTER event with detail 0 is sent. this means, when the mouse enters a window from the root window, both a leave and an enter event are sent. This is different with overlapping windows. Assume W1 and W2 are windows, the mouse is in W1s content, and W1 overlaps W2 (W1 is on top). This means that if events with detail 2 (border events) are ignored, an enter or leave event will be sent for every actual window enter or leave. There will not be duplicate events, and situations like fast moving mice (or nonexistant borders) are handled correctly. If you ignore detail 2 events, the previous examples (and the wew output) change to this: Example Nr.1: An ENTER event is sent for W1 Example Nr.2: A LEAVE event is sent for W1. Simultaneously, an ENTER event is sent for W2. |
The borders are special from the X POV. They're not really windows, but they are still an "object" on their own, which is why X makes the difference between a window and its border. From wew's POV, I think that entering a window should mean both crossing a window's border from outside to inside, or entering content. It should not report 2 'ENTER' events when the cursor enters a window. That would be both confusing for the user, and useless (if not annoying) when parsing events. So yeah, I gave it a try, and simply ignoring events with detail:2 is good enough. So the patch is as easy as replacing I don't know how much you care about having your nick listed in the commiters, so if you want to provide a pull-request, that's ok. Otherwise I can just push the changes I just made. It's up to you. |
I tried to document the details from what I could reproduce, without looking at
For the ENTER detail 1, it occured when I had the mouse cursor grabbed by an He still believe this event is a pain to deal with, and won't change the function name for any reason, haha. |
We're getting closer and closer to knowing how exactly this event works. My POV of how I think detail 1 works: The way mouse input in X works, it polls the mouse for a delta and moves the mouse accordingly. If the delta is high enough that it doesn't actually cross the border, but "teleports" in, that is a transition root -> content. This always seems to have detail 1. It seems that cursor grabbed might be similar: When it is ungrabbed, it "teleports" somewhere. This could probably reproduced more easily with an absolute pointing device (i.e. tablet). Leave detail 1 has happenes to me by doing the opposite: fling the mouse (so fast that the delta is high enough), that it leaves the window without transitioning over the border. When I get home, I'll test this with Leave detail 3 also seems to happen for me with border self -> border other (tested with huge borders and aligning windows so borders overlap) useful testing tool here is Enter detail 3 is the same but the other way round (border l content) other -> border self For detail 4 it's the same, but you replace border self with content self: Leave detail 4: content self -> (border l content) other Enter detail 4: (border l content) other -> content self Anyway, could you provide a screenshot like mibe (testing windows, event log, description of events). I'll attach a wew patch like the one seen in my screenshot for testing purposes. (Also, motherfuckingenterevent() seems to fit even better now, as we seem to be just beginning to understand how f*cked up this whole thing is) Once we finish documenting how this works we should push it upstream to xcb as it seems to still be marked as NOT YET DOCUMENTED on the manpage for xcb_enter_notify_event_t and xcb_leave_notify_event_t As a final note: Once this gets resolved, I'd want to either do this with a PR, or if not, at least be mentioned in the commit message (not in the headline, that wouldn't make any sense). I love your scientific approach to this, so to make this a bit more objective, we should start to create test cases and continuously try to verify or disprove each others theories until we both agree :) |
I've been testing a few things, and your idea about detail 1 seems to be the I experimented ENTER events a bit, and here is what I found:
above/below refering to the stacking order. I made a quick video to illustrate This is what I show at the end of my video, where the cursor is on the top We'll have to figure out what the "best" behavior is. |
That's what I've been noticing too when testing things. What do you think the behavior should be? Because logically you are technically leaving the window when you move it somewhere else. and if it didn't send an enter event for this situation, it would still send a leave event for when you leave that window, even though an enter event for that window would never have been sent. This patch seems to be a very tricky situation, as it is clearly broken in current master, and the fix seems logical, but seems to add confusing behavior, which might break people's setups. |
I must admit having a few difficulties to understand your point here. Using still images probably don't help much. Would you be avail on IRC to discuss it directly? I'll be in #wmutils on irc.iotek.org fir the next hour |
I did some further testing after reading your comment carefully, and you were right, it has nothing to do with the stacking order. From what I could figure out, here is the updated list of details for the ENTER event:
Is that what you noticed too? |
Fuck. When I move the cursor from urxvt's border, to dwb's content, I get detail == 3. This is driving me crazy... |
Sorry for being silent for so long, but I didn't find time to do any further research about this. What I did find out is that |
I'm glad to see you back! And with a good hint!! |
Yeah, I still have to get back into the flow (also, install wmutils so I can actually test stuff). I don't get some stuff that xev outputs either, but it might be worth a try. I also have working ffmpeg recording now, so there's that. Only problem is that school's picking up again, and there's a lot to do, but I'll try to get a good look on this problem, so we can actually fix it soon-ish. |
So, testing this further, testing scripts: I made a script that spawns a few The goal of this is to have tests that others can run and confirm, without having to think about it the same way as I do. This avoids bias, while confirming true observations. The script: First
and
|
This might help too: https://tronche.com/gui/x/xlib/events/window-entry-exit/ Gonna take a closer look at this tomorrow |
From the second link:
What then follows is the section Virtual Crossing and the detail Member. The possible values for detail are NotifyAncestor, NotifyVirtual, NotifyInferior, NotifyNonlinear, and NotifyNonlinearVirtual. This maps nicely with the 5 possible values I (and possibly we) have observed in testing. My documentation snippet from the PR: /**
* xcb_enter_notify_event_t->detail and
* xcb_leave_notify_event_t->detail Documentation:
* Legend:
* self .... wid in ee->event
* other ... other wid
* root .... root window
* ee->response_type == 7 (enter):
* e->detail == 0:
* root -> border self
* e->detail == 1:
* root -> content self
* e->detail == 2:
* content self -> border self
* e->detail == 3:
* other -> border self
* e->detail == 4:
* other -> content self
* ee->response_type == 8 (leave):
* e->detail == 0:
* border self -> root
* e->detail == 1:
* content self -> root
* e->detail == 2:
* border self -> content self
* e->detail == 3:
* border self -> other
* e->detail == 4:
* content self -> other
**/ The only problem here is, that we don't know for sure which of these names maps to which of the possible These names look like something that would be defined as a constant in an XCB header file. It might be worth looking into that to get the definitive order. |
I found it! All the XCB constants are defined in In there, we have an enum called typedef enum xcb_notify_detail_t {
XCB_NOTIFY_DETAIL_ANCESTOR = 0,
XCB_NOTIFY_DETAIL_VIRTUAL = 1,
XCB_NOTIFY_DETAIL_INFERIOR = 2,
XCB_NOTIFY_DETAIL_NONLINEAR = 3,
XCB_NOTIFY_DETAIL_NONLINEAR_VIRTUAL = 4,
XCB_NOTIFY_DETAIL_POINTER = 5,
XCB_NOTIFY_DETAIL_POINTER_ROOT = 6,
XCB_NOTIFY_DETAIL_NONE = 7
} xcb_notify_detail_t; As you can see, the order from the first link is, in fact, correct. With this knowledge I hope I'll understand the section on the |
From what I've read in the second link, these are my insights into the actual window hierarchy: Example (indented further == child):
For now, I'll discuss only enter events: Now, if we transition from If we transition from Transitions between the window's content, When transitioning between windows not directly children of one another, they both get events with |
A possible solution to the event confusion would be to ignore events of type As you can see, the value of Thank you for these two links. They are like a gold mine worth of information on this. Great job! EDIT: I just noticed that ignoring |
I ended up finding a detailed explaination here:
I'm not ENTIRELY sure about the So in the end, I think we need I tested this "new" version of wew, and it seems to work rather nicely. I'll |
The only problem is that, again, this new version of wew outputs both an enter and a leave event for every window entered. (1: Entering the window, 2: leaving the window to the content child window) This properly represents the way X handles this, but makes this event almost useless for general use in scripts. This kind of event should either not be included or the wew output should contain detail values |
I get your point. Let me think about it |
Seems that you were right: ignoring Gonna push it a test for a while. Thanks a lot! |
Sure thing :) |
Fixes Issue wmutils#3 Discussion and reasoning behind this change available on GitHub
Known annoyance. This is a consequence of the fact that moving something below the curser gives an "enter" event in X. The same thing happens as well with the old version of A workaround to this is to synchronize some wmutils scripts to "disable" autofocus for the duration of a window movement and then "reenabling" it. On a side note: Your desktop looks stunning everytime I see it, and it's different every time |
I think we can find a solution around it. By digging those DETAIL_NOTIFY_POINTER maybe? À mar. nov. 17 20:55:09 2015 GMT+0100, Ferdi265 a écrit :
Envoyé depuis mon Jolla |
I've never seen an Do you by any chance have a test case with which you can reliably reproduce such an event? |
Not yet :/ |
Fixed by: 8754fc9 |
If you move your mouse too quickly from one window to another, wew won't catch event number 7 (XCB_ENTER_NOTIFY), preventing my script from properly working.
Since it's seems that the event triggers on the window's border and I'm testing everything on a virtual machine before I do a real install, it could be because the VM is too slow, but I'm not sure about that.
The text was updated successfully, but these errors were encountered: