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

Server Side Wayland Decorations Resize on Non-resizable Applications #3566

Closed
tarek-y-ismail opened this issue Aug 22, 2024 · 2 comments
Closed
Assignees
Labels
Milestone

Comments

@tarek-y-ismail
Copy link
Contributor

tarek-y-ismail commented Aug 22, 2024

Steps to reproduce

  1. Run a non-resizable application, making sure it uses its Wayland backend
  2. Try dragging the corners or edges

Expected behavior: Decorations shouldn't resize. Additionally, the cursor shouldn't change.
Current behavior: The cursor indicates that edges and corners are resizable. And on dragging, decorations resize creating a blank area.

Note: This was confirmed on two SDL2 applications (neverputt, defendguin). It doesn't seem to occur on SDL3 examples (game-snake, camera-read-and-draw), so it might be SDL2 specific. Suggestions for/Reproductions on other non-SDL applications are welcome

@Saviq Saviq added this to the 2.18 milestone Aug 22, 2024
@tarek-y-ismail tarek-y-ismail self-assigned this Aug 26, 2024
@tarek-y-ismail
Copy link
Contributor Author

tarek-y-ismail commented Aug 26, 2024

After a bunch of investigation, it turns out that this was a bug with SDL2 not calling xdg_toplevel::set_{min,max}_size (see bug report at sway and SDL fix PR)

What's weird though is that GNOME somehow works around this? I'm not sure how or why..

@Saviq
Copy link
Collaborator

Saviq commented Aug 27, 2024

What's weird though is that GNOME somehow works around this? I'm not sure how or why.

Well, it's just that we treat no min/max size as unbounded, while GNOME treat it as if min/max was set to the preferred size? Or they've a quirk of some kind.

There's nothing in https://wayland.app/protocols/xdg-shell that I can see that would say which behaviour is appropriate - it's left to the compositor to decide, so IMO this bug can be closed on our side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants