Add pygame.display.get/set_window_position()

[damusss]

I implemented what is said in the title of the pull request plus tests, stubs and documentation, I tested locally the functions.

Why?

• The window API should not have this feature restricted to it, without it seems incomplete
• The SDL code to achieve this is minimal so I see no reason to exclude this functionality
• The environment variable won't allow position changes after initialization and is nor pythonic nor clear
• The window API currently doesn't support OpenGL among the many features, so adding this feature to the display API is important
• Really, why not? It's not bloating nor complicating rather implementing existing and important functions provided by SDL

I'm very open to feedback and critics, I got inspired by the rest of display.c to write the implementation :)
Sorry for the double pull request, I messed up the previous branch, the current was forked directly from pygame-community/pygame-ce:main

[damusss]

Would re-running checks magically fix the Pypy exception (which was not raised by code edited by me)? I remember that happening with another pull request of mine. (how would I do that?)

[oddbookworm]

Would re-running checks magically fix the Pypy exception (which was not raised by code edited by me)? I remember that happening with another pull request of mine. (how would I do that?)

Potentially, a rerun would have worked. Sometimes the fails are intermittent and unrelated to the changes. A member can rerun (most) failed checks (I haven't figured out how to rerun circleci yet). You can force rerun all CI by closing and reopening the PR, but I don't like doing that if I don't have to

[oddbookworm]

LGTM! Tested locally on windows 11, and it works.

[ankith26]

I'm not strongly in favour or strongly against this PR, but I have left a few reviews for your consideration.

[damusss]

@ankith26 I know it makes no sense, but I could be against my pull request. I made it because I knew the display API was gonna stay and I didn't understand why it was missing those functions. But then we started talking quite a lot about the window module.

From what I understood, the window API will be THE way of making the window. The display module will only contain monitor/screen related functions, meaning that set_mode, get_window_size, get_surface (I might be missing something) will be deprecated and only available with the Window object.
Feel free to correct me if what I understood is not planned, but if it was, having get/set_window_pos added and then immediately deprecated doesn't feel like a good move.

I use this comment as an occasion to ask you what's the future of the display/window API. If display will always remain as an option to create a singleton window, then I'm strongly in favor of my pull request (who would have guessed) but otherwise, then we should finish the window API and deprecate display functions related to the window.

NOTE: I'm still gonna modify it like you suggested as it makes a lot of sense, but I think this are important considerations.

[ankith26]

I use this comment as an occasion to ask you what's the future of the display/window API. If display will always remain as an option to create a singleton window, then I'm strongly in favor of my pull request (who would have guessed) but otherwise, then we should finish the window API and deprecate display functions related to the window.

The display module will probably never be removed. Almost all pygame code written relies on it. What we will most likely do once the window API is finalized and published, is recommend users to write any new code in it. The old code that uses display will continue to work.

[damusss]

The display module will probably never be removed. Almost all pygame code written relies on it. What we will most likely do once the window API is finalized and published, is recommend users to write any new code in it. The old code that uses display will continue to work.

Thanks for the information.

[oddbookworm]

Still looks good

[MyreMylar]

OK, I don't mind this going in.

It doesn't really create more work for the eventual plan of Window supplanting display because Window already supports this functionality. I guess it slightly takes a little shine of Window for having features that display doesn't. But eh, that's not a great reason not to do it at the minute.

If display eventually becomes a python shim around the new Window module then this will only add a tiny bit more code to that shim.