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

[martin rudalics]

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

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

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

martin