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: Stephen Berman <stephen.berman <at> gmx.net>, Robert Pluim <rpluim <at> gmail.com>
Cc: 46827 <at> debbugs.gnu.org
Subject: bug#46827: Broken initial size of GTK3 frame
Date: Tue, 2 Mar 2021 09:24:38 +0100

>> Interestingly, if I run the gtk build under xfwm4 without its dumpfile
>> present, I do sometimes see the frame issue you reported, which
>> suggests itʼs a timing issue somewhere.
>
> Evidence in favor of that suggestion may be the following observations:
> I can reliably reproduce the problematic display (on xfwm4-4.14.1 with
> GTK+ 3.24.17) with the first invocation below, but not with the second
> invocation:

Why is this evidence in favor of the above suggestion?

> $ emacs-master -Q --eval "(customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32)))"
>
> $ emacs-master -Q --eval "(progn (sleep-for .1) (customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32))))"
>
> Yet I can also reproduce the display problem with the following
> invocation:
>
> $ emacs-master -Q --eval "(progn (sit-for .1) (customize-set-variable 'default-frame-alist '((cursor-color . \"red3\") (width . 80) (height . 32))))"

Both `sleep-for' and `sit-for' with an abismal small argument work here,
0 does not.  So the problem still seems that redisplay misses a pending
window change.  I have no idea why `sleep-for' and `sit-for' behave
differently for you though.

martin

Previous Next

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