From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: master 4b98a79a50: Improve X event timestamp tracking Date: Sun, 7 Aug 2022 02:25:14 -0400 Message-ID: References: <165984385935.14715.8191942019361575877@vcs2.savannah.gnu.org> <20220807034419.B5F2FC09BFD@vcs2.savannah.gnu.org> <87y1w0zpe9.fsf@yahoo.com> <87r11szp6h.fsf@yahoo.com> <19d020d85bed5d030e706800f8cbb0b7fbb3bc65.camel@dancol.org> <875yj4znp5.fsf@yahoo.com> <75aa6286819b4ca9b008a3697b293567321c0d86.camel@dancol.org> <87h72oy682.fsf@yahoo.com> <0b58658c390b8c62cc1c5dfadd9e1f0621f64d82.camel@dancol.org> <87iln4wprn.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29462"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 07 08:28:45 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oKZmG-0007Sa-Aj for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 08:28:45 +0200 Original-Received: from localhost ([::1]:35618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKZmF-0003mw-8u for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 02:28:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57514) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZiz-0002qv-2o for emacs-devel@gnu.org; Sun, 07 Aug 2022 02:25:21 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:42304) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZiw-00062x-LE for emacs-devel@gnu.org; Sun, 07 Aug 2022 02:25:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:Cc: To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gJeIVA33qjvyERWWCAKgkRuR0hrWx7oa6itXXRV6dDk=; b=L1dd/wVWLRCfuXMTX24pqnMnDA P+22IHaSnTpFZBfbmQA34FJpncgriqbRItsTLWVj1OKexq4XVqfVJPO8QqKRTXdSzd0SrnxScqyye coshNbp0Ap6WI42kebdTxsxIP4njmq4rXQZg0iYFWoOxFgZqAqGT4m+Z1zZCcYMyuvYf+veZdrpgz 3/zEEhg4vwCCepJF2QyIXwuCefA1AiCqUtN8R426woAvzcFYMA1aMnBim9fYCF31fQT22POA893W8 LZz+RCso6kylKztG3DQah6b76dMVJQHc4rN6lPCteeBMI4W5pUgeTnfNwdX9r33BZcSHlrmHLV3Tp diqPO3Bw==; Original-Received: from 2603-9001-4203-1ab2-d8bc-e9aa-fed2-dc13.inf6.spectrum.com ([2603:9001:4203:1ab2:d8bc:e9aa:fed2:dc13]:59928) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1oKZit-0007HA-LV; Sat, 06 Aug 2022 23:25:15 -0700 Content-Language: en-US In-Reply-To: <87iln4wprn.fsf@yahoo.com> Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293179 Archived-At: On 8/7/22 02:07, Po Lu wrote: > Daniel Colascione writes: > >> Yes, it does. That's the whole point of being the window manager. Are >> you suggesting that application developers, not users, ought to get >> the final word on what windows go where? > _Emacs_ users and developers get the final word, not window manager > developers. 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. 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. >> Yes, they are sloppy, just like all other users and developers, you >> and me included, are sloppy. What's the old quip? Ah, right: "If men >> were angels, no laws would be necessary". If developers were perfect, >> we wouldn't need ASLR, or memory protection, or file permissions, or >> fuzzing, or memory-safe languages --- yet here we are. > So you are saying that ASLR or memory protection is the same as focus > stealing "prevention"? Seriously? You're the one suggesting that Emacs developers are somehow talented enough not to abuse APIs. >> Developers of Emacs are no more angelic than developers using any >> other toolkit, and focus stealing prevention mitigates their mistakes >> as much as it does any others. If a user doesn't want focus stealing >> preventation, he can disable it or use a window manager that doesn't >> provide it. It's not the place of Emacs to override the user's >> preference. > Why can't the user also customize `x-allow-focus-stealing' (see the > patch I sent) to nil? Or better, report a bug to the Emacs developers > while at it? 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? > Focus stealing prevention is not a user choice, and can't even be turned > off in the popular window managers. 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. >> If a process filter tries to asynchronously raise a window when the >> user is the middle of browsing cat pictures, and that user has >> configured his WM to block attempts by applications in the background >> to raise windows, the WM is right to block that raise attempt. The WM >> is where policy belongs. > I don't see > >> It does exist elsewhere. From MSDN's page on SetForegroundWindow >> (https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) >> : >> >> The system restricts which processes can set the foreground window. >> A process can set the foreground window only if one of the >> following >> conditions is true: >> >> * The process is the foreground process. >> >> * The process was started by the foreground process. >> >> * The process received the last input event. >> >> * There is no foreground process. >> >> * The process is being debugged. >> >> * The foreground process is not a Modern Application or the >> Start Screen. >> >> * The foreground is not locked (see LockSetForegroundWindow). >> >> * The foreground lock time-out has expired (see * >> SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo). >> >> * No menus are active. > I don't see an analogue here, because there's no way for us to manually > specify that Emacs received the last input event. > >> Also from that page: >> >> A process that can set the foreground window can enable another >> process to set the foreground window by calling the >> AllowSetForegroundWindow function. The process specified by >> dwProcessId loses the ability to set the foreground window the next >> time the user generates input, unless the input is directed at that >> process, or the next time a process calls AllowSetForegroundWindow, >> unless that process is specified. > That's different, because another program is explictly prohibiting a > program from setting the input focus. The target of AllowSetForegroundWindow *gains* the ability to set focus where it otherwise couldn't. It's a nice handoff mechanism. > Whether or not input was received > is also accounted for by the window system, not the program itself. Yep. That's one way Win32 ends up being better than X. > Also, is Emacs a "Modern Application" on MS-Windows? I thought it still > runs on Windows 9X. 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. >> Guess what API emacsclient calls. > Yet x-focus-frame works. > >> It's a generic hint that only one or two backends care about right >> now. That's not the same as a leaky abstraction. > It's not a hint at all. Yes it is. > >> Platform-implementation code shouldn't have to know about platform >> specifics. That's why frame operations should be generic and >> polymorphic, not ad-hoc and gated behind type tests. > So it doesn't have to apply such a hint. It only has to run > x-focus-frame, and as a result the frame is activated. Sometimes contrary to what the user wants. >> I'll say it again: server.el hinting to Emacs that the user has >> interacted with a frame is not an implementation detail of a window >> system. >> Startup notification isn't suitable here because we're not starting >> anything. > It's the only protocol that transfers the X server timestamp at which a > user launched a program (by dropping a file onto an Emacsclient desktop > icon) to the program being launched. > >> Emacsclient could include *its* server time in the message. > How will emacsclient be able to send the server time reliably, ensuring > "correct ordering"? > > Consider the following sequence of events: > > emacsclient X server emacs > ChangeProperty -------------------> > --------------> > <------------------ PropertyNotify > --------------> > ClientMessage ------------------> > --------------> > ClientMessage --------------> > > By the time the client message arrives, the timestamp will already be > out of date. Yeah, you're right. A synthetic input event would work, wouldn't it? It doesn't matter, though, because emacsclient doesn't work that way. >> Well, a related protocol would be nice. Feel free to propose one. > It would be useless since nobody else will support it at this point. > All active development is happening around Wayland (no matter how much > your or I despise that fact.) I'm not a Wayland fan either, but we're way past the "disagree and commit" phase on that one. I just hope that protocols emerge that let us claw back some of the lost flexibility of X11.