unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Deiconifying GTK frames on GNOME shell
@ 2021-09-05  9:39 martin rudalics
  2021-09-05 10:26 ` Colin Baxter
  2021-09-05 19:19 ` Dmitry Gutov
  0 siblings, 2 replies; 14+ messages in thread
From: martin rudalics @ 2021-09-05  9:39 UTC (permalink / raw)
  To: emacs-devel

When running a GTK3 build of Emacs on GNOME shell, the following
sequence of actions

(setq frame (make-frame))
(iconify-frame frame)
(make-frame-visible frame)

does not produce a visible frame here.  Rather, the frame stays
iconified although (frame-visible-p frame) for it returns t.
(raise-frame frame) and (select-frame-set-input-focus frame) do not work
either.  A similar problem happens when running Emacs under the
Enlightenment WM.

I invite users running Emacs under GNOME shell to tell us whether they
see the same behavior or whether the above sequence of operations works
as intended.

This affects all frame management routines calling candidate_frame and
people who customized `frame-auto-hide-function' to `iconify-frame'.  In
particular, if you show the minibuffer in a separate frame, you cannot
raise that frame from Emacs once you have iconified it.

If we decide that this is a bug _we_ want to fix then I can offer the
following changes which seem to make things work here:

(1) In xterm.c swap the calls to

       gtk_widget_show_all (FRAME_GTK_OUTER_WIDGET (f));
       gtk_window_deiconify (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)));

(2) When trying to deiconify an iconified frame make it invisible first
     and only then make it visible.

I have no idea whether and how these changes might affect other builds
so making these customizable might be a good idea.  But first I'd like
to know whether we really care about this issue.  Since I use GNOME
shell for testing purposes only, I do not care personally.

Thanks in advance, martin



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-05  9:39 Deiconifying GTK frames on GNOME shell martin rudalics
@ 2021-09-05 10:26 ` Colin Baxter
  2021-09-06  8:31   ` martin rudalics
  2021-09-05 19:19 ` Dmitry Gutov
  1 sibling, 1 reply; 14+ messages in thread
From: Colin Baxter @ 2021-09-05 10:26 UTC (permalink / raw)
  To: martin rudalics; +Cc: , emacs-devel

>>>>> martin rudalics <rudalics@gmx.at> writes:

    > When running a GTK3 build of Emacs on GNOME shell, the following
    > sequence of actions

    > (setq frame (make-frame)) (iconify-frame frame)
    > (make-frame-visible frame)

    > does not produce a visible frame here.  Rather, the frame stays
    > iconified although (frame-visible-p frame) for it returns t.
    > (raise-frame frame) and (select-frame-set-input-focus frame) do
    > not work either.  A similar problem happens when running Emacs
    > under the Enlightenment WM.

    > I invite users running Emacs under GNOME shell to tell us whether
    > they see the same behavior or whether the above sequence of
    > operations works as intended.

For me, the sequence works as intended in openbox but not in either
gnome-session or gnome-session-classic.

Best wishes,



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-05  9:39 Deiconifying GTK frames on GNOME shell martin rudalics
  2021-09-05 10:26 ` Colin Baxter
@ 2021-09-05 19:19 ` Dmitry Gutov
  2021-09-06  8:32   ` martin rudalics
  1 sibling, 1 reply; 14+ messages in thread
From: Dmitry Gutov @ 2021-09-05 19:19 UTC (permalink / raw)
  To: martin rudalics, emacs-devel

On 05.09.2021 12:39, martin rudalics wrote:
> When running a GTK3 build of Emacs on GNOME shell, the following
> sequence of actions
> 
> (setq frame (make-frame))
> (iconify-frame frame)
> (make-frame-visible frame)
> 
> does not produce a visible frame here.  Rather, the frame stays
> iconified although (frame-visible-p frame) for it returns t.

