GNU bug report logs - #46827
Broken initial size of GTK3 frame

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46827 <at> debbugs.gnu.org, rpluim <at> gmail.com, stephen.berman <at> gmx.net
Subject: bug#46827: Broken initial size of GTK3 frame
Date: Tue, 2 Mar 2021 17:07:16 +0100

[Message part 1 (text/plain, inline)]

> What's wrong with this place?

Actually, it's not needed.  I just have to call do_pending_window_change
_after_ updating the tool bar as in the attached patch.

> But please note that after calling
> do_pending_window_change you need to perform the "maybe the selected
> window changed" dance we do after other similar calls.

I suppose the

      do_pending_window_change could change the selected_window due to
      frame resizing which makes the selected window too small.

is some sort of cargo cult now.  While frame resizing can make the
selected window small, it will neither remove nor change it.

But since the menu and tool bar code _can_ change the selected window
we'll still have to cater for it.

> Otherwise, I'm okay with this change, but only on master.  Emacs 27.2
> will have to make do with what we have now.

Don't worry.  Even on master we could condition it on GTK3.  I'd just
want to find out why it works around the problem in the first place.

And I have a second, similar GTK3-only frame resizing problem with a
similar effect that, however, becomes virulent only after resizing a
frame manually with the mouse.

martin

[xdisp.c.diff (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.