From: martin rudalics <rudalics@gmx.at>
To: Ross Vandegrift <ross@kallisti.us>
Cc: 53298@debbugs.gnu.org
Subject: bug#53298: 29.0.50; GTK3 frame stops updating
Date: Tue, 18 Jan 2022 08:29:08 +0100 [thread overview]
Message-ID: <40e5420e-8de6-be61-28af-8ab9418a08ea@gmx.at> (raw)
In-Reply-To: <20220117232351.35nwooltmbj3cvhv@stgulik>
[-- 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;
}
next prev parent reply other threads:[~2022-01-18 7:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40e5420e-8de6-be61-28af-8ab9418a08ea@gmx.at \
--to=rudalics@gmx.at \
--cc=53298@debbugs.gnu.org \
--cc=ross@kallisti.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.