unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#53298: 29.0.50; GTK3 frame stops updating
@ 2022-01-16  6:43 Ross Vandegrift
  2022-01-16 11:06 ` martin rudalics
  0 siblings, 1 reply; 9+ messages in thread
From: Ross Vandegrift @ 2022-01-16  6:43 UTC (permalink / raw)
  To: 53298

Under the Enlightenmnet window manager 0.25, emacs w/GTK3 stops updating
after switching to a different virtual desktop and back.  It still
responds to keyboard input.  It can be restored by shading (aka rolling
up) or minimizing the window.

Further, minimizing the window will cause emacs to behave correctly
after future virtual desktop switches.  At least until another unshading
- at which point it stops updating again.

Enlightenment 0.25 began setting _NET_WM_STATE to _NET_WM_STATE_HIDDEN
when switching virtual desktops.  According to xprop, the value is
cleared after returning to the emacs desktop.

A Xaw build doesn't have this problem.  I've confirmed this with with
27.1 packages from debian bullseye and the current master branch.

To reproduce:
1. install enlightenment 0.25 and start an X session
2. configure at least two virtual desktops in Settings -> Screen ->
Virtual Desktops
3. install emacs using the GTK3 toolkit and start it
4. switch to another virtual desktop and back
5. focus the emacs frame, typing will not show up, but keyboard
shortcuts still work (C-x C-c is easy to verify with)
6. double click the window title bar twice to shade & unshade.  The
window should start updating again.

Thanks,
Ross


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2022-01-15 built on stgulik
Repository revision: c59e870cceb2f40040d6c02da7658c58054ab3ad
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --with-x=yes --with-x-toolkit=gtk3 --with-cairo
 --with-toolkit-scroll-bars --enable-libsystemd --without-gconf
 --with-mailutils --prefix=/usr/local/emacs/'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  global-flycheck-mode: t
  auto-insert-mode: t
  override-global-mode: t
  global-auto-revert-mode: t
  cl-old-struct-compat-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort flyspell mail-extr emacsbug message yank-media rmc dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums flycheck-yamllint init
trailing-whitespace-mode terraform-mode systemd edmacro kmacro server
rego-mode reformatter protobuf-mode cc-langs plantuml-mode ob-dot ox-odt
rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse
nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar ox-html table
ox-ascii ox-publish ox org-element avl-tree org-capture org-agenda
org-refile org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete pcomplete org-list
org-faces org-entities org-version ob-emacs-lisp ob-core ob-eval
org-table oc-basic bibtex iso8601 ol org-keys oc org-compat org-macs
org-loaddefs format-spec cal-menu calendar cal-loaddefs paragraph-tricks
nginx-mode meson-mode markdown-mode noutline outline logstash-conf
conf-mode js cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs ispell highlight-symbol
highlight-quoted highlight-parentheses highlight-numbers parent-mode
highlight-defined advice hcl-mode go-mode find-file ffap etags fileloop
generator xref project compile comint ansi-color ring gitlab-ci-mode
yaml-mode flycheck find-func dash dockerfile-mode s sh-script executable
css-mode smie sgml-mode facemenu imenu eww xdg url-queue thingatpt shr
pixel-fill kinsoku svg xml dom puny mm-url gnus nnheader gnus-util
text-property-search time-date mail-utils wid-edit mm-util mail-prsvr
color autoinsert cl-extra help-mode use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core finder-inf autorevert filenotify rx info
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars seq gv subr-x byte-opt bytecomp
byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 489361 16852)
 (symbols 48 32344 5)
 (strings 32 171428 5117)
 (string-bytes 1 4919003)
 (vectors 16 58333)
 (vector-slots 8 639678 18492)
 (floats 8 244 245)
 (intervals 56 514 95)
 (buffers 992 11))





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

* bug#53298: 29.0.50; GTK3 frame stops updating
  2022-01-16  6:43 bug#53298: 29.0.50; GTK3 frame stops updating Ross Vandegrift
@ 2022-01-16 11:06 ` martin rudalics
  2022-01-16 20:44   ` Ross Vandegrift
  0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2022-01-16 11:06 UTC (permalink / raw)
  To: Ross Vandegrift, 53298

 > Under the Enlightenmnet window manager 0.25, emacs w/GTK3 stops updating
 > after switching to a different virtual desktop and back.  It still
 > responds to keyboard input.  It can be restored by shading (aka rolling
 > up) or minimizing the window.
 >
 > Further, minimizing the window will cause emacs to behave correctly
 > after future virtual desktop switches.  At least until another unshading
 > - at which point it stops updating again.
 >
 > Enlightenment 0.25 began setting _NET_WM_STATE to _NET_WM_STATE_HIDDEN
 > when switching virtual desktops.  According to xprop, the value is
 > cleared after returning to the emacs desktop.
 >
 > A Xaw build doesn't have this problem.  I've confirmed this with with
 > 27.1 packages from debian bullseye and the current master branch.
 >
 > To reproduce:
 > 1. install enlightenment 0.25 and start an X session
 > 2. configure at least two virtual desktops in Settings -> Screen ->
 > Virtual Desktops
 > 3. install emacs using the GTK3 toolkit and start it
 > 4. switch to another virtual desktop and back
 > 5. focus the emacs frame, typing will not show up, but keyboard
 > shortcuts still work (C-x C-c is easy to verify with)
 > 6. double click the window title bar twice to shade & unshade.  The
 > window should start updating again.

Thanks for the report.  I suppose this is the problem described in
Bug#49955 28.0.50; Emacs got quasi freeze.  For some reasons, Masaru
Nomiya reported that bug as fixed but we never got a conclusive answer.

Also the problem he reported here

https://www.mail-archive.com/enlightenment-users@lists.sourceforge.net/msg26981.html

apparently had no conclusive outcome either.

Can you try commenting in the two lines

/** 	      SET_FRAME_VISIBLE (f, 1); **/
/** 	      SET_FRAME_ICONIFIED (f, false); **/

in xterm.c and tell whether that solves the problem.  If so, we could
add an option to set these in accordance with the window manager used.

Thanks, martin





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

* bug#53298: 29.0.50; GTK3 frame stops updating
  2022-01-16 11:06 ` martin rudalics
