emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: visible-frame-list (and PGTK)


From: Po Lu
Subject: Re: visible-frame-list (and PGTK)
Date: Sat, 14 Oct 2023 19:24:30 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]