Re: visible-frame-list (and PGTK)

["Björn Bidar" <bjorn.bidar@thaodan.de>]

Po Lu <luangruo@yahoo.com> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> 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 visible-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.