|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)|
Daniel Colascione <email@example.com> writes:Should Emacs set override-redirect all its frames, draw client-sidedecorations, and grab the keyboard all the time too --- just in casethe window manager does something wrong? The purpose of a windowmanager is to manage windows: it's the part of the system tasked withwhat-goes-where policy. I'm genuinely confused about why you thinkEmacs 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 giveapplication authors an "escape hatch" that lets them opt of policyenforcement under the theory that they must have some good reason fordoing so. Turns out, everyone thinks he has a good reason.Fortunately for us, X was designed with a completely different attitudein mind.
You're the one suggesting that Emacs developers are somehow talentedenough 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 (andtheir input extension equivalents.) Programs aren't supposed to get thetimestamp from the X server and set the user time, they're only supposedto do so in response to a limited set of input events.
Because 1) users won't know it's there, and 2) settingx-allow-focus-stealing to nil will break the legitimate emacsclientuse-case, and 3) what if every program did this?It will be documented in PROBLEMS, and emacsclient can be modified tobind it to some other value in that case. And Emacs isn't everyprogram.It's a preference in some window managers. That it's reachedalways-enabled status in others suggests that it's a good thing and asignaled user preference that Emacs should not attempt to defeat.So what about everywhere else we bludgeon the window manager intoobeying our commands? Starting from the various frame resizing hacks(Martin knows more) to actually determining window manager positioningbehavior and fighting with type "A" window managers over the position ofa frame? All of those solutions have worked fine over decades, so Idon'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 ofeffort put into graceful degradation when running underless-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 theStart 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 willcargo cult the timestamp you put in the event that's sent. The onlyhalfway-reliable way is to change a property on the frame's window andwait for the PropertyChange event.(Grabbing the server doesn't work either because the input events thatpile up will get sent first, after the grab is released.)
|[Prev in Thread]||Current Thread||[Next in Thread]|