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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16028 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#16028: 24.3.50;
 Latest build completely breaks my thumnail frames code
Date: Fri, 13 Dec 2013 12:51:05 +0200

> Date: Fri, 13 Dec 2013 11:12:39 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: drew.adams <at> oracle.com, 16028 <at> debbugs.gnu.org
> 
>  > 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.

I'd say we should try that.

> 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.

I don't see experts on board who would know how to do that.

> (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.

We could uncomment that code and see what trouble, if any, it causes.

Previous Next

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