Window state

[Hapax]

why would we make a special case for this one, and not for the others?

Because it already exists this way and would allow fully backwards compatibility with previous SFML 2 versions.

I think we should make things simple, clean and consistent.

Forcing a change from the simple fullscreen style to using multiple lines for a fullscreen window makes it become less simple.
Clean and consistent comes with either redesigning the interface (version 3) to allow the new stuff or not implementing the new stuff at all. Otherwise it costs simplicity as mentioned.

[Laurent]

Because it already exists this way and would allow fully backwards compatibility with previous SFML 2 versions.

I personally prefer to deprecate things if it allows us to keep the API clean. "X is done this way because of historical reasons" is always a bad argument when you explain something to your users.

Forcing a change from the simple fullscreen style to using multiple lines for a fullscreen window makes it become less simple.

This change just moves Fullscreen from being a fixed style to a changeable state. It's not "less simple", it's just different and more powerful.

Clean and consistent comes with either redesigning the interface (version 3) to allow the new stuff or not implementing the new stuff at all.

So you're completely against deprecation? Think about all these users complaining about SFML being stuck in endless discussions, this is not really what they want to hear

[Hapax]

Clean and consistent comes with either redesigning the interface (version 3) to allow the new stuff or not implementing the new stuff at all.

So you're completely against deprecation? Think about all these users complaining about SFML being stuck in endless discussions, this is not really what they want to hear

No, no, not at all. This this question of whether or not to stick to not breaking the interface or allowing it to break. Since SFML's stance seems to be firmly on not breaking, it would be better to not change something so drastic, requiring multiple lines to set up a full screen window, for example. If it did allow breaking (including breaking deprecation), the order of parameters could easily be changed to suit, for example.

Note that SFML's deprecation method means that it is still technically allowed so the implementation of fullscreen style would still have to be implemented anyway. This means that both methods need to be provided, which can be much less clean.


I'm not personally adverse to serious breaking changes, to be clear. I'm all for improvement and evolution and am always willing to update code to follow the most recent version. It's one of those points though, where if you allow this thing, do you allow some other thing, which situation is so often remarked upon.

[Laurent]

So what do you propose, actually? Is it just about not deprecating sf::Style::Fullscreen?

[Foaly]

I though we finally desided in that recent discussion, that we want to start moving forward with SFML again. And while keeping the API freeze in place use deprecation to implement new features. This would be such a case
I know it feels a little clunky to have 2 calls now to open a window in fullscreen instead of one. Thats why I originally proposed to have state as a parameter in the window constructor. Laurent argued against it, since the same can be accived with a initially hidden window that is then put into fullscreen state. The new API is also more powerful in the ragard, that you can make all the changes to a window, before showing it.


Sooo I uploaded a first implementation for MacOS. Not everything works, but it gives you an idea and can serve as a foundation for further discussions. You can find it in my feature/window_state branch.

So here are some implementation questions for MacOS. I haven't programmed a lot of Objective C (none actually ) so some questions might be easy to answer.

* when do I use self and when nil as parameters on NSWindow functions (both seem to work)?
* For the Hidden Style, calling orderOut directly after window creation doesn't hide the window. Actually on OSX right now it doesn't work if you do this:

sf::RenderWindow window(sf::VideoMode(800, 600), "Example");
window.setVisible(false);

From my test setVisible only starts working after the second run trough pollEvents.
I did look into what other librarys or people on the web did (there isn't much), but they all seem to be using orderOut.
* The fullscreen state is not implemented yet, as I'm not quiet sure of how to go best about it. It would probably need some refactoring of the init methods. I would need some input from mantognini on this.
* Also I get warning for the WindowImplDelegateProtocol methods not being implemented for SFViewController. From what I see the implementaion has to be dupicated, right? I am not sure what the design is here.


So yeah I mostly need mantognini input on the Mac version
I will try to start a windows implementation tonight.


edit: fixed one bug! also list and [ s ] together seems to be broken

[Hapax]

So what do you propose, actually? Is it just about not deprecating sf::Style::Fullscreen?

Adding the state to the constructor as originally suggested.

This is simpler overall; opening a fullscreen window with SFML is incredible simple at the moment. The (as Foaly put it) "clunky" code to create one with multiple lines may put off some more casual users or new users, which I imagine is not the intent.

[Mario]

Rather than hiding all windows initially (it's what I understood?), why not adding a `sf::Style::Hidden`, that basically works like a call `window.setVisible(false)`?

[Laurent]

Rather than hiding all windows initially

Nobody suggested that, as it would be a silent change in existing behaviour.

why not adding a `sf::Style::Hidden`, that basically works like a call `window.setVisible(false)`?

This is precisely what I suggest.

[Foaly]

Hello there!
I just pushed my windows implementation for the window state API. You can find it here.
From my tests it works quiet nice, but more testing and feedback would be great.
I have also encountered a really weird bug, which prohibits you from switching to fullscreen a second time, after you've switched back to windowed mode. The comparison on this line always fails, even if my debugger tells me state is State::Windowed. It is super weird and I can't figure it out, maybe somebody else knows more.

Here is he test code I have been using. Feel free to test and comment!

(click to show/hide)

#include <SFML/Graphics.hpp>
#include <iostream>

void printState(sf::Window& window)
{
    switch(window.getState())
    {
        case sf::State::Minimized:
            std::cout << "Minimized" << std::endl;
            break;
        case sf::State::Maximized:
            std::cout << "Maximized" << std::endl;
            break;
        case sf::State::Windowed:
            std::cout << "Windowed" << std::endl;
            break;
        case sf::State::Fullscreen:
            std::cout << "Fullscreen" << std::endl;
            break;
    }

}

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "Example", sf::Style::Default);

    bool isHidden = true;
    // run the program as long as the window is open
    while (window.isOpen())
    {
        // check all the windows events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // "close requested" event: we close the window
            if (event.type == sf::Event::Closed)
                window.close();

            else if (event.type == sf::Event::KeyReleased) {
                // close if escape key was pressed
                if (event.key.code == sf::Keyboard::Escape) {
                    window.close();
                }
                else if (event.key.code == sf::Keyboard::M) {
                    window.setState(sf::State::Minimized);
                    sf::sleep(sf::seconds(3));
                    printState(window);
                    window.setState(sf::State::Maximized);
                }
                else if (event.key.code == sf::Keyboard::N) {
                    window.setState(sf::State::Maximized);
                }
                else if (event.key.code == sf::Keyboard::W) {
                    window.setState(sf::State::Windowed);
                }
                else if (event.key.code == sf::Keyboard::F) {
                    window.setState(sf::State::Fullscreen);
                }
                else if (event.key.code == sf::Keyboard::H) {
                    isHidden = !isHidden;
                    window.setVisible(isHidden);
                }
                else if (event.key.code == sf::Keyboard::G) {
                    printState(window);
                }
            }
        }

        // clear the window to black
        window.clear();

        //window.draw();

        // display the windows content
        window.display();
    }
    return 0;
}
 