@ 2022-01-16 20:44   ` Ross Vandegrift
  2022-01-17  9:39     ` martin rudalics
  0 siblings, 1 reply; 9+ messages in thread
From: Ross Vandegrift @ 2022-01-16 20:44 UTC (permalink / raw)
  To: martin rudalics; +Cc: 53298

On Sun, Jan 16, 2022 at 12:06:12PM +0100, martin rudalics wrote:
> Thanks for the report.  I suppose this is the problem described in
> Bug#49955 28.0.50; Emacs got quasi freeze.  For some reasons, Masaru
> Nomiya reported that bug as fixed but we never got a conclusive answer.
> 
> Also the problem he reported here
> 
> https://www.mail-archive.com/enlightenment-users@lists.sourceforge.net/msg26981.html
> 
> apparently had no conclusive outcome either.
> 
> Can you try commenting in the two lines
> 
> /** 	      SET_FRAME_VISIBLE (f, 1); **/
> /** 	      SET_FRAME_ICONIFIED (f, false); **/
> 
> in xterm.c and tell whether that solves the problem.  If so, we could
> add an option to set these in accordance with the window manager used.

No, that didn't help.  Reverting 483c5e953c as suggested in #49955 does though.
I mucked with the revert a bit, the issue is skipping the the FocusIn handling
on GTK.

The minimal working revert is below.  Not sure if this is safe for the other
issue through.

Ross

