From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 46963@debbugs.gnu.org
Subject: bug#46963: 28.0.50; Bad WM size hints in GTK-3 builds
Date: Sat, 6 Mar 2021 20:29:02 +0100 [thread overview]
Message-ID: <a517ad67-9acc-8ee7-2340-0b8debf15a52@gmx.at> (raw)
In-Reply-To: <83h7lownju.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]
> 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
[-- Attachment #2: 11_bad.png --]
[-- Type: image/png, Size: 42924 bytes --]
[-- Attachment #3: 11_good.png --]
[-- Type: image/png, Size: 50117 bytes --]
next prev parent reply other threads:[~2021-03-06 19:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-06 10:47 bug#46963: 28.0.50; Bad WM size hints in GTK-3 builds martin rudalics
2021-03-06 11:04 ` Eli Zaretskii
2021-03-06 19:29 ` martin rudalics [this message]
2021-03-06 20:13 ` Eli Zaretskii
2021-03-08 8:25 ` martin rudalics
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=a517ad67-9acc-8ee7-2340-0b8debf15a52@gmx.at \
--to=rudalics@gmx.at \
--cc=46963@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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.