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 event for changes to the safe area #3911

Open
madsmtm opened this issue Sep 11, 2024 · 2 comments
Open

Add event for changes to the safe area #3911

madsmtm opened this issue Sep 11, 2024 · 2 comments
Labels
C - needs discussion Direction must be ironed out S - api Design and usability

Comments

@madsmtm
Copy link
Member

madsmtm commented Sep 11, 2024

#3890 added an API to query the safe area, but left an API for listening to changes to that value unspecified (only noting that RedrawRequested would be called if it changed).

The API could look something like this:

enum WindowEvent {
   SafeAreaChanged {
        origin: PhysicalPosition<u32>,
        size: PhysicalSize<u32>,
    }
    // ...
}

But that'd mean we have to emit it whenever the surface resizes too, which isn't so nice.

Perhaps something like the following would be better?

struct Insets {
    top: PhysicalUnit<u32>,
    left: PhysicalUnit<u32>,
    bottom: PhysicalUnit<u32>,
    right: PhysicalUnit<u32>,
}

enum WindowEvent {
   SafeAreaChanged(Insets),
    // ...
}

trait Window {
    fn safe_area_insets(&self) -> Insets;
    // ...
}

See also discussion starting from #3890 (comment).

@madsmtm madsmtm added S - api Design and usability C - needs discussion Direction must be ironed out labels Sep 11, 2024
@madsmtm
Copy link
Member Author

madsmtm commented Sep 11, 2024

Responding to #3890 (comment) here:

It doesn't have to be synced though, you should emit it only when the area changes, resize doesn't mean that it changed, because it may not apply at all.

The issue with exposing size in the event is that if the user stores that size, and they get a SurfaceResized event, the size from the previous SafeAreaChanged that they stored would now be wrong.

So we'd have to emit the SafeAreaChanged again, or state something like "SurfaceResized invalidates the safe area rectangle, you should re-query it with Window::safe_area".

If we expose the insets directly, they would never be wrong, even if the surface itself is resized.

@kchibisov
Copy link
Member

If we expose the insets directly, they would never be wrong, even if the surface itself is resized.

Yeah, that's probably not a bad idea after all, since it's just an extra padding one could say and it'll be much easier actually, since you likely already have a padding handling of some sort in your application just to not make elements render right at the border of the window.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C - needs discussion Direction must be ironed out S - api Design and usability
Development

No branches or pull requests

2 participants