diff --git a/src/xterm.c b/src/xterm.c
index 5798ea3eeb..752b6562bb 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -9574,16 +9574,10 @@ 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 deconizing a window (Bug42655). */
       f = any;
       if (f && FRAME_ICONIFIED_P (f))
        {
@@ -9593,7 +9587,6 @@ handle_one_xevent (struct x_display_info *dpyinfo,
           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;






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

* bug#53298: 29.0.50; GTK3 frame stops updating
  2022-01-16 20:44   ` Ross Vandegrift
@ 2022-01-17  9:39     ` martin rudalics
  2022-01-17 23:23       ` Ross Vandegrift
  0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2022-01-17  9:39 UTC (permalink / raw)
  To: Ross Vandegrift; +Cc: 53298

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

 > No, that didn't help.  Reverting 483c5e953c as suggested in #49955 does though.
 > I mucked with the revert a bit, the issue is skipping the the FocusIn handling
 > on GTK.
 >
 > The minimal working revert is below.  Not sure if this is safe for the other
 > issue through.

Thanks.  I attach a diff against Emacs 28 for this.  Can you try it?
You would have to set the variable 'x-set-frame-visibility-more-laxly'
to either 'focus-in' or 't' to see the effect.

Thanks, martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: x-set-frame-visibility-more-laxly.diff --]
[-- Type: text/x-patch; name="x-set-frame-visibility-more-laxly.diff", Size: 4946 bytes --]

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index eb685e5bfb..5271f3b4e9 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -1269,6 +1269,13 @@ and then Alt-F7).  A bug for it is here:
 https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/231034.
 Note that a permanent fix seems to be to disable "assistive technologies".

+*** Enlightenment: Frames not redrawn after switching virtual desktops
+
+With Enlightenment version 0.25, Emacs frames may no be redrawn orderly
+after switching back from another virtual desktop, see Bug#49955 and
+Bug#53298.  Setting the variable 'x-set-frame-visibility-more-laxly' to
+one of 'focus-in', 'expose' or 't' should fix this.
+
 *** Gnome: Emacs receives input directly from the keyboard, bypassing XIM.

 This seems to happen when gnome-settings-daemon version 2.12 or later
diff --git a/src/xterm.c b/src/xterm.c
index b55a54b945..b80d45f855 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8231,12 +8231,17 @@ handle_one_xevent (struct x_display_info *dpyinfo,
           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
-		 https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html.  */
-/** 	      SET_FRAME_VISIBLE (f, 1); **/
-/** 	      SET_FRAME_ICONIFIED (f, false); **/
+	      /* By default, do not set the frame's visibility here, see
+		 https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html.
+		 The default behavior can be overridden by setting
+		 'x-set-frame-visibility-more-laxly' (Bug#49955,
+		 Bug#53298).  */
+	      if (EQ (x_set_frame_visibility_more_laxly, Qexpose)
+		  || EQ (x_set_frame_visibility_more_laxly, Qt))
+		{
+		  SET_FRAME_VISIBLE (f, 1);
+		  SET_FRAME_ICONIFIED (f, false);
+		}

 	      if (FRAME_X_DOUBLE_BUFFERED_P (f))
                 font_drop_xrender_surfaces (f);
@@ -8824,26 +8829,33 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       goto OTHER;

     case FocusIn:
-#ifndef USE_GTK
+#ifdef 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
+         a MapNotify when unminimizing/deiconifying.  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
+	 But don't do that by default 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.  */
-      f = any;
-      if (f && FRAME_ICONIFIED_P (f))
-	{
-          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);
-        }
+	 That is fixed above but bites us here again.
+
+	 The option x_set_frame_visibility_more_laxly allows to override
+	 the default behavior (Bug#49955, Bug#53298).  */
+      if (EQ (x_set_frame_visibility_more_laxly, Qfocus_in)
+	  || EQ (x_set_frame_visibility_more_laxly, Qt))
 #endif /* USE_GTK */
+	{
+	  f = any;
+	  if (f && FRAME_ICONIFIED_P (f))
+	    {
+	      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);
+	    }
+	}

       x_detect_focus_change (dpyinfo, any, event, &inev.ie);
       goto OTHER;
@@ -13779,4 +13791,21 @@ syms_of_xterm (void)
 consuming frame position adjustments.  In newer versions of GTK, Emacs
 always uses gtk_window_move and ignores the value of this variable.  */);
   x_gtk_use_window_move = true;
+
+  DEFSYM (Qexpose, "expose");
+
+  DEFVAR_LISP ("x-set-frame-visibility-more-laxly",
+	       x_set_frame_visibility_more_laxly,
+    doc: /* Non-nil means set frame visibility more laxly.
+If this is nil, Emacs is more strict when marking a frame as visible.
+Since this may cause problems on some window managers, this variable can
+be also set as follows: The value `focus-in' means to mark a frame as
+visible also when a FocusIn event is received for it on GTK builds.  The
+value `expose' means to mark a frame as visible also when an Expose
+event is received for it on any X build.  The value `t' means to mark a
+frame as visible in either of these two cases.
+
+Note that any non-nil setting may cause invisible frames get erroneously
+reported as iconified.  */);
+  x_set_frame_visibility_more_laxly = Qnil;
 }

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

