[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 4b98a79a50: Improve X event timestamp tracking

From: Daniel Colascione
Subject: Re: master 4b98a79a50: Improve X event timestamp tracking
Date: Sun, 07 Aug 2022 02:55:39 -0400
User-agent: AquaMail/1.38.0 (build: 103800177)

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]