Re: Deiconifying GTK frames on GNOME shell

[martin rudalics]

>>> [I thought I posted this workaround that I've been using at least since
>> ... when? ...
>
> a year at least (i have it in my October 2020 backup)

I wonder whether you had written it in response to some change in either
Emacs or GNOME.

> I've noticed the problem since march last year - the mutter-wayland folk
> i chatted with at that time disclaimed any notion of "iconify", saying
> hiding a window does not change the state

Remarkable.  We should and do get Expose events for such windows though.
But we lack UnmapNotify and VisibilityNotify events for them.  One major
problem is that they seem to care about Wayland only now.  Have you ever
tried the pgtk branch and how it behaves in this regard?

> and this is required for
> live-previews when switching workspaces, etc. though they claimed full
> support for ewmh NET_WM_STATE_HIDDEN

And IIUC we have troubles with that as well.  x_get_current_wm_state is
not reliable in my experience (or maybe we don't call it often enough).

> no, I couldn't figure out how to make raise-frame (select a different
> frame and set input focus) work on mutter-wayland with gtkonly emacs.

`raise-frame' calls Fmake_frame_visible.  Are advices not working when
called from C?  Anyhow, you should try to do those advices in C in the
first place - that's what I tried in the patch I sent to Dmitry and it
works for `raise-frame' here (but causes havoc under xfwm).

> gdk's calls do not work.

In general?  We do use them all the time.

> I think that's being punted, and relief is expected from some
> "xdg-activation protocol"

Has that been implemented already?  The pgtk branch should probably know
about it first.

> The mutter model means invisible frames are still supposed to keep
> rendering - they just wont be composited on the main workspace.

But how comes then that when users iconify a frame by clicking at the
title bar icon or when they switch workspaces they get problems when
deiconyfing a frame or switching workspace again.  All that time Emacs
should think of the frame as being exposed, visible, ...  Is that
x_get_current_wm_state striking again so Emacs _is_ somehow aware of the
frame not being really visible and waits for a signal that the frame has
become visible again?

Basically we can adopt a model where Emacs thinks all the time that a
frame is not visible and always asks to make it visible when it thinks
that the frame should be visible.  Just that `frame-list' could never
tell in such a model what the visible and invisible frames are ...

> [I try use it once in a while - try to get it to do what I want,
> encounter problems, give up for a month, etc.]

One evidence has become clear enough though: Our mutter clients don't
use multiple frames.

Thanks, martin