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

[Drew Adams]

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