Potential approach to EnterNotify problem in window manager

[Ingo Bürk]

Hi Thomas,

thank you for your reply!

> KWin FFM has a general pointer position comparism.
Yeah, I guess that's one way to do it, but seems like a lot of trouble
to go through.

> You could add a hinting property to the i3bar or just compare class
> and type properties to know that this is the i3bar. 
We don't want to ignore EnterNotify in all cases, only in the scenario
of hiding the bar. If the user moves the mouse from i3bar to a window,
we still need to process it and change the focus. So i3bar would have to
set a property on the window, unmap it and then remove the property
again. But that'd require i3 to query properties of the window for every
EnterNotify. I guess an even bigger issue is that the EnterNotify won't
actually know where it came from, but only contain the target window, so
on top of this all we'd have to correlate EnterNotify to the previous
LeaveNotify to know which window the pointer came from. Sounds like it'd
be a rather unstable approach prone to mistakes.

The way I see it tracking the pointer is a – in theory – doable
approach, even though I'd personally not be a fan of it. I've done
pointer tracking for my tool xedgewarp before and unless you use
Xinput2's raw events, it only causes nighmares and breaks applications
like Chrome. So since i3 is based entirely on xcb that would also add
the problem of xcb-xinput being in a pretty broken state in the
typically circulating xcb releases at the moment.


Ingo


On 10/23/2015 12:01 AM, Thomas Lübking wrote:
> On Donnerstag, 22. Oktober 2015 22:17:28 CEST, Ingo Bürk wrote:
>
>> This causes the problem that if the user puts their pointer "away" in
>> some corner, then shows the bar for a second and then hides it again,
>> X11 generates LeaveNotify for i3bar and EnterNotify for whichever window
>> is underneath the pointer. Since the user might have "focus follows
>> mouse", this causes said window to be focused, even though it's not at
>> all the intention of the user (they're not really looking to use their
>> mouse at all in this scenario).
>
> KWin FFM has a general pointer position comparism. Only actual
> movements cause a focus change, not random crossing event caused by
> window un/maps (as eg. caused by popups)
>
>> Now, if i3bar was part of the window manager, we could obviously just
>> discard the EnterNotify in the window manager to avoid this.
>
> Humm?
> The EnterNotify is generated for something else anyway, but window
> detection is not related to the process at all. You could add a
> hinting property to the i3bar or just compare class and type
> properties to know that this is the i3bar.
>
> Cheers,
> Thomas
> _______________________________________________
> xorg at lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s