Skip to content
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

Merged
merged 8 commits into from
May 25, 2024

Conversation

Damus666
Copy link
Contributor

@Damus666 Damus666 commented Apr 22, 2024

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

@Damus666 Damus666 requested a review from a team as a code owner April 22, 2024 19:59
src_c/display.c Outdated Show resolved Hide resolved
buildconfig/stubs/pygame/display.pyi Outdated Show resolved Hide resolved
return NULL;

if (win)
SDL_SetWindowPosition(win, x, y);
Copy link
Member

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

Copy link
Member

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

docs/reST/ref/display.rst Outdated Show resolved Hide resolved
@Damus666
Copy link
Contributor Author

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
Copy link
Member

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

docs/reST/ref/display.rst Outdated Show resolved Hide resolved
Copy link
Member

@oddbookworm oddbookworm left a 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.

@yunline yunline added New API This pull request may need extra debate as it adds a new class or function to pygame display pygame.display labels May 9, 2024
Copy link
Member

@ankith26 ankith26 left a 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.

@@ -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:...
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

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()`.
Copy link
Member

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.

Copy link
Contributor Author

@Damus666 Damus666 May 12, 2024

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);
Copy link
Member

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

@Damus666
Copy link
Contributor Author

@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
Copy link
Member

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.

@Damus666
Copy link
Contributor Author

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.

@@ -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]:...
Copy link
Member

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?

Copy link
Contributor Author

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

@Damus666 Damus666 changed the title Add pygame.display.get/set_window_pos() functions, tests, stubs and documentation Add pygame.display.get/set_window_position() May 18, 2024
src_c/display.c Outdated

if (pos != NULL) {
if (!pg_TwoIntsFromObj(pos, &x, &y))
return RAISE(PyExc_TypeError, "pos must be two numbers");
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

@oddbookworm oddbookworm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still looks good

Copy link
Member

@MyreMylar MyreMylar left a 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.

@oddbookworm oddbookworm added this to the 2.5.0 milestone May 25, 2024
@oddbookworm oddbookworm merged commit 582b639 into pygame-community:main May 25, 2024
39 checks passed
@Damus666 Damus666 deleted the display-getset-window-pos branch May 26, 2024 09:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
display pygame.display New API This pull request may need extra debate as it adds a new class or function to pygame
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants