GNU bug report logs -
#16028
24.3.50; Latest build completely breaks my thumnail frames code
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Mon, 2 Dec 2013 15:53:02 UTC
Severity: normal
Found in version 24.3.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #161 received at 16028 <at> debbugs.gnu.org (full text, mbox):
> 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
This bug report was last modified 11 years and 101 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.