Win10 mode: shader windows aren't borderless

[ilonachan]

Exactly what the title says: when a background window is created with the win10 mode, it has a border. In a single-screen setup this wouldn't be visible, but on a multi-monitor setup this border overlaps onto other monitors (and above the other shadow windows running in parallel on those monitors). For some reason the (correctly set) GLFW hint DECORATED=FALSE isn't respected; however, setting it explicitly as a window attribute does work, and is my proposed fix.

[danielfvm]

I sadly don't have a multi-monitor setup so thank you for letting me know. Strange that the glfw hint isn't working, are you running this on Windows 10?

[ilonachan]

Yeah exactly, Windows 10. Is that a known issue?

[ilonachan]

As described in #34, I know why the hints don't do anything: they're set after the window is already created (in the super constructor). Once the window is created it isn't affected by changes in the hint system, and its attributes need to be explicitly set (which is what my fix did). I know this is how it works, because when I move the window_hint calls above the super call, it works as intended! I do however think that, since we already have an explicit window ID, setting attributes on that specific window is clearer than polluting some imaginary hint space (though that may be a matter of style).

EDIT: things are a little more complicated. If I don't set the hint before the window is created and positioned in the super constructor, then its layout apparently includes the decorations. If I change the decoration state after the window is already shown, that seems to cause a redraw/relayout, and the window is "correctly" positioned (except for the problem described in #34). But if I set the attribute between those two moments, there are ugly (suspiciously window-decoration-shaped) gaps around the edges of the shadow window. In other words: moving the hints up is the way to go, as it seems more reliable and less finicky.