GNU bug report logs - #16028
24.3.50; Latest build completely breaks my thumnail frames code

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: 16028 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code
Date: Fri, 13 Dec 2013 11:12:39 +0100

> But if we somehow could provide Drew with the frame dimensions that
> _should_ have resulted from the two changes his code does, then he
> could add a call to set-frame-size to request precisely those
> dimensions, and that should fix his problem, no?

I'm not sure.  In principle Drew should be able to thumbify as follows:

(1) Save the current pixel sizess, font and scrollbar width.

(2) Set the new font size.

(3) Set the new scrollbar width.

(4) Set the new pixel sizes to some calculated from the ones saved in
    (1) and the scale factor used in (2).

To dethumbify he would have to

(5) Set the new font size to the one saved in (1).

(6) Set the new scrollbar width to the one saved in (1).

(7) Set the new frame pixel sizes to the ones saved in (1).

I don't know whether this correctly restores window start positions but
at least it seems the only sane way to fix his problem with the current
trunk.

We could obviously store the new pixel values and either let any size
changing functions use the new values or provide a Lisp interface to
them and let Drew use that value in his calculations.  Doing so would,
however, not eliminate the fact that the state of Emacs is inconsistent
while a resize operation is pending because the value returned by
`frame-pixel-height' is not in line with that of `frame-height'.  The
programmer would still have to be aware of this inconsistency and
explaining such a thing in the manual or a doc-string would be quite a
nuisance.  BTW, when creating a new frame, the inconsistency should be
observable on GNU/Linux as well.

I see only two ways to solve this inconsistency:

(1) Find some way to synch with the window manager as we do on
    GNU/Linux.

(2) Apply the size changes with the commented-out code.  The comment
    motivating why we should not do this on Windows because of the
    menubar wrapping issue doesn't make sense to me anyway: If we and
    Windows can handle wrapping, we'll do that when Windows gets back to
    us.  And the worst thing that could happen to us is that parts of
    the frame (including the modeline) might get obscured.  But this is
    something I plan to do anyway when shrinking a frame below the
    minimum size to accomodate all of its windows.

WDYT?

martin

Previous Next

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