x/exp/shiny: windows made on Windows(OS) have decreased height and width #19704
Comments
|
Yes we pass screen.NewWindowOptions Width and Height to Windows CreateWindowEx API as is. That will create window of that size. The inside part of the window is called "client area", if we are expected to create window with "client area" of screen.NewWindowOptions Width x Height, we would have to make window little bit bigger. Just googling I find http://stackoverflow.com/questions/4843806/winapi-create-a-window-with-a-specified-client-area-size or something of that sort. Leaving for @nigeltao to decide what to do here. Alex |
|
Yeah, I think that the 640 x 480 should specify the client area, not the window area. The shiny windriver (as opposed to the app code that calls shiny libraries) is responsible for adjusting. Having said that, in general, the width x height passed to NewWindow are only hints. Some window systems will ignore them, especially on mobile, so shiny apps shouldn't hard code layouts or expect that x = 630 will be visible even after asking for width = 640. |
|
@200sc please try https://go-review.googlesource.com/39111 . Does it fixes your problem? Alex |
|
CL https://golang.org/cl/39111 mentions this issue. |
|
It looks like it does, yes. Thanks! |
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:
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.
The text was updated successfully, but these errors were encountered: