From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Bj=C3=B6rn?= Bidar Newsgroups: gmane.emacs.devel Subject: Re: visible-frame-list (and PGTK) Date: Sat, 14 Oct 2023 22:22:10 +0300 Message-ID: <37615.5816296645$1697311397@news.gmane.org> References: <87h6mta1ld.fsf.ref@yahoo.com> <87h6mta1ld.fsf@yahoo.com> 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="34642"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 14 21:23:09 2023 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 1qrkE9-0008oc-68 for ged-emacs-devel@m.gmane-mx.org; Sat, 14 Oct 2023 21:23:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qrkDM-0006Xh-7P; Sat, 14 Oct 2023 15:22:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qrkDK-0006XR-AJ for emacs-devel@gnu.org; Sat, 14 Oct 2023 15:22:18 -0400 Original-Received: from thaodan.de ([185.216.177.71]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qrkDH-0006zs-HJ for emacs-devel@gnu.org; Sat, 14 Oct 2023 15:22:18 -0400 Original-Received: from odin (dsl-trebng12-50dc77-87.dhcp.inet.fi [80.220.119.87]) by thaodan.de (Postfix) with ESMTPSA id 1D405D08D70; Sat, 14 Oct 2023 22:22:11 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1697311331; bh=yeAWFrsbzhYFFDX+qABD2sMR+XUB16Lhx9XpR7G22u0=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=sFyJeYmY0zrxVYsbSX5J4wePYAsBqCDKoEbpVTWbh9odPQRhUdObTU9FqBi+MeHF8 3/p7Eu8I9a93Et6aSgaeuxBLV7a5dlPN00xy7wskyDAq32+nQe6EsjhlAlqainhd50 4/DmdVbA4GPgJIKXLj27a824udCTi0Pt64AXs3FUwQbnMHdySfgSyWcumIg730YSTS 57nAkgJECCd5VJk0ZfDyA1kXh8LyE6kUlGZ3qOXScBJ9YgxTFasjC4AzncgRW3W+t1 A3jNlzegYpW9Rn2PWaIN2y2HyzD7fZPk6BDJ3lmGZDFS1943JaQ8m4/tJk0BDwu1S5 XfvWYI1gfRXD2QGc16UUggjs/JO/03I9f22MPhYiiy1+vBEhfD/Pt5maaIly43oW8A mE4D9y3doKgaNVJ4aKuBJmmepJ/knpQketIIoLNu/AIzc4/vL38ppqz/8JbJJeEObk b7vW4O4Z2adlWURXKF8VMYWoTtESkFAIheYEV8qEe7mhxjLrPb2kWybkQU00bzBd2e TVlYwejWvJvG4XONNIoTD4YHhhC/nthvUpnsYKCesXeonetqKjSHDFA9rttQJ1xPAS k1Y7Mp6TXosetYpm4XRR1oaz3K0I74rpCPH5wP1k1f1VJP/NBdw4Nm6oGa2R/rlzNM KUIuDQPbpneRW57PjgLh0SXI= In-Reply-To: <87h6mta1ld.fsf@yahoo.com> (Po Lu's message of "Sat, 14 Oct 2023 19:24:30 +0800") Autocrypt: addr=bjorn.bidar@thaodan.de; prefer-encrypt=nopreference; keydata= mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlH Received-SPF: pass client-ip=185.216.177.71; envelope-from=bjorn.bidar@thaodan.de; helo=thaodan.de X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 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, INVALID_MSGID=0.568, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311453 Archived-At: Po Lu writes: > Bj=C3=B6rn Bidar writes: > >> Does `(visible-frame-list)` take the current virtual desktop into >> account? > > Under X, yes. there are various packages around that e.g. i3 mode that filter visible-frame list with i3 ipc to only get the frames from the current desktop, similar also ace-window uses such functionality by using visible-frame-list or x-window-parameters directly (comparing _NET_WM_DESKTOP with _NET_CURRENT_DESKTOP). The tried to find any reference that Emacs is doing something similar to vi= sible-frame-list by couldn't. >> If so does this also work when Emacs is build with PGTK? > > This doesn't function under Wayland, for the reasons you mentioned. > >> Would it make sense to adapt Wayland protocols that don't exist in GTK >> in this case? KDE has a protocol[2] for this and Wlroots is >> considering the same, >> Compositors such as Swap already having such functionality in their >> ipc.[3][4] > > I'm quite averse to this prospect, inasmuch as it amounts to shouldering > the heavy burden of maintaining up-to-date copies of each of these > protocols, one exceptionally pronounced under Wayland because they are > subject to incompatible changes or deletion without a moment's notice. > > Nowhere is this seen to worse advantage than in that GNU/Linux > distributions seldom provide headers for these extension protocols, > responsibility for which devolves upon their clients. No doubt with the > presumption (and upshot) being that these protocols are only employed by > a select few clients, to wit such toolkits as GTK, Qt and their ilk. For Qt/KDE the kde protocol extension version matches to the current version of frameworks, KDE sets the lowest minimum for each version. The distro's don't really change that. KDE and wlroots seem to work together on protocols, e.g. by wlroots basing on protocol on the other. > Seriously, open in your web browser: > > http://wayland.app/protocols/ > > Observe that among all these protocols, only those designated "core" or > "stable" accord clients some guarantee of stability. KDE and WLR > protocols are conspicuously absent from that list, and all bear a > surprising predilection to abrupt change and obsolescing. Furthermore, > they only service a subset of Wayland users. Is it because the KDE protocols don't contain that are stable or core don't have the KDE name any more? The website seems to filter protocols that are not standardized in to their sources e.g KDE or WLR. Doesn't mean that e.g. KDE doesn't implement WLR extensions or vice versa. As many things in the Linux world the GNOME people use their political power to block new protocols that don't fit their vision or push their own. My point being that Emacs doesn't agree with the Wayland restrictions set by GNOME if the PGTK when using GDK Wayland should match the features of the other ports. If those features are found in protocols defined by KDE and WLR and are also implemented in various compositors using either of them, then I think it makes sense to think about adapting these protocols. The easiest example I can think of is that Emacs uses server side (window) decorations, luckily in this case the KDE protocol as added to the wayland protocols as xdg-decoration. Even thou it's in XDG for a long time it's not implemented by the GNOME people. If more protocols which Emacs would like to make use of, even those in core, unstable or staging, are not implemented in GDK/GTK that could be an issue. The days that GTK was mostly vendor neutral are long gone IMHO. > Ultimately, Wayland users must come to terms with the restrictions > imposed by their choice of window system; it is not within our power to > assuage or otherwise mitigate them. I guess in this case Emacs is under the mercy of GTK to be cooperative. Maybe they will see the light of day when it comes to use cases that don't match their point of view of working.