Same here, except (frame-visible-p frame) returns 'icon.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-05 10:26 ` Colin Baxter
@ 2021-09-06  8:31   ` martin rudalics
  0 siblings, 0 replies; 14+ messages in thread
From: martin rudalics @ 2021-09-06  8:31 UTC (permalink / raw)
  To: Colin Baxter; +Cc: emacs-devel

 > For me, the sequence works as intended in openbox but not in either
 > gnome-session or gnome-session-classic.

Thanks for responding.  I conclude that the issue doesn't bother you.

martin



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-05 19:19 ` Dmitry Gutov
@ 2021-09-06  8:32   ` martin rudalics
  2021-09-07  0:45     ` Dmitry Gutov
  0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2021-09-06  8:32 UTC (permalink / raw)
  To: Dmitry Gutov, emacs-devel

 >> When running a GTK3 build of Emacs on GNOME shell, the following
 >> sequence of actions
 >>
 >> (setq frame (make-frame))
 >> (iconify-frame frame)
 >> (make-frame-visible frame)
 >>
 >> does not produce a visible frame here.  Rather, the frame stays
 >> iconified although (frame-visible-p frame) for it returns t.
 >
 > Same here, except (frame-visible-p frame) returns 'icon.

Even after doing (make-frame-visible frame)?

Just in case can you confirm that the earlier mentioned

(1) In xterm.c swap the calls to

       gtk_widget_show_all (FRAME_GTK_OUTER_WIDGET (f));
       gtk_window_deiconify (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)));

(2) When trying to deiconify an iconified frame make it invisible first
     and only then make it visible.

hack would work?

Thanks, martin



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-06  8:32   ` martin rudalics
@ 2021-09-07  0:45     ` Dmitry Gutov
  2021-09-07  8:16       ` martin rudalics
  2021-09-10  8:33       ` martin rudalics
  0 siblings, 2 replies; 14+ messages in thread
From: Dmitry Gutov @ 2021-09-07  0:45 UTC (permalink / raw)
  To: martin rudalics, emacs-devel

On 06.09.2021 11:32, martin rudalics wrote:
> Even after doing (make-frame-visible frame)?

Yup.

> Just in case can you confirm that the earlier mentioned
> 
> (1) In xterm.c swap the calls to
> 
>        gtk_widget_show_all (FRAME_GTK_OUTER_WIDGET (f));
>        gtk_window_deiconify (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)));
> 
> (2) When trying to deiconify an iconified frame make it invisible first
>      and only then make it visible.
> 
> hack would work?

Yes, that seems to work. Consistently.

If I don't do (1), BTW, I can do (2) twice, and that also makes the 
frame visible.

Meaning

   (make-frame-invisible frame)
   (make-frame-visible frame)
   (make-frame-invisible frame)
   (make-frame-visible frame)

If I do (1), then doing (2) only once is sufficient.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-07  0:45     ` Dmitry Gutov
@ 2021-09-07  8:16       ` martin rudalics
  2021-09-09 13:13         ` Madhu
  2021-09-10  8:33       ` martin rudalics
  1 sibling, 1 reply; 14+ messages in thread
From: martin rudalics @ 2021-09-07  8:16 UTC (permalink / raw)
  To: Dmitry Gutov, emacs-devel

 >> (1) In xterm.c swap the calls to
 >>
 >>        gtk_widget_show_all (FRAME_GTK_OUTER_WIDGET (f));
 >>        gtk_window_deiconify (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)));
 >>
 >> (2) When trying to deiconify an iconified frame make it invisible first
 >>      and only then make it visible.
 >>
 >> hack would work?
 >
 > Yes, that seems to work. Consistently.

Thanks for checking.

 > If I don't do (1), BTW, I can do (2) twice, and that also makes the frame visible.
 >
 > Meaning
 >
 >    (make-frame-invisible frame)
 >    (make-frame-visible frame)
 >    (make-frame-invisible frame)
 >    (make-frame-visible frame)
 >
 > If I do (1), then doing (2) only once is sufficient.

Interesting.  I will check when I switch to GNOME next time.

