unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Po Lu <luangruo@yahoo.com>
To: "Björn Bidar" <bjorn.bidar@thaodan.de>
Cc: emacs-devel@gnu.org
Subject: Re: visible-frame-list (and PGTK)
Date: Sat, 14 Oct 2023 19:24:30 +0800	[thread overview]
Message-ID: <87h6mta1ld.fsf@yahoo.com> (raw)
In-Reply-To: <87il79h4ex.fsf@> ("Björn Bidar"'s message of "Sat, 14 Oct 2023 13:41:42 +0300")

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Does `(visible-frame-list)` take the current virtual desktop into
> account?

Under X, yes.

> 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.

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.

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.  All things considered, being
incapable of listing visible frames in Emacs is no great calamity when
that capacity is also withheld from all other programs, who seem to fare
reasonably under such circumstances...



       reply	other threads:[~2023-10-14 11:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87h6mta1ld.fsf.ref@yahoo.com>
     [not found] ` <87il79h4ex.fsf@>
2023-10-14 11:24   ` Po Lu [this message]
2023-10-14 19:22     ` visible-frame-list (and PGTK) Björn Bidar
     [not found]     ` <87bkd12en1.fsf@>
2023-10-15  0:54       ` Po Lu
2023-10-14 10:41 Björn Bidar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h6mta1ld.fsf@yahoo.com \
    --to=luangruo@yahoo.com \
    --cc=bjorn.bidar@thaodan.de \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).