Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Window state  (Read 38005 times)

0 Members and 1 Guest are viewing this topic.

Hapax

  • Hero Member
  • *****
  • Posts: 3379
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Window state
« Reply #15 on: February 05, 2018, 12:34:38 am »
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.
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Window state
« Reply #16 on: February 05, 2018, 06:40:21 am »
Quote
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.

Quote
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.

Quote
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 ;D
Laurent Gomila - SFML developer

Hapax

  • Hero Member
  • *****
  • Posts: 3379
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Window state
« Reply #17 on: February 05, 2018, 05:27:11 pm »
Quote
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 ;D
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.
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Window state
« Reply #18 on: February 05, 2018, 08:32:32 pm »
So what do you propose, actually? Is it just about not deprecating sf::Style::Fullscreen?
Laurent Gomila - SFML developer

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Window state
« Reply #19 on: February 07, 2018, 07:44:58 pm »
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 :D ) 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
« Last Edit: February 08, 2018, 12:51:14 am by Foaly »

Hapax

  • Hero Member
  • *****
  • Posts: 3379
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Window state
« Reply #20 on: February 07, 2018, 09:03:49 pm »
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.
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

Mario

  • Moderator
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: Window state
« Reply #21 on: February 08, 2018, 09:19:15 am »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Window state
« Reply #22 on: February 08, 2018, 09:49:46 am »
Quote
Rather than hiding all windows initially
Nobody suggested that, as it would be a silent change in existing behaviour.

Quote
why not adding a `sf::Style::Hidden`, that basically works like a call `window.setVisible(false)`?
This is precisely what I suggest.
Laurent Gomila - SFML developer

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Window state
« Reply #23 on: February 11, 2018, 05:10:19 pm »
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)

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

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Window state
« Reply #24 on: February 15, 2018, 05:47:43 pm »
No comments :( ? Nobody tested?

Sub

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: Window state
« Reply #25 on: February 16, 2018, 08:36:48 pm »
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

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Window state
« Reply #26 on: February 21, 2018, 05:14:38 pm »
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

  • Jr. Member
  • **
  • Posts: 76
    • View Profile
Re: Window state
« Reply #27 on: July 20, 2019, 04:24:57 am »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11007
    • View Profile
    • development blog
    • Email
Re: Window state
« Reply #28 on: June 07, 2020, 08:16:47 pm »
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
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/