Re: master 4b98a79a50: Improve X event timestamp tracking

[Po Lu <luangruo@yahoo.com>]

Daniel Colascione <dancol@dancol.org> writes:

> Should Emacs set override-redirect all its frames, draw client-side
> decorations, and grab the keyboard all the time too --- just in case
> the window manager does something wrong? The purpose of a window
> manager is to manage windows: it's the part of the system tasked with
> what-goes-where policy. I'm genuinely confused about why you think
> Emacs in particular should go to lengths to contravene that policy.

Because our users asked for it, and such a policy is causing Emacs bugs.
Like various other places where we fight with the window manager.

> This discussion is a great example of why OS developer shouldn't give
> application authors an "escape hatch" that lets them opt of policy
> enforcement under the theory that they must have some good reason for
> doing so. Turns out, everyone thinks he has a good reason.

Fortunately for us, X was designed with a completely different attitude
in mind.

> You're the one suggesting that Emacs developers are somehow talented
> enough not to abuse APIs.

Well, your suggestion is also abusing an API, just in a different way.
_NET_WM_USER_TIME only applies to ButtonPress and KeyPress events (and
their input extension equivalents.)  Programs aren't supposed to get the
timestamp from the X server and set the user time, they're only supposed
to do so in response to a limited set of input events.

> Because 1) users won't know it's there, and 2) setting
> x-allow-focus-stealing to nil will break the legitimate emacsclient
> use-case, and 3) what if every program did this?

It will be documented in PROBLEMS, and emacsclient can be modified to
bind it to some other value in that case.  And Emacs isn't every
program.

> It's a preference in some window managers. That it's reached
> always-enabled status in others suggests that it's a good thing and a
> signaled user preference that Emacs should not attempt to defeat.

So what about everywhere else we bludgeon the window manager into
obeying our commands? Starting from the various frame resizing hacks
(Martin knows more) to actually determining window manager positioning
behavior and fighting with type "A" window managers over the position of
a frame? All of those solutions have worked fine over decades, so I
don't understand why this has to be any different.

> Yep. That's one way Win32 ends up being better than X.

But then the bug could never be fixed under MS Windows.

> Emacs is every bit a modern Windows application. There's been a lot of
> effort put into graceful degradation when running under
> less-than-cutting-edge environments like Windows 95.

I'm talking about the "Modern Application" referred to in the doc,
specifically this part:

>>>    * The foreground process is not a Modern Application or the
>>>      Start Screen.

> Yes it is.

Why, if there's no way to set it?

> Sometimes contrary to what the user wants.

Then the user can customize the variable to nil.

> Yeah, you're right. A synthetic input event would work, wouldn't it?

Synthesizing input events doesn't work either, because the X server will
cargo cult the timestamp you put in the event that's sent.  The only
halfway-reliable way is to change a property on the frame's window and
wait for the PropertyChange event.

(Grabbing the server doesn't work either because the input events that
pile up will get sent first, after the grab is released.)