-
Notifications
You must be signed in to change notification settings - Fork 18.8k
Description
What version of Go are you using (go version)?
go1.8
What operating system and processor architecture are you using (go env)?
windows/amd64
What did you do?
I called:
// s is of type screen.Screen
s.NewWindow(&screen.NewWindowOptions{640, 480, "title"})What did you expect to see?
I expected for a window to appear which was was 640 pixels wide and 480 tall.
What did you see instead?
Instead, a window with dimensions 624 x 441 appeared.
I know the size of the returned window because shiny sent us a size event of 624 x 441 after creation, and I confirmed it by attempting and failing to draw elements at x = 630.
This happens, as far as I can tell, because Windows does not want the actual width and height in terms of inside pixels of the end window in its window creation args, but rather the size the window will take up on screen, which includes borders that Windows puts on all of its windows, like the 39 pixel control bar on the top.
(It happens to be the case that the 16 pixels of width-buffer is not at all accurate for Windows 10, so while I haven't researched it I imagine that is some kind of legacy support)
We handle this in our application by just increasing the widths and heights passed in to new windows by 16 and 39 respectively, hoping these numbers are consistent for different Windows versions.
I'm not sure, however, what exactly shiny is trying to represent with its window size arguments. I assumed that shiny was representing the number of pixels of workable space its windows had, in which case I think shiny should handle this internally.
If that is not what shiny is trying to represent, a clarifying comment on NewWindowOptions that says the sizes are total-pixels-on-screen, including artifacts added by any particular OS, would be great.