Re: master 4b98a79a50: Improve X event timestamp tracking

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 4364 bytes --]



On August 7, 2022 02:41:25 Po Lu <luangruo@yahoo.com> wrote:

> 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.

Sure, but don't we have, in this instance, an option that doesn't involve 
fighting 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.

It's definitely from a more naive time. You can tell by the lack of 
inter-client security.

>
>
>> 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.

I'd argue that my suggestion is consistent with the spirit of the API and 
changes behavior only in a narrow case. Your proposal involves changing the 
behavior of every x-focus-frame call made when Emacs doesn't have focus, 
yes? (Also, aren't you worried that the focus check will lead to behavioral 
inconsistencies?)


>
>
>> 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.

Because there's a less invasive alternative.


>
>
>> Yep. That's one way Win32 ends up being better than X.
>
> But then the bug could never be fixed under MS Windows.

The bug doesn't exist on MS Windows because the Win32 API has a function 
specifically designed to help apps do what emacsclient wants to do.

>
>
>> 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.

Customizing the variable to nil breaks emacsclient.

>
>
>> 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.)


[-- Attachment #2: Type: text/html, Size: 10324 bytes --]