Windows OS ::getDesktopMode() fix

[Hydra]

I've actually just realized. Nobody's tested this on Windows 10? Could it possibly be a issue that's unique to Windows 10?

I'm using Windows 10 Home, 64 bit, 10.0. 10240 Build 10240 with a:
Intel(R) Core(TM) i7-45 10U CPU @2.00GHz, 2601 Mhz
processor.

[Mario]

Check my last post. It's a visual thing caused by Windows 10's visual style. The actual borders are thicker than the visible border.

[Hydra]

Check my last post. It's a visual thing caused by Windows 10's visual style. The actual borders are thicker than the visible border.

So will this be changed? I'm guessing it would be pretty easy to check for the border size.

[Mario]

It's something I'd like to fix, but it's not as easy as just moving the window, since border sizes might be different on different systems. Read my suggestion in the other post.

[Laurent]

So basically, it is just that on Windows 10, the border is fully transparent. So it is correctly positioned at (0, 0) after all, and there's no bug. So... what else is there to be said?

[Mario]

Correct, from a technical standpoint everything is correct, although it looks weird.

[Hydra]

So basically, it is just that on Windows 10, the border is fully transparent. So it is correctly positioned at (0, 0) after all, and there's no bug. So... what else is there to be said?

There should at least be a warning in the documentation. Otherwise for beginners it looks like the window hasn't been positioned correctly.

[Hydra]

Correct, from a technical standpoint everything is correct, although it looks weird.

Technically no, because if you use getDesktopMode() then the window does not work correctly.

[Laurent]

There should at least be a warning in the documentation. Otherwise for beginners it looks like the window hasn't been positioned correctly.

A warning about what? "If your OS has transparent borders for some stupid reason, remember that they still exist and take some space"?

Technically no, because if you use getDesktopMode() then the window does not work correctly.

Since it's because of the transparent borders, this problem should not be tied to the desktop mode. Any window placed programmatically at (x, y) will appear at (x + 9, y).

[Mario]

The window has the correct size (the client area is as big as the desktop), it's just not aligned in a way to fill everything. Right now there's no direct way to retrieve the correct "maximized resolution" to create a full screen window that fills the screen while keeping the borders inside (in SFML).

When passing a VideoMode, you tell SFML to create a window that has that much drawing space. You don't set the outer size of the window (as you do in some GUI toolkits).

Windows 10 is out for a bit less than two weeks, expect quirks and odd things happening that aren't documented yet.

[Hydra]

There should at least be a warning in the documentation. Otherwise for beginners it looks like the window hasn't been positioned correctly.

A warning about what? "If your OS has transparent borders for some stupid reason, remember that they still exist and take some space"?

Technically no, because if you use getDesktopMode() then the window does not work correctly.

Since it's because of the transparent borders, this problem should not be tied to the desktop mode. Any window placed programmatically at (x, y) will appear at (x + 9, y).

No, a warning saying something like "For some reason Windows 10 has transparent borders so using ::setPosition(0, 0) will actually work like ::setPosition(9, 0)".

The thing is the window is positioned wrongly. It isn't positioned at 0, 0. It gets moved 9 pixels across on Windows 10. It's literally as simple as checking whether the host OS is Windows 10 and if so then minus 9 pixels on the x. Instead of confusing people and having wrong displays on other computers.

[Laurent]

The thing is the window is positioned wrongly. It isn't positioned at 0, 0. It gets moved 9 pixels across on Windows 10

The window is positioned correctly. The issue is purely visual; would the border not be 100% transparent, everybody would be happy. You just think it is offset by 9 pixels, but that's because you can't see the border. But it's definitely there.

It's literally as simple as checking whether the host OS is Windows 10 and if so then minus 9 pixels on the x. Instead of confusing people and having wrong displays on other computers.

That would be a quick and dirty "fix".
Can you be sure that Windows 10 will not change this in a future update? Can you be sure that users can't change this with an option? Can you be sure that users can't change this by applying a different theme?

I would even say that offsetting it by -9 pixels would be a bug, because the borders would become out of reach, and the user wouldn't be able to resize the window by the left side.

[Hydra]

No, you can still reach the borders and resize. Just for some reason you have an extra invisible bit you can use. Also it clearly doesn't change with themes because I have a theme installed and it doesn't change.

[Hapax]

This was the reason I asked you to try it with a style of "none".

It looks like, in true Microsoft style, Windows 10 is trying to be as backwards compatible as possible. This means that the actual position of the client part of the window is still in exactly the same place as it would be on older versions. To provide this compatibility while removing its frames, it's offsetting by the older frame size.
This is a Window 'feature' and isn't really an SFML problem.

[jamesL]

...
While the window borders shrunk to 1 pixel thickness in Windows 10, Microsoft kept the old "thick borders"  behind the scenes for easier resizing.

Here you can see it in action:



As you can see, from the top, the cursor changes as the cursor touches the actual window.

But from the left, the cursor changes quite a bit earlier. This invisible part of the border is what causes that "gap" when displaying the windowed full screen with borders.
...

just thought that was very interesting 

...Also it clearly doesn't change with themes because I have a theme installed and it doesn't change.

but just because it doesn't change with the theme you're using does that guarantee that it won't be affected by ANY theme ?

and I think his point still stands

what if MS decides to change border width on the next windows 10 update ?
or what if it makes the border visible ?