Many thanks, martin



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-07  8:16       ` martin rudalics
@ 2021-09-09 13:13         ` Madhu
  2021-09-10  8:34           ` martin rudalics
  0 siblings, 1 reply; 14+ messages in thread
From: Madhu @ 2021-09-09 13:13 UTC (permalink / raw)
  To: emacs-devel

* martin rudalics <635efeee-ffd5-28e3-d966-1086990b1aac@gmx.at> :
Wrote on Tue, 7 Sep 2021 10:16:02 +0200:

>>> (1) In xterm.c swap the calls to
>>>        gtk_widget_show_all (FRAME_GTK_OUTER_WIDGET (f));
>>>        gtk_window_deiconify (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)));
>>> (2) When trying to deiconify an iconified frame make it invisible first
>>>      and only then make it visible.
>>> hack would work?
>> Yes, that seems to work. Consistently.
> Thanks for checking.
>
>> If I don't do (1), BTW, I can do (2) twice, and that also makes the
>> frame visible.
>>    (make-frame-invisible frame)
>>    (make-frame-visible frame)
>>    (make-frame-invisible frame)
>>    (make-frame-visible frame)
>>
>> If I do (1), then doing (2) only once is sufficient.
>
> Interesting.  I will check when I switch to GNOME next time.

[I thought I posted this workaround that I've been using at least since
- either on a bugreport or in a message to you - but I can't spot it in
my XMAIL]

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-07  0:45     ` Dmitry Gutov
  2021-09-07  8:16       ` martin rudalics
@ 2021-09-10  8:33       ` martin rudalics
  2021-09-11 14:48         ` Dmitry Gutov
  1 sibling, 1 reply; 14+ messages in thread
From: martin rudalics @ 2021-09-10  8:33 UTC (permalink / raw)
  To: Dmitry Gutov, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

 > If I don't do (1), BTW, I can do (2) twice, and that also makes the frame visible.
 >
 > Meaning
 >
 >    (make-frame-invisible frame)
 >    (make-frame-visible frame)
 >    (make-frame-invisible frame)
 >    (make-frame-visible frame)

I attach a patch based on this recipe but it causes (occasionally
terrible) flickers on other desktops so I would have to special-case it
on mutter anyway.  I still have no good idea what's really going on
here.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: viv.diff --]
[-- Type: text/x-patch; name="viv.diff", Size: 5562 bytes --]

diff --git a/src/w32term.c b/src/w32term.c
index ad4d1a3282..a1b20236d8 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -6903,11 +6903,6 @@ w32_make_frame_invisible (struct frame *f)

   my_show_window (f, FRAME_W32_WINDOW (f), SW_HIDE);

-  /* We can't distinguish this from iconification
-     just by the event that we get from the server.
-     So we can't win using the usual strategy of letting
-     FRAME_SAMPLE_VISIBILITY set this.  So do it by hand,
-     and synchronize with the server to make sure we agree.  */
   SET_FRAME_VISIBLE (f, 0);
   SET_FRAME_ICONIFIED (f, false);

diff --git a/src/xdisp.c b/src/xdisp.c
index e853c8c223..66535109b2 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -15675,9 +15675,6 @@ redisplay_internal (void)
       FRAME_TTY (sf)->previous_frame = sf;
     }

-  /* Set the visible flags for all frames.  Do this before checking for
-     resized or garbaged frames; they want to know if their frames are
-     visible.  See the comment in frame.h for FRAME_SAMPLE_VISIBILITY.  */
   number_of_visible_frames = 0;

   FOR_EACH_FRAME (tail, frame)
diff --git a/src/xterm.c b/src/xterm.c
index 1887c3255d..0de6be762c 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8239,12 +8239,33 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       f = x_window_to_frame (dpyinfo, event->xexpose.window);
       if (f)
         {
+	  if (CONSP (frame_size_history))
+	    {
+	      frame_size_history_extra
+		(f,
+		 FRAME_VISIBLE_P (f)
+		 ? build_string ("Expose, visible")
+		 : build_string ("Expose, not visible"),
+		 FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f),
+		 -1, -1, event->xexpose.width, event->xexpose.height);
+	    }
+
           if (!FRAME_VISIBLE_P (f))
             {
               block_input ();
 	      /* The following two are commented out to avoid that a
 		 plain invisible frame gets reported as iconified.  That
-		 problem occurred first for Emacs 26 and is described in
+		 problem occurred first for Emacs 26 with GTK3 and is
+		 the result of the following actions:
+
+		 (1) x_make_frame_invisible sets f->visible to 0.
+
+		 (2) We get an (unexpected) Expose event for f and here
+		     set f->visible to 1.
+
+		 (3) The subsequent UnmapNotify event finds f->visible
+		     is 1 and sets f->iconified true.
+
 		 https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html.  */
 /** 	      SET_FRAME_VISIBLE (f, 1); **/
 /** 	      SET_FRAME_ICONIFIED (f, false); **/
@@ -8835,26 +8856,24 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       goto OTHER;

     case FocusIn:
-#ifndef USE_GTK
       /* Some WMs (e.g. Mutter in Gnome Shell), don't unmap
          minimized/iconified windows; thus, for those WMs we won't get
          a MapNotify when unminimizing/deconifying.  Check here if we
-         are deiconizing a window (Bug42655).
-
-	 But don't do that on GTK since it may cause a plain invisible
-	 frame get reported as iconified, compare
-	 https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html.
-	 That is fixed above but bites us here again.  */
+         are deiconifying a window (Bug42655).  */
       f = any;
+      /* Should we handle invisible frames here too?  */
       if (f && FRAME_ICONIFIED_P (f))
 	{
+	  if (CONSP (frame_size_history))
+	    frame_size_history_plain
+	      (f, build_string ("FocusIn, was iconified"));
+
           SET_FRAME_VISIBLE (f, 1);
           SET_FRAME_ICONIFIED (f, false);
           f->output_data.x->has_been_visible = true;
           inev.ie.kind = DEICONIFY_EVENT;
           XSETFRAME (inev.ie.frame_or_window, f);
         }
-#endif /* USE_GTK */

       x_detect_focus_change (dpyinfo, any, event, &inev.ie);
       goto OTHER;
@@ -9344,9 +9363,24 @@ handle_one_xevent (struct x_display_info *dpyinfo,

     case VisibilityNotify:
       f = x_top_window_to_frame (dpyinfo, event->xvisibility.window);
-      if (f && (event->xvisibility.state == VisibilityUnobscured
-		|| event->xvisibility.state == VisibilityPartiallyObscured))
-	SET_FRAME_VISIBLE (f, 1);
+      if (f)
+	{
+	  if (event->xvisibility.state == VisibilityUnobscured
+	      || event->xvisibility.state == VisibilityPartiallyObscured)
+	    {
+	      if (CONSP (frame_size_history))
+		frame_size_history_plain
+		  (f, build_string ("VisibilityNotify, visible"));
+
+	      SET_FRAME_VISIBLE (f, 1);
+	    }
+	  else
+	    {
+	      if (CONSP (frame_size_history))
+		frame_size_history_plain
+		  (f, build_string ("VisibilityNotify, invisible"));
+	    }
+	}

       goto OTHER;

@@ -11918,11 +11952,6 @@ x_make_frame_invisible (struct frame *f)

   x_sync (f);

-  /* We can't distinguish this from iconification
-     just by the event that we get from the server.
-     So we can't win using the usual strategy of letting
-     FRAME_SAMPLE_VISIBILITY set this.  So do it by hand,
-     and synchronize with the server to make sure we agree.  */
   SET_FRAME_VISIBLE (f, 0);
   SET_FRAME_ICONIFIED (f, false);

@@ -11937,7 +11966,18 @@ x_make_frame_invisible (struct frame *f)
 x_make_frame_visible_invisible (struct frame *f, bool visible)
 {
   if (visible)
+#if defined (USE_GTK)
+    if (FRAME_ICONIFIED_P (f))
+      {
+	x_make_frame_visible (f);
+	x_make_frame_invisible (f);
+	x_make_frame_visible (f);
+      }
+  else
     x_make_frame_visible (f);
+#else
+  x_make_frame_visible (f);
+#endif
   else
     x_make_frame_invisible (f);
 }

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-09 13:13         ` Madhu
@ 2021-09-10  8:34           ` martin rudalics
  2021-09-10 12:04             ` Madhu
  0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2021-09-10  8:34 UTC (permalink / raw)
  To: Madhu, emacs-devel

 > [I thought I posted this workaround that I've been using at least since

... when? ...

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

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

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

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.

martin



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-10  8:34           ` martin rudalics
@ 2021-09-10 12:04             ` Madhu
  2021-09-11  8:38               ` martin rudalics
  0 siblings, 1 reply; 14+ messages in thread
From: Madhu @ 2021-09-10 12:04 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-10 12:04             ` Madhu
@ 2021-09-11  8:38               ` martin rudalics
  0 siblings, 0 replies; 14+ messages in thread
From: martin rudalics @ 2021-09-11  8:38 UTC (permalink / raw)
  To: Madhu, emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-10  8:33       ` martin rudalics
@ 2021-09-11 14:48         ` Dmitry Gutov
  2021-09-11 16:43           ` martin rudalics
  0 siblings, 1 reply; 14+ messages in thread
From: Dmitry Gutov @ 2021-09-11 14:48 UTC (permalink / raw)
  To: martin rudalics, emacs-devel

On 10.09.2021 11:33, martin rudalics wrote:
>  > If I don't do (1), BTW, I can do (2) twice, and that also makes the 
> frame visible.
>  >
>  > Meaning
>  >
>  >    (make-frame-invisible frame)
>  >    (make-frame-visible frame)
>  >    (make-frame-invisible frame)
>  >    (make-frame-visible frame)
> 
> I attach a patch based on this recipe but it causes (occasionally
> terrible) flickers on other desktops so I would have to special-case it
> on mutter anyway.  I still have no good idea what's really going on
> here.

The patch seems to work, fixing the scenario above. Thanks.

Not sure at which step the flickers are supposed to appear - probably in 
some more complex scenarios?

Perhaps related to the topic of the discussion: I very rarely use 
multiple frames myself (child frames excepted), but I'm happy to help 
troubleshoot bugs under GNOME anyway.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Deiconifying GTK frames on GNOME shell
  2021-09-11 14:48         ` Dmitry Gutov
@ 2021-09-11 16:43           ` martin rudalics
  0 siblings, 0 replies; 14+ messages in thread
From: martin rudalics @ 2021-09-11 16:43 UTC (permalink / raw)
  To: Dmitry Gutov, emacs-devel

 > Not sure at which step the flickers are supposed to appear - probably in some more complex scenarios?

They occur with xfwm and, in a less annoying way, with plasma.  I
haven't seen them with mutter.

 > Perhaps related to the topic of the discussion: I very rarely use
 > multiple frames myself (child frames excepted), but I'm happy to help
 > troubleshoot bugs under GNOME anyway.

Thanks.  Users that should be bitten most by this are those using
`frame-auto-hide-function'.

martin



^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-09-11 16:43 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-05  9:39 Deiconifying GTK frames on GNOME shell martin rudalics
2021-09-05 10:26 ` Colin Baxter
2021-09-06  8:31   ` martin rudalics
2021-09-05 19:19 ` Dmitry Gutov
2021-09-06  8:32   ` martin rudalics
2021-09-07  0:45     ` Dmitry Gutov
2021-09-07  8:16       ` martin rudalics
2021-09-09 13:13         ` Madhu
2021-09-10  8:34           ` martin rudalics
2021-09-10 12:04             ` Madhu
2021-09-11  8:38               ` martin rudalics
2021-09-10  8:33       ` martin rudalics
2021-09-11 14:48         ` Dmitry Gutov
2021-09-11 16:43           ` martin rudalics

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).