-
-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add pygame.display.get/set_window_position() #2816
Add pygame.display.get/set_window_position() #2816
Conversation
return NULL; | ||
|
||
if (win) | ||
SDL_SetWindowPosition(win, x, y); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In SDL3, this will return something based on whether it was successful or not (SDL3 docs). @Starbuck5 @ankith26 @MyreMylar what do y'all think about this? Should there be some version checks built into new code that can support SDL3 more directly in the future, or should that be added in with other SDL3-compat stuff?
The same also applies to SDL_GetWindowPosition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should just put a comment here for now saying that this function will start raising errors, and deal with it during the porting
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Tested locally on windows 11, and it works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not strongly in favour or strongly against this PR, but I have left a few reviews for your consideration.
buildconfig/stubs/pygame/display.pyi
Outdated
@@ -82,6 +82,8 @@ def get_caption() -> Tuple[str, str]: ... | |||
def set_palette(palette: Sequence[ColorValue], /) -> None: ... | |||
def get_num_displays() -> int: ... | |||
def get_window_size() -> Tuple[int, int]: ... | |||
def get_window_pos() -> Tuple[int, int]:... | |||
def set_window_pos(pos: Sequence[int]) -> None:... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
def set_window_pos(pos: Sequence[int]) -> None:... | |
def set_window_pos(pos: Coordinate) -> None:... |
typing it as a Coordinate
is more generic and accurate
docs/reST/ref/display.rst
Outdated
This differs from updating environment variables as this function can be called after the display has been initialised. | ||
The position is expected to be relative to the topleft of the primary monitor. | ||
The y coordinate will ignore the window frame (y = 0 means the frame is hidden). | ||
The user will still be able to move the window after this call. See also :func:`pygame.display.get_window_pos()`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to have it noted here that there is a chance that this function can just fail on some platforms/configurations (example: direct wayland on linux)
So we shouldn't encourage users to rely on this function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw that the similar functions in window.c call the same SDL functions, doesn't that mean that they could also fail on those platforms/configurations?
Also when you say fail, what kind of exceptions are you talking about?
return NULL; | ||
|
||
if (win) | ||
SDL_SetWindowPosition(win, x, y); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should just put a comment here for now saying that this function will start raising errors, and deal with it during the porting
@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 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. |
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. |
buildconfig/stubs/pygame/display.pyi
Outdated
@@ -82,6 +82,8 @@ def get_caption() -> Tuple[str, str]: ... | |||
def set_palette(palette: Sequence[ColorValue], /) -> None: ... | |||
def get_num_displays() -> int: ... | |||
def get_window_size() -> Tuple[int, int]: ... | |||
def get_window_pos() -> Tuple[int, int]:... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why window_pos
instead window_position
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I wrote it I gave it that name because it was shorter but Window has the position attribute and not pos so it makes sense to have position. I'll edit this when I'm back in Italy in 14 hours
src_c/display.c
Outdated
|
||
if (pos != NULL) { | ||
if (!pg_TwoIntsFromObj(pos, &x, &y)) | ||
return RAISE(PyExc_TypeError, "pos must be two numbers"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please change this as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad I didn't see it thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still looks good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
I implemented what is said in the title of the pull request plus tests, stubs and documentation, I tested locally the functions.
Why?
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