GNU bug report logs - #46963
28.0.50; Bad WM size hints in GTK-3 builds

Previous Next

To reply to this bug, email your comments to 46963 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: 28.0.50; Bad WM size hints in GTK-3 builds
Date: Sat, 6 Mar 2021 11:47:39 +0100

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

With emacs -Q use the mouse to drag the bottom edge of your frame up as
far as possible.  With GTK builds I see menu and tool bar and one line
of *scratch*, with a Lucid build only menu and tool bar remain visible.

Apparently, Emacs handles such resizing well but under the hood there is
one slightly devastating difference: The GTK3 build is not aware of the
last resizing steps.  Evaluating (frame-height) in the final one line
frame yields 4, so Emacs misses three lines.  In GTK2 and Lucid we get 3
but this is an Emacs internal issue.  If you do

(setq window-safe-min-height 0)

before dragging the border, you get 1 as expected.

You can visualize the difference better by evaluating

(setq frame-size-history '(100))

before dragging, evaluating

(frame--size-history)

when dragging finished and inspecting the buffer *frame-size-history*.
Here I get for a GTK2 build (only the lines with <= 144 pixels listed)

Frame size history of #<frame *scratch* - GNU Emacs at restno 0x190aac0>
xg-frame-resized	 (720 144 720 126) nil
adjust-frame-size-1	 (720 144 720 126) (change-frame-size 5)
adjust-frame-size-3	 (720 144 720 126) (752 144 752 126)
xg-frame-resized	 (720 126 720 108) nil
adjust-frame-size-1	 (720 126 720 108) (change-frame-size 5)
adjust-frame-size-3	 (720 126 720 108) (752 126 752 108)
xg-frame-resized	 (720 108 720 90) nil
adjust-frame-size-1	 (720 108 720 90) (change-frame-size 5)
adjust-frame-size-3	 (720 108 720 90) (752 108 752 90)
xg-frame-resized	 (720 90 720 72) nil
adjust-frame-size-1	 (720 90 720 72) (change-frame-size 5)
xg-frame-resized	 (720 90 720 54) nil
adjust-frame-size-1	 (720 90 720 54) (change-frame-size 5)
xg-frame-resized	 (720 90 720 36) nil
adjust-frame-size-1	 (720 90 720 36) (change-frame-size 5)
xg-frame-resized	 (720 90 720 18) nil
adjust-frame-size-1	 (720 90 720 18) (change-frame-size 5)

while for a GTK3 build I get

Frame size history of #<frame *scratch* - GNU Emacs at restno 0x2e5e6d0>
xg-frame-resized	 (720 144 720 126) nil
adjust-frame-size-1	 (720 144 720 126) (change-frame-size 5)
adjust-frame-size-3	 (720 144 720 126) (752 144 752 126)
xg-frame-resized	 (720 126 720 108) nil
adjust-frame-size-1	 (720 126 720 108) (change-frame-size 5)
adjust-frame-size-3	 (720 126 720 108) (752 126 752 108)
xg-frame-resized	 (720 108 720 90) nil
adjust-frame-size-1	 (720 108 720 90) (change-frame-size 5)
adjust-frame-size-3	 (720 108 720 90) (752 108 752 90)
xg-frame-resized	 (720 90 720 84) nil
adjust-frame-size-1	 (720 90 720 84) (change-frame-size 5)

As you can see, the initial parts of these traces are the same.  But
when it comes to shrink the frame below a height of 90 pixels, the GTK3
build goes to 84 pixels and stalls there while the GTK2 build continues
to receive sizes down to one line (18 pixels).  Yet in both cases the WM
window shrinks the same way down to one buffer line.

We could dismiss this issue as a bug nobody will care about because in
practice nobody will notice it.  But suppose we wanted to establish some
useful minimum frame size bounds like other applications (Thunderbird,
Firefox) do and pass them to the window manager.  This works fine for
all builds but the GTK3 one.  There, dragging the frame border ceases
again to report the last corresponding values and we get a frame looking
like in the attached shot (this is a split frame with two windows).

The culprit of the GTK3 behavior is Jan Djärv's fix for Bug#8919 which
overrides X11 functions with homemade ones.  Commenting out these
functions fixes the behavior here.  I'm not sure how to proceed though.

Reverting Jan's change might break Emacs for KDE users again although I
doubt it.  A configure option is no option for people who do not build
their Emacsen.  So a Lisp option is probably the only way to go which
means to copy the functions from SetNrmHint.c to emacsgtkfixed.c.  Or
maybe remove the emacsgtkfixed files altogether?  Any ideas?

martin

[GTK3-frame after dragging bottom border.png (image/png, attachment)]

Message #8 received at 46963 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46963 <at> debbugs.gnu.org
Subject: Re: bug#46963: 28.0.50; Bad WM size hints in GTK-3 builds
Date: Sat, 06 Mar 2021 13:04:37 +0200

> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sat, 6 Mar 2021 11:47:39 +0100
> 
> The culprit of the GTK3 behavior is Jan Djärv's fix for Bug#8919 which
> overrides X11 functions with homemade ones.  Commenting out these
> functions fixes the behavior here.  I'm not sure how to proceed though.
> 
> Reverting Jan's change might break Emacs for KDE users again although I
> doubt it.  A configure option is no option for people who do not build
> their Emacsen.  So a Lisp option is probably the only way to go which
> means to copy the functions from SetNrmHint.c to emacsgtkfixed.c.  Or
> maybe remove the emacsgtkfixed files altogether?  Any ideas?

When Jan made that change, did GTK3 already exist?  If not, then we
could avoid using that code for GTK3.

Alternatively, we could disallow making frames smaller than 4 lines,
because making our code jump through hoops for uses cases that are
supposed to be rare, to say the least, makes little sense to me.

Message #11 received at 46963 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46963 <at> debbugs.gnu.org
Subject: Re: bug#46963: 28.0.50; Bad WM size hints in GTK-3 builds
Date: Sat, 6 Mar 2021 20:29:02 +0100

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

> When Jan made that change, did GTK3 already exist?

Sure.

> If not, then we
> could avoid using that code for GTK3.

At the time he made the breaking change (June 2011) Jan remarked:

"This is so ugly, so maybe Emacs should remove Gtk3 support for this
release?"

Unfortunately he went on with the change and the chance to get rid of
GTK3 was lost forever.  BTW, I don't have the faintest idea how that
change works in the first place.

> Alternatively, we could disallow making frames smaller than 4 lines,
> because making our code jump through hoops for uses cases that are
> supposed to be rare, to say the least, makes little sense to me.

That's what I'm trying to do because you asked for such a solution.  It
cannot be a fixed number of lines like 4 because minibuffer-only or
ediff control frames want less.  OTOH four lines are not enough when
shrinking a frame with say four windows stacked above each other.

Rather, I calculate, from the number of vertically stacked windows, the
presence of scroll bars, mode, header and tab bar lines and a plethora
of other factors a minimal height of the frame and try to pass that to
the window manager.  But GTK3 intercepts me.

To make this visually more evident: I ask for a minimum height of 11
lines and that information apparently makes it through to the window
manager which stops shrinking the window at 11 lines as requested.
Somehow though GTK manages to swallow the last three ConfigureNotify
events in the way I described in my OP, thus making Emacs think that the
frame stopped shrinking at 14 lines.  Consequently, our frame resizing
mechanism does not try to shrink the normal windows and the minibuffer
gets cut off from view as can be seen in what I attach as 11_bad.

The expected correct behavior (and the one produced after defining out
the XSetWMNormalHints and XSetWMSizeHints redefinitions) is attached as
11_good.

martin

[11_bad.png (image/png, attachment)]

[11_good.png (image/png, attachment)]

Message #14 received at 46963 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46963 <at> debbugs.gnu.org
Subject: Re: bug#46963: 28.0.50; Bad WM size hints in GTK-3 builds
Date: Sat, 06 Mar 2021 22:13:32 +0200

> Cc: 46963 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sat, 6 Mar 2021 20:29:02 +0100
> 
>  > Alternatively, we could disallow making frames smaller than 4 lines,
>  > because making our code jump through hoops for uses cases that are
>  > supposed to be rare, to say the least, makes little sense to me.
> 
> That's what I'm trying to do because you asked for such a solution.  It
> cannot be a fixed number of lines like 4 because minibuffer-only or
> ediff control frames want less.  OTOH four lines are not enough when
> shrinking a frame with say four windows stacked above each other.
> 
> Rather, I calculate, from the number of vertically stacked windows, the
> presence of scroll bars, mode, header and tab bar lines and a plethora
> of other factors a minimal height of the frame and try to pass that to
> the window manager.  But GTK3 intercepts me.

Then perhaps we should document this oddity in PROBLEMS and forget
about it.

Message #17 received at 46963 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46963 <at> debbugs.gnu.org
Subject: Re: bug#46963: 28.0.50; Bad WM size hints in GTK-3 builds
Date: Mon, 8 Mar 2021 09:25:38 +0100

> Then perhaps we should document this oddity in PROBLEMS and forget
> about it.

Actually, providing a run-time option for this was trivial.  A PROBLEMS
entry is still needed.  More fun ahead implementing this on the Windows
API via MinTrackSize.

martin

Previous Next

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