MacOS: When initializing an openGL view with an existing window, call finishInit

[jkeller51]

See issue #1759 for a description of the problem.

For DPI-scaling reasons, I think it is the sf::RenderWindow's "business" if the scaling factor changes, so my change signs it up to receive the same notifications on the window as it would if it had created the window.

• Discussed in an issue
• Does the code follow the SFML Code Style Guide?
• Have you provided some example/test code for your changes?

---

Description

Please describe your pull request.

This PR is related to the issue #1759

Tasks

• Tested on macOS

How to test this PR?

See below

[jkeller51]

Code example:

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

#define USE_PARENT_WINDOW 0

int main() {
    
#if USE_PARENT_WINDOW
    sf::Window parentWindow(sf::VideoMode(600,400), "SFML Test");
    sf::RenderWindow window(parentWindow.getSystemHandle());
#else
    sf::RenderWindow window(sf::VideoMode(600,400), "SFML Test");
#endif
    
    while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
            switch(event.type) {
                case sf::Event::Closed:
                    window.close(); // will not get here when USE_PARENT_WINDOW==1
                    // *this is expected* because the parentWindow will (and should)
                    // receive this event and decide what to do with it, which in this
                    // case is nothing
                    break;
                case sf::Event::Resized:
                    std::cout << "Window resized to " << event.size.width << " x " <<
                        event.size.height << std::endl;
                    
                    break;
                default:
                    break;
            }
            window.clear(sf::Color::White);
            window.display();
        }
        
        
    }
    
    
    return 0;
}

Try flipping USE_PARENT_WINDOW and dragging the window between screens and the problem will become clear.

Using my change, the problem is solved.

[eXpl0it3r]

Comparing it to the original implementation, this seems mostly an oversight to me.

Thanks for catching it and creating a PR! 🙂

[eXpl0it3r]

Would be great, if you could retest this. The change makes sense, but in my personal tests I was still unable to close the window even with the fix applied.

[jkeller51]

You still won't be able to -- the window closing takes a different path. Clicking the close button calls the NSWindow's close methods, and the parentWindow in my example is the NSWindow which receives those function calls and decides how to respond. In this example, I have not handled events for the parentWindow so it will not close.

The resizing changes I am targeting are notifications that do not pay attention to hierarchy -- anybody can sign up to receive these notifications. Other notifications that will be fixed by this PR are related to focusing and unfocusing the window. We can probably find other solutions to address other window-specific events that will not be affected by this change like window closing, etc.

But it makes sense to me that parentWindow is responsible for handling window closing before anyone else. Technically when USE_PARENT_WINDOW=1 in my example, the sf::RenderTexture window is just an NSView inside of an NSWindow, so in that context it makes sense that it wouldn't handle window closing. But it might be useful for the sf::RenderWindow to still receive a notification just before the window closes. I would propose a separate issue for that though.

[eXpl0it3r]

Ohhh, I read the comment in the code wrong. 😄