sf::WindowBase vs sf::Window vs sf::RenderWindow

[eXpl0it3r]

Currently we have three different window classes.

Originally, sf::Window was a basic window that creates an OpenGL context, but without SFML specific draw functionality. And sf::RenderWindow which does add those SFML specific draw functionalities.

Then much later sf::WindowBase was introduced as a window that doesn't have an OpenGL context and to retain the API compatibility for SFML 2.

With SFML 3 being in development, we're no longer bound to API compatibility and with a glimpse into a future, where we might have multiple rendering backends...

What API would you propose for the window setup if you were to start completely fresh?

[wintertime]

Nice that you finally start cleaning up the codebase for SFML3.

I think, there was too much mixed into the Window.
A cleaner API may be to have a Window, which only cares about the basic window settings and input.
Then have an abstract Context class providing a hopefully future-proof abstraction. The first derived class from this could then be the OpenGLContext. Later other APIs could have their own.
I'd hope it can be avoided and just the Context used, but if necessary make a Graphics class that is given a Context, which is used for everything that the SFML Graphics package additionally needs.

[barnack]

Nice to see the windows are being argued about.
Imo the biggest problem is that the library's modularity is lost with the windowing system.
While we can have SFML's windowing without SFML's drawing, we can't have SFML's drawing without SFML's windowing. That I think should be addressed for SFML 3.

There needs to be a way to let the users provide their own window and NOT override the user's (or third party library) underlying windowing system management.

I can't speak for other OSs as I'm focused on Windows; on Windows if the user passes his own HWND, SFML will replace the user's window procedure with its own.

Instead a more generalized drawing framework could give an interface to which the user can pass OS level events to the windows so SFML can handle the messages it needs to handle.

In short, if I use SFML's drawing on my own non-SFML windows, I want SFML to deal with resizing events but not everything else.

For example I do have a more generalized windowing framework here (https://github.com/Sephirothbahamut/CPP_Utilities_MS), that lets the user add his own "modules" to the window, so you can write a "direct2d", and "sfml" or an "opengl" module that handle swapchain related stuff but let other modules handle other things.

A valid option would be a window-specific rendertarget type with an "on resize" method that takes the new window size. The user window is expected to call that method with the resize event, may it be from a WndProc on window, a callback on glfw, or the size event from sfml's own window.

Same for any other event that a window render target may need, although to be honest the resize event is the only one I can think about right now.

[Thrasher]

Is it a given that we still need 3 window types for the three use cases currently covered by WindowBase, Window, and RenderWindow? If we drop one of those use cases then I can see ways to simplify things but if we still need to support all three then I'm not sure what improvements are viable.

[eXpl0it3r]

I think all three use cases still have value, which is why its been done in the first place.

• A window that is built for use with the full power of sfml-graphics
• A window that is provides an OpenGL context and doesn't require sfml-graphics, useful especially if you use modern OpenGL and can't create compatibility contexts to work with sfml-graphics
• A window that is just a shell without any graphics context, so one can build on top being OpenGL or Vulkan

I guess the main questions, I want to ask are:

• Do we see better names for these types?
• Is there a way to make sf::Window the empty shell and have OpenGL context creation as availalbe "addon" and allowing for Vulkan context or anything else being user defined, thus not requiring sf::WindowBase?