Why not set sf::Window style at runtime?

[sharethis]

When I create a new window, I can specify whether I'd like a title bar, is resizable, and so on. But I'd like to change that at runtime. This way, I could toggle between windowed mode and fullscreen mode just by removing the window frame and maximizing it. That would allow me to continue using all my OpenGL objects which would get destroyed when recreating the window. Doing this at runtime is possible on Windows and Linux. I don't know about Mac yet.

[CypherStone]

I'm not sure what the issue with closing the window and re-creating one has with your OpenGL objects as mine stay functional when I change to fullscreen and so on. But I can agree, having a style change function would make the code look considerably nicer our end. Internally it could do all of the destroying and recreation of the window or the Windows and Linux equivalent.

[Tank]

There have been some discussions about moving some of the window styles to separate functions, like maximize or fullscreen, because both are no styles, but states.

Should be somewhere at Github, I will try to find it later again, it's no fun at a mobile device.

[sharethis]

@CypherStone: Some OpenGL objects survive, but for example Framebuffer objects get destroyed. Additional, I recently introduced a bug by assuming that Query objects would stay valid after recreating the window.

@Tank: Thanks.

[Tank]

There we go, it was about minimizing in that specific case: https://github.com/SFML/SFML/issues/306

[eXpl0it3r]

In addition to what Tank said, it might be useful to know that some windowing implementations/APIs require the style when creating a window and I'm not sure if all the systems support functions to change the style on the fly. So if one API doesn't provide such functions, but requires a recreation of the window, then it's a better design to use what SFML uses at the moment.

But again, states such a maximized, minimized, fullscreen, etc. might change in the future, since they are more like states rather than styles.

[Tank]

No, I don't think that it's a better design. SFML's API should be designed to make sense, not to publicly reflect what internal dependencies (Win API, X11 etc) require.

Without checking, but there should be definitely ways to minimize and maximize a window without recreating it, as that sounds kinda insane.

If a window recreation is required, though, then it should be evaluated if that yields issues or can simply be done.

In general this should be transparent to the user, though.

[eXpl0it3r]

If a window recreation is required, though, then it should be evaluated if that yields issues or can simply be done.

In general this should be transparent to the user, though.

I just wonder if a recreation of a window as a "side effect" of calling a function is really something one wants to accept.

[Tank]

If it's the only option then one has to accept it or avoid changing the proper states. If window recreation itself doesn't have side effects, I personally couldn't care less.

[sharethis]

Do we have any plans to work on this?

[Ceylo]

To get a confirmation and to support this feature:

I'm in the case where the user can toggle the main window to be fullscreen or windowed. When doing so, I re-create the window and properties such as whether VSync is enabled or whether mouse cursor is hidden are lost. So when I want to switch to fullscreen, I have to re-set all the window properties. This is especially annoying considering that some of these properties cannot be "get" from the window object, so if it was modified externally (ie. by the user of your library) you can't do anything.

Am I missing some obvious easy way to handle the case?
If not, I guess not having to re-create the window to switch to fullscreen mode would solve my issue.

[binary1248]

This is especially annoying considering that some of these properties cannot be "get" from the window object, so if it was modified externally (ie. by the user of your library) you can't do anything.

I guess we all know what this means... We need more getters in sf::Window .

[StDH]

I vote for this =P