Add `Window.wm_info`

[damusss]

Window manager information and especially the window handle were only accessible to the display module. I feel like you should know the window handle of any window, so I added the property. The return value almost perfectly mimics the display one, but it can change of course since this would be new api.

MRE:

import pygame

D = False
if D:
    screen = pygame.display.set_mode((300, 300))
else:
    win = pygame.Window("test", (300, 300))
    win2 = pygame.Window("tes2", (150, 150))

while True:
    for e in pygame.event.get():
        if e.type == pygame.QUIT or e.type == pygame.WINDOWCLOSE:
            pygame.quit()
            raise SystemExit

        if e.type == pygame.KEYDOWN:
            if D:
                print(pygame.display.get_wm_info())
            else:
                print(win.wm_info, win2.wm_info)

    if D:
        screen.fill(0)
        pygame.display.flip()
    else:
        win.get_surface().fill(0)
        win2.get_surface().fill(0)
        win.flip()
        win2.flip()

[damusss]

SDL_syswm.h header is removed in SDL3. The way to access the wm info has also changed, and I believe that also changes what values are exported by the SDL side.

I think that going forward any new API added should be SDL3 style, and any thing in the grey area should not be exported at all.

Alright, good to know. I'll study the new system that SDL3 uses and adjust the Window code for it. I believe I should keep the SDL2 version (unless it has more dictionary keys than sdl3 will support) so it can be added before pygame 3.

[damusss]

@ankith26 @Starbuck5 the most recent commit adds a codepath for SDL3. I removed the dictionary keys from the SDL2 codepath that weren't accessible in SDL3. My only limitations:

• I have no idea on how to test the SDL3 codepath
• I got confused sometimes. because I tried to be close to the sdl2 codepath, but sometimesPyLong_FromLong was used when the returned value was a pointer, instead of using PyCapsule_New. So I'd like to know if what I did is correct, as I assume the checks won't tell me anything

[ankith26]

Perhaps this PR should wait for the "port window to SDL3" PR to be made and merged first

[damusss]

Perhaps this PR should wait for the "port window to SDL3" PR to be made and merged first

I suppose that makes sense. Do you need special competence to pull off one of those PRs, or is it just about following the migration guide (and making different codepaths/creating compat macros)? (if so, I could even try to make it, otherwise I'll wait for you or starbuck). :)

Almost forgot, do you guys test your PR to actually compile with SDL3 locally, or do you just trust yourselves? About the first option (more likely), how do you do it? My WSL technically counts as linux if that helps

[ankith26]

We do test that the patch compiles on SDL3. It can be done locally, but you have to compile SDL3 from source if you are gonna go the WSL way (don't worry, it's not that hard). BTW, we also have SDL3 CI now that can do the testing on windows+mac+linux.

Basically the thing is we are yet to figure how to properly deal with the pixelformat changes uniformly, once that is done we can apply the same strategy everywhere and port the next wave of modules

[ankith26]

Well actually, Window is not blocked by pixelformat changes, I am working on porting it to SDL3 rn

[damusss]

Alright then, nice, thanks