From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: master 4b98a79a50: Improve X event timestamp tracking Date: Sun, 07 Aug 2022 14:07:08 +0800 Message-ID: <87iln4wprn.fsf@yahoo.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26668"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 07 08:09:23 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 1oKZTX-0006mA-MJ for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 08:09:23 +0200 Original-Received: from localhost ([::1]:53876 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKZTV-0004n7-Tl for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 02:09:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56090) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZRd-0003Zb-TH for emacs-devel@gnu.org; Sun, 07 Aug 2022 02:07:28 -0400 Original-Received: from sonic307-56.consmr.mail.ne1.yahoo.com ([66.163.190.31]:35466) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oKZRb-0003xK-4K for emacs-devel@gnu.org; Sun, 07 Aug 2022 02:07:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659852440; bh=eTnwK0OUMlMuaClR8tV0LGhYScCAlwgpFgP5+7Rsc9c=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=qb+iby32XgrBXPPXz6XyqOPL9fJtbQ3VVDcIZT2xhqoHT2ewAn74KdUnfQJ8EHxcx3Dfcj/PSAjOJXVa3liRdZS/hOmqQHuVy1jeoBukz43xwb18kaOW7QnIuSDik4v4rZ+Az+QO8cFcfVoQei7ZOaeH6yOzrVl2opTmZGyYRPWrLh3Sm0KATcKk3xUgARGru1qhBsqo/udeFNW/PDlKtHoxx/Nzc6H0VuXuXhJ7CRE3C0D0WqLimQmAPE2JbNCAp1H/+jY/gJn71hMurOTEZeQFgLKp6ZGj7gY7WWsvzPuWfICaiMBaZ6dFgd6kGItpq+W7Gi8avXRDflWUFyb8iQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659852440; bh=NkSV8g1jHlngwIYjFV/J8jGVaUVikKw63VSLy0AwpED=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=FM1oVix7G8so7iLGyDg5S0kHOhFdZtomnBFDgfRdcoB/iezlhg9t84MnVJEsBO2lAxTBBBGIc8Yy7WZs6Kf/6dc4P/0oFbataBsss8qhIIjnHvdTTboGkqDTkeT8TnQoZR/vd85wKLkd28bPrzehfLQuPKu5UKi3B5r5TaBMOcdDk5plt20SaCQeNAuLrnsyJMnhYlr6IvClac+m+jPplDEndBUxEgWDxUyG4mUeKkcMqSZgOHWUFJJY0NlhszIXYO/Qqowm25iXGcCqOMzugMfPI8PJBFMcc/23lzwnDLttVPYYs8mJQK+oZUD6yyXs7oE31HTC1BdoGit5WaAe7Q== X-YMail-OSG: CTRwopcVM1kSsBphVJJGRGfjyw6oynQ5whG.PyrE9rfYpnsbEjwKyt3Nl7G_B25 jaM2jdaj9oztreV4bnjxPAhHjrZA5ReXgTMkbOXiLJ3DT32DJPrn29.fyDKKUtG4V99KAYRYUrkG n3.Fygvl6YP7m3SF2f3lk_vFa0Qa.9zxarjYZMmu.asiPJf9P4AMFVQF_3TJnm4AiiS_EDmZ7UCA xwxQyuwePAM12GrN03QhRR1_h8L.ScnQlpUTQoR84ba2476_91g_YKYDjJzI1dEbXR2DhKzto90u JZC4imHL0q6O_6DxMXo3j9Ai4.zBFKRhI5qtikYjmUx3dNwBcf4_oDLf8T.mrCdZLek34dX3MadI csqTfgwTxvHDBiDVY18sYRB1sd9fxckBx_jQegY__uzFW0tthfLHWhf8P8QxELgJacDWRTXJknBn ilG5kCxFyQmS1Zmf5T9WuZQGgq5zW256SjR9iWppnLw4U58vT_ecWJX1x3IaZLjLsU9x0_imMoz3 Kd3k6AKM5R4J_t4iD_wPnmTd3QFwmjbv.P6mHYjtoRwwGAEEPzSNhSh83xYa6MT87TVC6H.e8qvU 6BpPByVgvCVr_fAzy8T8ujdqILXP83kZFBjgu5jrr0zqqtvx2d0lwnl.wuVvAZlbeO3cONd8dAtU xGBiUY58XWQW8IT2C4y5FLhCzs_DQJ2AmxSBGMkwSydTGjij3k12CCXTxyhwLIs9IVQSPk7QZOw1 GWlbM.xkPg9WoCo57LCpQS6KL0qSBdiNEnG6KUqTh8i.jO9FHeDaaZ.XxBM_rl1VSFzh9kgLI3rF Z4SoemTN6qNWoPrMoJ_TOTOp0EeUNhUY.aO3PponKP X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Sun, 7 Aug 2022 06:07:20 +0000 Original-Received: by hermes--canary-production-sg3-6f58cd9b5-q5dg5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f04191645fb0eb56f242c8ad62aa34b4; Sun, 07 Aug 2022 06:07:14 +0000 (UTC) In-Reply-To: <0b58658c390b8c62cc1c5dfadd9e1f0621f64d82.camel@dancol.org> (Daniel Colascione's message of "Sun, 07 Aug 2022 01:43:43 -0400") X-Mailer: WebService/1.1.20491 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.190.31; envelope-from=luangruo@yahoo.com; helo=sonic307-56.consmr.mail.ne1.yahoo.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:293176 Archived-At: 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. > 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".=C2=A0If 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? > 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? Focus stealing prevention is not a user choice, and can't even be turned off in the popular window managers. > 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=20 > It does exist elsewhere. From MSDN's page on SetForegroundWindow > (https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-se= tforegroundwindow) > : > > 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. Whether or not input was received is also accounted for by the window system, not the program itself. Also, is Emacs a "Modern Application" on MS-Windows? I thought it still runs on Windows 9X. > 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. > 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. > 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. > 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.)