* bug#53298: 29.0.50; GTK3 frame stops updating
  2022-01-17  9:39     ` martin rudalics
@ 2022-01-17 23:23       ` Ross Vandegrift
  2022-01-18  7:29         ` martin rudalics
  0 siblings, 1 reply; 9+ messages in thread
From: Ross Vandegrift @ 2022-01-17 23:23 UTC (permalink / raw)
  To: martin rudalics; +Cc: 53298

On Mon, Jan 17, 2022 at 10:39:53AM +0100, martin rudalics wrote:
> > No, that didn't help.  Reverting 483c5e953c as suggested in #49955 does though.
> > I mucked with the revert a bit, the issue is skipping the the FocusIn handling
> > on GTK.
> >
> > The minimal working revert is below.  Not sure if this is safe for the other
> > issue through.
> 
> Thanks.  I attach a diff against Emacs 28 for this.  Can you try it?
> You would have to set the variable 'x-set-frame-visibility-more-laxly'
> to either 'focus-in' or 't' to see the effect.

Yep, this works.  Thanks!

Ross





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

* bug#53298: 29.0.50; GTK3 frame stops updating
  2022-01-17 23:23       ` Ross Vandegrift
@ 2022-01-18  7:29         ` martin rudalics
  2022-01-18 18:03           ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2022-01-18  7:29 UTC (permalink / raw)
  To: Ross Vandegrift; +Cc: 53298

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

 >> Thanks.  I attach a diff against Emacs 28 for this.  Can you try it?
 >> You would have to set the variable 'x-set-frame-visibility-more-laxly'
 >> to either 'focus-in' or 't' to see the effect.
 >
 > Yep, this works.  Thanks!

Eli, is this OK to install on the release branch?  It doesn't affect
default behavior but leaves us a fire escape for this and similar cases.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: x-set-frame-visibility-more-laxly.diff --]
[-- Type: text/x-patch; name="x-set-frame-visibility-more-laxly.diff", Size: 4946 bytes --]

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index eb685e5bfb..5271f3b4e9 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -1269,6 +1269,13 @@ and then Alt-F7).  A bug for it is here:
 https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/231034.
 Note that a permanent fix seems to be to disable "assistive technologies".

+*** Enlightenment: Frames not redrawn after switching virtual desktops
+
+With Enlightenment version 0.25, Emacs frames may no be redrawn orderly
+after switching back from another virtual desktop, see Bug#49955 and
+Bug#53298.  Setting the variable 'x-set-frame-visibility-more-laxly' to
+one of 'focus-in', 'expose' or 't' should fix this.
+
 *** Gnome: Emacs receives input directly from the keyboard, bypassing XIM.

 This seems to happen when gnome-settings-daemon version 2.12 or later
diff --git a/src/xterm.c b/src/xterm.c
index b55a54b945..b80d45f855 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8231,12 +8231,17 @@ handle_one_xevent (struct x_display_info *dpyinfo,
           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
-		 https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html.  */
-/** 	      SET_FRAME_VISIBLE (f, 1); **/
-/** 	      SET_FRAME_ICONIFIED (f, false); **/
+	      /* By default, do not set the frame's visibility here, see
+		 https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html.
+		 The default behavior can be overridden by setting
+		 'x-set-frame-visibility-more-laxly' (Bug#49955,
+		 Bug#53298).  */
+	      if (EQ (x_set_frame_visibility_more_laxly, Qexpose)
+		  || EQ (x_set_frame_visibility_more_laxly, Qt))
+		{
+		  SET_FRAME_VISIBLE (f, 1);
+		  SET_FRAME_ICONIFIED (f, false);
+		}

 	      if (FRAME_X_DOUBLE_BUFFERED_P (f))
                 font_drop_xrender_surfaces (f);
@@ -8824,26 +8829,33 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       goto OTHER;

     case FocusIn:
-#ifndef USE_GTK
+#ifdef 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
+         a MapNotify when unminimizing/deiconifying.  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
+	 But don't do that by default 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.  */
-      f = any;
-      if (f && FRAME_ICONIFIED_P (f))
-	{
-          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);
-        }
+	 That is fixed above but bites us here again.
+
+	 The option x_set_frame_visibility_more_laxly allows to override
+	 the default behavior (Bug#49955, Bug#53298).  */
+      if (EQ (x_set_frame_visibility_more_laxly, Qfocus_in)
+	  || EQ (x_set_frame_visibility_more_laxly, Qt))
 #endif /* USE_GTK */
+	{
+	  f = any;
+	  if (f && FRAME_ICONIFIED_P (f))
+	    {
+	      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);
+	    }
+	}

       x_detect_focus_change (dpyinfo, any, event, &inev.ie);
       goto OTHER;
@@ -13779,4 +13791,21 @@ syms_of_xterm (void)
 consuming frame position adjustments.  In newer versions of GTK, Emacs
 always uses gtk_window_move and ignores the value of this variable.  */);
   x_gtk_use_window_move = true;
+
+  DEFSYM (Qexpose, "expose");
+
+  DEFVAR_LISP ("x-set-frame-visibility-more-laxly",
+	       x_set_frame_visibility_more_laxly,
+    doc: /* Non-nil means set frame visibility more laxly.
+If this is nil, Emacs is more strict when marking a frame as visible.
+Since this may cause problems on some window managers, this variable can
+be also set as follows: The value `focus-in' means to mark a frame as
+visible also when a FocusIn event is received for it on GTK builds.  The
+value `expose' means to mark a frame as visible also when an Expose
+event is received for it on any X build.  The value `t' means to mark a
+frame as visible in either of these two cases.
+
+Note that any non-nil setting may cause invisible frames get erroneously
+reported as iconified.  */);
+  x_set_frame_visibility_more_laxly = Qnil;
 }

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

