GNU bug report logs - #65217
29.1; set-frame-size gets confused and drops calls

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Ash <ext0l <at> catgirl.ai>, Eli Zaretskii <eliz <at> gnu.org>, 65217 <at> debbugs.gnu.org
Subject: Re: bug#65217: 29.1; set-frame-size gets confused and drops calls
Date: Mon, 21 Aug 2023 15:39:36 +0200

> It doesn't here.  Just in case, I tried a few different window
> managers (IceWM, Fluxbox, Window Maker, ...) and the result was the
> same: the scroll bar is displayed and hidden repeatedly, but the frame
> size doesn't change (except of course by the few pixels that are used
> to display the scroll bar).

Does that mean that my older recipe

(setq my/frame
      (make-frame `((left . 500)
                    (top . 5)
                    (width . 20)
                    (height . 20))))

(defun my/twiddle (width height)
  (set-frame-size my/frame 10 10)
  (set-frame-size my/frame width height)
  (sit-for 0)
  (message (format "%s %s" (frame-width my/frame) (frame-height my/frame))))

(my/twiddle 20 20)

works correctly with your setup?  In which case the GTK people might
have fixed this in the meantime (I'm still on GTK+ Version 3.24.5) and
the only problem is with child frames as in the OP.

> What would you suggest for this specific bug report?  The OP hasn't
> replied yet, so it's not yet know whether that advice solves their
> problem, but don't you agree that calling (redisplay t) after calling
> set-frame-size (and other similar functions) would in most cases help
> to have the frame "in sync" with the code?

I'd agree if (1) the patch I posted earlier doesn't help and (2) the
problem above with normal top-level frames has not been fixed.

martin

Previous Next

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