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 15:02:11 +0800 Message-ID: <87v8r4tu30.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> <83pmhcy5it.fsf@gnu.org> <8735e8y4z6.fsf@yahoo.com> <8735e8wpef.fsf@yahoo.com> <5b4dda05-45cc-6843-c87f-047efda257df@dancol.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26435"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: Eli Zaretskii , 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 09:04:29 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 1oKaKr-0006gQ-JY for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 09:04:29 +0200 Original-Received: from localhost ([::1]:46656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKaKq-0004Z0-5h for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 03:04:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60658) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKaIw-0003pW-JM for emacs-devel@gnu.org; Sun, 07 Aug 2022 03:02:31 -0400 Original-Received: from sonic316-22.consmr.mail.ne1.yahoo.com ([66.163.187.148]:39459) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oKaIu-0002VZ-0z for emacs-devel@gnu.org; Sun, 07 Aug 2022 03:02:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659855745; bh=t71p38FaHkUpszBm+RyUFpsPpyyAWSMhC93Yy1ADDhA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=iHXWmI+OpxA6NQDPKRK55fyZFcMmIPPuLsO0CfiHHMviYBBY0unmtsa5gGiHbkE573KFv5DgXrwT4KC6cbrknWmVTE277fLhwfhfE9zi+iUNpbDYlgwDdGutzu7BXXrvlrucVxURDQbWuaVURywzHkpLpX137DKUwp6ZKQLa+Z235kpBaAGnhfIa+d79AxeOVFiPSWSnI0JlzidiHUT1FzafPuZroGzyLk9poqzNlisDrA8ZWTu85vzbzkTVhsAn9ip17hOB/Qvl3aWe4kzDI5oGxiH/AdyuFf4EHrsgrvIXioTmBJ//LBNkukq0yJZhwtLO4Dk2MsDnYC9cK28SDw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659855745; bh=bD4kFVhKZzFY9hvBZtRHJ8lv7sDW1fjRrrrgS2pZDKL=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=NbwygeXBuKoMuuZ3C8pYkAUV5NMD3apSkctWjljQmMWLxj/KYnxB2o4ZvqU73SyKz/aUoNhGdxBlBWZP6B62e1Vq/7zTkkjjsAh8qWHWdPgakovWi0oG657fzPcHiQEzM6SO8uUbo4mTADPG+4X7vNsTKZGFLRORM5WGIe25vHKOgCR3+TJPpT6tuujFGqviOACpS7GmqMk0H/++P3/bEK8mbnLPsQAoa6PCCuMpwdXEmXKOer1w6Y33t6E3X9+xmO80VcMmGZus0qq5ZS4k+93TfWZp/e09Tc/hEUbP2vJn4HEf3wjLrhrKCyDkyWWfCC/w8xH/Em2ZsO7yxnpXSQ== X-YMail-OSG: y9r05CsVM1kHD766u2D1d9_F99J5nwPH4kDGoLifvbdkxOYLJ4DTZGQsF_WVMAv u9IClyW.cKTJcbVf7cSz3o1UYswLB.Ti_HbY4KMTtwOnkY7EQ1zz9Zi_SqoyCcLIJW2abh4C5vus nNGuv5iawlqY_3t2AvyIt1khvH.DzJV_Mktk4HtaQWwJg4U.WrpuzpAZ9rrMXNBQ0rwmeR2Q0Pin mTUHLohNrD_tVydLHbtfvCJaDTm6oJIaYpLnXvisajAcVKpWBaMOf_jnzitMrXxmBpnlS2mdd.x9 ZK8wREl64TWM4oFNqovHZm.6Yce0U77S4nzmvAr67lscFkaCfQNUIKKMcK49CsOzZ1TjASb96Isq 8NIwL2hW8kPmB1i_ajXs4CB0LZ9CZ9B4_6CVpv23mqqeayzrYwBVuLnxDNhjO5u7zf.vQG7G.ABH n.bJQ1DCqRYqyf7bvtSelQPV5OMYwYIV.zavGNh4rU15GoSx_mkXbadQc0_47uwuyZ2YJ0XG.1OW yidzRaL2WGRMwMNcThmh_3r1.cpAI.PQtyc.cQJXRr_i9wo2_1akfzXkvFNm1GOhfdW_EzE3qtpa FHBEbKGckDywSxBe_AW0o_dnvwSnB_sUcVBkRt0fcpU4nkJeaHBEZMbLmJZRYnHBb0Hdpvg7Pc3u g7oh2m0_nNPbprXUiQuz7FoiyYb4RW6ywG45999am9NL252EgREhRg6LiaLVz_TzEMkrVxlqqA8e TI16wYjUgYhsk4rMIzabQ_Ouy_i7RmgOCdmvPjaft_x2kxd7Sq66V.WQMD6mhFwNmIhNWCkavVsX kOB8Q9zcKlzOM9fwObRBqf_A1HdOGaVnhz2iw7iEw4 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sun, 7 Aug 2022 07:02:25 +0000 Original-Received: by hermes--canary-production-sg3-6f58cd9b5-hxmk8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 619bb17f68edd967658a9e9ec1a2970a; Sun, 07 Aug 2022 07:02:18 +0000 (UTC) In-Reply-To: <5b4dda05-45cc-6843-c87f-047efda257df@dancol.org> (Daniel Colascione's message of "Sun, 7 Aug 2022 02:43:55 -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.187.148; envelope-from=luangruo@yahoo.com; helo=sonic316-22.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=unavailable 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:293183 Archived-At: Daniel Colascione writes: > None of those things is about working against policy implemented by > the system on behalf of the user. Your patch is explicitly about > making Emacs defy that policy. Is that how well-behaved X clients > should behave? Firstly, that's not true. Secondly, as a general rule, there are no well-behaved X clients in existence. Let's see what GTK does: /* Translate a timestamp of GDK_CURRENT_TIME appropriately */ if (timestamp == GDK_CURRENT_TIME) { #ifdef GDK_WINDOWING_X11 if (GDK_IS_X11_WINDOW(gdk_window)) { GdkDisplay *display; display = gtk_widget_get_display (widget); timestamp = gdk_x11_display_get_user_time (display); } else #endif timestamp = gtk_get_current_event_time (); [...] gdk_window_focus (gdk_window, timestamp); And Qt: updateNetWmUserTime(connection()->time()); [...] event.response_type = XCB_CLIENT_MESSAGE; event.format = 32; event.sequence = 0; event.window = m_window; event.type = atom(QXcbAtom::_NET_ACTIVE_WINDOW); event.data.data32[0] = 1; event.data.data32[1] = connection()->time(); event.data.data32[2] = focusWindow ? focusWindow->winId() : XCB_NONE; event.data.data32[3] = 0; event.data.data32[4] = 0; (where the connection time is updated by frame drawn events, so is in effect always very close to the server time regardless of how much interaction has happened.) Focus stealing prevention only works with naive clients and very old clients, along with newly mapped windows. > Window managers typically don't let you just raise frames > arbitrarily. What should the documentation of this function say? XRaiseWindow works here on GNOME Shell, kwin and mwm/dtwm, which is what I can easily test with. Please tell me where it doesn't work, and I will try to fix it. > XDestroyWindow? Windows can die at any time, yes? They can't, not through user interaction. Nobody defends against extremely unruly clients that kill toplevel windows at random, even though the fix is as simple as grabbing the server. > Although I suppose if someone raced XDestroyWindow against > XChangeProperty we'd either get the PropertyNotify or the xlib error > callback would fire, depending on who won the race. I *think* we can't > get into a situation in which we'd wait forever for the > PropertyNotify. I'll have to double check. A hang is possible but not something that can practically happen. You'd have to be a genius to time the XDestroyWindow right between the XChangeProperty and PropertyNotify. > It's not realistic to expect users to read any file in etc. When users > have a problem, they try again, then ask their friends, then search > the internet, and then give up and install VSCode. Like it or not, > that's the flow, and checked-in documentation won't help. Here's how VS Code (Chromium) implements activating a frame: x11::Time timestamp = X11EventSource::GetInstance()->GetTimestamp(); // override_redirect windows ignore _NET_ACTIVE_WINDOW. // https://crbug.com/940924 if (wm_supports_active_window && !override_redirect_) { std::array data = { // We're an app. 1, static_cast(timestamp), // TODO(thomasanderson): if another chrome window is active, specify // that here. The EWMH spec claims this may make the WM more likely to // service our _NET_ACTIVE_WINDOW request. 0, 0, 0, }; SendClientMessage(xwindow_, x_root_window_, x11::GetAtom("_NET_ACTIVE_WINDOW"), data); (also see https://codereview.chromium.org/2287583003/ for context) once again, the timestamp is automatically obtained from the X server (thus bypassing any focus stealing prevention) after a few optimizations aimed at reducing round-trips are made. > Then let's change the documentation: add a note to x-focus-frame > reminding callers that it's ultimately up to the window manager > whether a window is activated --- and it is. A WM is free to ignore > our activation requests even if we pretend to be a panel or a fire > truck or a cool bird or whatever. Why implement three separate ways of > working against that grain when we can do what the WM wants? That isn't what the documentation has said for more than 20 years, so this would in effect be an incompatible change.