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

Support for drawing in any surface. #34

Closed
tgonzalez89 opened this issue Jul 21, 2021 · 3 comments · Fixed by #38
Closed

Support for drawing in any surface. #34

tgonzalez89 opened this issue Jul 21, 2021 · 3 comments · Fixed by #38

Comments

@tgonzalez89
Copy link

Right now the code expects the widget to be drawn in the display surface. If I draw it in another surface it doesn't understand the widget's position relative to the top level display surface only to the "local" surface and it doesn't handle mouse events properly.

@AustL
Copy link
Owner

AustL commented Jul 21, 2021

I'm not sure I understand exactly. Could you please provide some code to replicate the issue?

@tgonzalez89
Copy link
Author

Here is some example code that illustrates what I mean.

There are 4 buttons.

  • One (win) is placed directly in the display surface and works as expected.
  • Another (sub1) is placed in a subsurface (parent is display surface). This has the issue, but there is an easy workaround (more on that later).
  • Another (sub2) is placed in a surface that is drawn on top of the display surface.
  • The last one is the workaround for the subsurface case. The workaround consists of putting the button in the top level surface (the display surface) and when setting the position use the get_abs_offset function to offset to the desired position in the child surface. This works for nested subsurfaces, since get_abs_offset goes all the way to the top level.

To get a workaround going for the sub2 case (surface drawn into another one) the only way is to manually track all the offsets from each surface all the way to the top level. I didn't put this case here, but I think this library shouldn't support this case because it'll make it cumbersome to do. You would have ask the user for the abs offset, I don't think you can get it automatically from anywhere.

import pygame
from pygame_widgets import Button

pygame.init()
win = pygame.display.set_mode((600, 600))
sub1 = win.subsurface((300, 300, 300, 300))
sub2 = pygame.Surface((300, 300))
sub1_wa = win.subsurface((0, 300, 300, 300))

button_win = Button(
    win, 0, 0, 50, 50,
    text='W',
    onClick=lambda: print('Click Win')
)
button_sub1 = Button(
    sub1, 0, 0, 50, 50,
    text='S1',
    onClick=lambda: print('Click Sub1')
)
button_sub2 = Button(
    sub2, 0, 0, 50, 50,
    text='S2',
    onClick=lambda: print('Click Sub2')
)
button_sub1_wa = Button(
    win, 0, sub1_wa.get_abs_offset()[1], 50, 50,
    text='S1WA',
    onClick=lambda: print('Click Sub1_WA')
)

run = True
while run:
    events = pygame.event.get()
    for event in events:
        if event.type == pygame.QUIT:
            pygame.quit()
            run = False
            quit()

    win.fill((255, 255, 255))
    sub1.fill((192, 192, 192))
    sub2.fill((64, 64, 64))
    sub1_wa.fill((0, 0, 0))

    button_win.listen(events)
    button_win.draw()
    button_sub1.listen(events)
    button_sub1.draw()
    button_sub2.listen(events)
    button_sub2.draw()
    button_sub1_wa.listen(events)
    button_sub1_wa.draw()

    win.blit(sub2, (300, 0))

    pygame.display.update()

@AustL
Copy link
Owner

AustL commented Jul 25, 2021

I fixed the subsurface case, by making the 'contains' method take into account the absolute offset. I agree that the sub2 case should not be handled, as offsets would need to be handled manually.

@AustL AustL linked a pull request Jul 25, 2021 that will close this issue
@AustL AustL closed this as completed in #38 Jul 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants