visible-frame-list (and PGTK)

visible-frame-list (and PGTK)

[Björn Bidar]

Hello,

Does `(visible-frame-list)` take the current virtual desktop into
account? If so does this also work when Emacs is build with PGTK?

For X11 Emacs can use EWMH to only show the frames visible on the
current virtual desktop either directly or through GDK.

I noticed that the GTK developer are no no about these kind
information, saying it shouldn't exist in Wayland [1].

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]

Br,

Björn


[1] https://gitlab.gnome.org/GNOME/gtk/-/issues/2506
[2] https://wayland.app/protocols/kde-plasma-virtual-desktop#org_kde_plasma_virtual_desktop_management:request:get_virtual_desktop
[3] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40
[4] https://man.archlinux.org/man/sway-ipc.7.en#3._GET_OUTPUTS

Re: visible-frame-list (and PGTK)

[Po Lu]

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

Re: visible-frame-list (and PGTK)

[Björn Bidar]

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.

Re: visible-frame-list (and PGTK)

[Po Lu]

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

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

This isn't necessary.  Window managers place frames situated within
non-current virtual desktops in the Iconic state by custom, and such
frames are accounted invisible by Emacs.

Unless i3 contravenes this established practice, such explicit
comparison is unnecessary and expensive.

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

My point is, not enjoying the patronage of those protocols' developers,
we are in no position to maintain up-to-date support for the many
versions that are undoubtedly present on our user's computers.

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

Please see above.