Also maybe some more people have an opinion on whether or not to have a state parameter in the constructor

[Foaly]

No comments ? Nobody tested?

[Sub]

There's a fairly strong chance that I'm an idiot, but I can't compile it.

Code: [Select]

/home/dan/Desktop/SFML-22fd13733499963d3e184fffbb004d26ba624de8/src/SFML/Window/Window.cpp: In member function ‘void sf::Window::setState(sf::State)’:
/home/dan/Desktop/SFML-22fd13733499963d3e184fffbb004d26ba624de8/src/SFML/Window/Window.cpp:379:22: error: ‘State’ is not a class or namespace
         if (state == State::Windowed)
                      ^
/home/dan/Desktop/SFML-22fd13733499963d3e184fffbb004d26ba624de8/src/SFML/Window/Window.cpp:385:22: error: ‘State’ is not a class or namespace
         if (state == State::Fullscreen)
                      ^
/home/dan/Desktop/SFML-22fd13733499963d3e184fffbb004d26ba624de8/src/SFML/Window/Window.cpp: In member function ‘sf::State sf::Window::getState() const’:
/home/dan/Desktop/SFML-22fd13733499963d3e184fffbb004d26ba624de8/src/SFML/Window/Window.cpp:404:42: error: ‘State’ is not a class or namespace
     return m_impl ? m_impl->getState() : State::Windowed;
                                          ^
src/SFML/Window/CMakeFiles/sfml-window.dir/build.make:374: recipe for target 'src/SFML/Window/CMakeFiles/sfml-window.dir/Window.cpp.o' failed
make[2]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/Window.cpp.o] Error 1
CMakeFiles/Makefile2:170: recipe for target 'src/SFML/Window/CMakeFiles/sfml-window.dir/all' failed
make[1]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....



[Foaly]

Huh thats weird... It seems like the compiler can't find State in Window.cpp eventough WindowState.hpp is included in Window.hpp...

What compiler/operating system + versions are you using?

As a fix you could try including WindowState.hpp in Window.cpp and see if it compiles.

Also than you for giving this a try! 

[Recoil]

Sorry to necro this post, and I know it is over a year old, but has there been any update to implementing minimize and maximize states?  My Google-fu has failed to find a working implementation of doing this programmatically.

I'm creating a borderless render window, and using a custom form that can be skinned (with a theme soon).  I can get the close button to work, and if this was a windows form I could go that route, but I am using .NET Core and this functionality does not exist.  I can clunkily maximize the render window, but there is no option to set the visibility = false and keep the icon in the taskbar for setting back to visibility = true.

[eXpl0it3r]

Going over the proposed API and discussion again, I was wondering, whether it would make sense to have a sf::State::Hidden?
That way we have two sets of window "modifiers": states and styles
Styles define what the window decorations look like (titlebar, buttons, borderless, etc.) and states define the state of the window (window, fullscreen, minized, maximized and hidden).
That would also mean, that in theory we could deprecate setVisible().

On the other hand, this would make adding sf::Style::Hidden so we can construct a window in a hidden state a bit of a confusing design, as you'd have hidden on style and state...
Maybe keeping setVisible for SFML 2 and creating windows hidden by default in SFML 3 would be a trade off here.

Either way, I've started to put together all the relevant points as a sort of "solution design" on the wiki. That should help bring together all the current discussion points, implementations and API checks, plus it can help as future reference.
https://github.com/SFML/SFML/wiki/SD%3A-States-and-Styles