1
SFML development / Window state
« on: February 01, 2018, 11:35:24 pm »
Hello everybody,
I was looking into a ticket that I have already been working on in the past. It is on maximing a window from code. Reading over the discussion again it seems to end with an already pretty good concept for an API. I though about it some more and I want to propose a design here. I'd like to hear your thoughts and if we can agree on it or develop it further I would like to start an implementation soon. Oh and a thing you guys are gonna like: we don't have to change the existing API, except for one deprecation
So I would suggest this:
So as you can see we have a seperation between state and style. Style is now only for the appearance/decoration of a window. The state of the window can now be described seperatly. An enum somewhere contains the possible window states. States are exclusive, so a window can only ever have one state. The create method will be extended by another parameter for the style, which can default to Windowed. The platform implementation of create will then open the window in the given state. There is also a getter and a setter in sf::Window. The setter will simply apply the state to the window. The getter will return the windows current state. Those are all the additions to the API. The Fullscreen window style would have to be deprecated in order to make a clear distinction between style and state.
This API would have two welcome side effects. You could finally switch to fullscreen mode and back (at least I have found it very annoying in the past that you always have to recreate the window for that, especially since things like the mouse visibility are not saved). Also it would allow creating a hidden/invisible window on creation by passing the minimized state to the create function.
So I would like to hear your thoughts on this
I was looking into a ticket that I have already been working on in the past. It is on maximing a window from code. Reading over the discussion again it seems to end with an already pretty good concept for an API. I though about it some more and I want to propose a design here. I'd like to hear your thoughts and if we can agree on it or develop it further I would like to start an implementation soon. Oh and a thing you guys are gonna like: we don't have to change the existing API, except for one deprecation
So I would suggest this:
enum State
{
Windowed,
Minimized,
Maximized,
Fullscreen
};
sf::Window::State state = sf::Window::State::Minimized;
window.create(videoMode, title, style, settings, state);
state = window.getState();
window.setState(state);
{
Windowed,
Minimized,
Maximized,
Fullscreen
};
sf::Window::State state = sf::Window::State::Minimized;
window.create(videoMode, title, style, settings, state);
state = window.getState();
window.setState(state);
So as you can see we have a seperation between state and style. Style is now only for the appearance/decoration of a window. The state of the window can now be described seperatly. An enum somewhere contains the possible window states. States are exclusive, so a window can only ever have one state. The create method will be extended by another parameter for the style, which can default to Windowed. The platform implementation of create will then open the window in the given state. There is also a getter and a setter in sf::Window. The setter will simply apply the state to the window. The getter will return the windows current state. Those are all the additions to the API. The Fullscreen window style would have to be deprecated in order to make a clear distinction between style and state.
This API would have two welcome side effects. You could finally switch to fullscreen mode and back (at least I have found it very annoying in the past that you always have to recreate the window for that, especially since things like the mouse visibility are not saved). Also it would allow creating a hidden/invisible window on creation by passing the minimized state to the create function.
So I would like to hear your thoughts on this