* bug#53298: 29.0.50; GTK3 frame stops updating
  2022-01-18  7:29         ` martin rudalics
@ 2022-01-18 18:03           ` Eli Zaretskii
  2022-01-20  9:49             ` martin rudalics
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2022-01-18 18:03 UTC (permalink / raw)
  To: martin rudalics; +Cc: ross, 53298

> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 18 Jan 2022 08:29:08 +0100
> Cc: 53298@debbugs.gnu.org
> 
> Eli, is this OK to install on the release branch?  It doesn't affect
> default behavior but leaves us a fire escape for this and similar cases.

Yes, but please remove the reference to bug numbers from the PROBLEMS
entry.  We don't point to bugs there because PROBLEMS is for users who
need a quick and efficient solution TL;DR style.  The reference to the
bugs in the comments to the code is enough.

Thanks.





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

* bug#53298: 29.0.50; GTK3 frame stops updating
  2022-01-18 18:03           ` Eli Zaretskii
@ 2022-01-20  9:49             ` martin rudalics
  2022-02-19 12:57               ` bug#53299: GTK3 frames stop updating Lars Ingebrigtsen
  0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2022-01-20  9:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: ross, 53298

 >> Eli, is this OK to install on the release branch?  It doesn't affect
 >> default behavior but leaves us a fire escape for this and similar cases.
 >
 > Yes, but please remove the reference to bug numbers from the PROBLEMS
 > entry.  We don't point to bugs there because PROBLEMS is for users who
 > need a quick and efficient solution TL;DR style.  The reference to the
 > bugs in the comments to the code is enough.

Done.

Ross, I pushed this to Emacs 28.  If you are using master only, you will
have to wait a day or two until the changes have been merged.  After
that please check again and tell us whether it works.

Thanks, martin





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

* bug#53299: GTK3 frames stop updating
  2022-01-20  9:49             ` martin rudalics
@ 2022-02-19 12:57               ` Lars Ingebrigtsen
  0 siblings, 0 replies; 9+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-19 12:57 UTC (permalink / raw)
  To: martin rudalics; +Cc: 53298, ross, 53299

martin rudalics <rudalics@gmx.at> writes:

> Ross, I pushed this to Emacs 28.  If you are using master only, you will
> have to wait a day or two until the changes have been merged.  After
> that please check again and tell us whether it works.

This was a month ago, but there was no response to this message, so I'm
assuming that Martin's change fixed this, and I'm closing this bug
report.  If it's still a problem in Emacs 28, please respond to the
debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





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

end of thread, other threads:[~2022-02-19 12:57 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-16  6:43 bug#53298: 29.0.50; GTK3 frame stops updating Ross Vandegrift
2022-01-16 11:06 ` martin rudalics
2022-01-16 20:44   ` Ross Vandegrift
2022-01-17  9:39     ` martin rudalics
2022-01-17 23:23       ` Ross Vandegrift
2022-01-18  7:29         ` martin rudalics
2022-01-18 18:03           ` Eli Zaretskii
2022-01-20  9:49             ` martin rudalics
2022-02-19 12:57               ` bug#53299: GTK3 frames stop updating Lars Ingebrigtsen

Code repositories for project(s) associated with this public 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 read-only IMAP folder(s) and NNTP newsgroup(s).