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: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 16028 <at> debbugs.gnu.org
Subject: bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code
Date: Thu, 12 Dec 2013 11:55:19 -0800 (PST)

>  > Why should asking to change the scroll-bar width constitute a
>  > request to also change the pixel size of the frame?
> 
> Because that's what x_set_scroll_bar_width in frame.c does.
> Unfortunately so, IMHO.

Well, I don't understand, but maybe I do not need to.  Is that something
new?  The regression is new.  If the C code has always done that, it has
not been problematic for thumbnail frames before now.

>  > Or did you mean only that
>  > changing the scroll-bar width will change the frame width slightly?
>  > The latter I could probably live with.
> 
> When x_set_scroll_bar_width asks to change the frame size, it has to
> provide the new size in some way.  In your particular case, it uses that
> of _before_ the font change since Windows did not propagate the new
> values back to us.
> 
>  >> Now before my changes, (2) asked the window manager to change the pixel
>  >> size of the frame based on its line/column sizes multiplied by the
>  >> default font sizes.  After my changes, (2) asks to change the pixel size
>  >> of the frame directly from the previously calculated pixel sizes.
>  >> However, since on Windows (1) does not record the change of the pixel
>  >> size caused by setting the font size, the request in (2) will be based
>  >> on the pixel size of the frame before (1) was issued.
>  >
>  > Good to understand.  Thx.  Not sure what that means in terms of trying
>  > to get my code to work properly with your new code (as well as with
>  > prior Emacs code).  Concrete suggestions welcome.
> 
> I'm afraid there's not much you can do here.

You mean the only solution is to stop using Emacs 24 after 24.3?

>  >> I don't know how to fix this properly.  IIUC Emacs cannot wait until
>  >> Windows passes the new sizes back to it in (1) just as it does on other
>  >> systems.  The sit-for I proposed earlier could work around this.  If
>  >> OTOH I restore the calculation for (2) to use the line/column values,
>  >> people who want to change the scrollbar width exactly by pixels are
>  >> lost.
>  >
>  > Are they necessarily lost, or is there some other way to accommodate
>  > both?
>  >
>  > BTW, as far as you can tell, is it just the scroll bar that is the
>  > problem (wrt my code)?
> 
> Hopefully, scrollbars on Windows are the only problem for you.

Well at least that is good news.  As a workaround, then, I could presumably
turn off the scroll bar on thumbnail frames.  That would be a fairly large
loss of functionality, but at least it would make (de)thumbifying possible
again.

Previous Next

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