bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames co


From: Eli Zaretskii
Subject: 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@gmx.at>
> CC: drew.adams@oracle.com, 16028@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]