Re: Deiconifying GTK frames on GNOME shell

[Madhu]

* martin rudalics <366d9251-3609-9e0b-3d35-8af409af706a@gmx.at> :
Wrote on Fri, 10 Sep 2021 10:34:17 +0200:

>> [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)

>> - either on a bugreport or in a message to you - but I can't spot it in
>> my XMAIL]
>
> Have we been discussing this issue before?  Have you (or anyone else)
> filed a report against it?  No pointers anywhere?

Apparently not.

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 and this is required for
live-previews when switching workspaces, etc. though they claimed full
support for ewmh NET_WM_STATE_HIDDEN

>> (defadvice make-frame-visible (around mutter-workaround (&optional frame) 
>> activate)
>>    (if (or (eql (frame-parameter frame 'visibility) 'icon)
>>         (eql (frame-parameter frame 'visibility) nil))
>>        (set-frame-parameter frame 'visibility nil))
>>    ad-do-it)
>
> This works here for making the frame visible again.  It fails for
> `raise-frame' and `select-frame-set-input-focus' but I think it should
> be possible to fix these with similar advices too.

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.
gdk's calls do not work.

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

> I don't understand yet how this x_make_frame_visible_invisible stuff is
> supposed to work in the first place and I haven't even found the commit
> that introduced it yet.  Maybe it got fixed or broken during

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

> https://lists.gnu.org/r/emacs-devel/2018-03/msg00863.html
>
> so there should be also a timeout around somewhere.
>
> IIUC this could be a serious issue with frame switching on mutter so
> maybe either other people use a workaround like yours or they use a
> version of mutter where this problem doesn't happen.

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