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

Adding relative_position #323

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

DasLixou
Copy link
Contributor

@DasLixou DasLixou commented Feb 27, 2023

  • Adding relative_position for EventContext returning RelativeResult
  • Adding bounds helper for EventContext

@DasLixou DasLixou changed the title Adding bounds_relative_position Adding relative_position Feb 27, 2023
@DasLixou
Copy link
Contributor Author

I am kinda unsure about the Inside / Outside thing because you will mostly use this with mouse events and they are as far as I know only sent if its "inside" the view, aren't they?

@geom3trik
Copy link
Collaborator

I am kinda unsure about the Inside / Outside thing because you will mostly use this with mouse events and they are as far as I know only sent if its "inside" the view, aren't they?

Mouse events can be sent to the view when outside of its bounds if the view has captured mouse events. This is typically done when a view is draggable so that the MouseUp event is still received if the mouse leaves the view while dragging.

@DasLixou
Copy link
Contributor Author

I am kinda unsure about the Inside / Outside thing because you will mostly use this with mouse events and they are as far as I know only sent if its "inside" the view, aren't they?

Mouse events can be sent to the view when outside of its bounds if the view has captured mouse events. This is typically done when a view is draggable so that the MouseUp event is still received if the mouse leaves the view while dragging.

Thats my thought. So what do you say is better? Leave it as it is or make it just directly return a (f32, f32). But you can now just do relative_position(x, y).unwrap() anyways so i think it wouldn't be bad to have that extra thing, right?

@geom3trik
Copy link
Collaborator

Thats my thought. So what do you say is better? Leave it as it is or make it just directly return a (f32, f32). But you can now just do relative_position(x, y).unwrap() anyways so I think it wouldn't be bad to have that extra thing, right?

I like how you had it with the enum. But it depends on how we expect this to be used. Essentially we're encoding 2 pieces of information into one here, the relative position and also whether it's inside/outside. Does it become inconvenient if all you need is one or the other? Another potential solution is to have a separate method for checking if the relative position is inside the bounds of the view. I think BoundingBox may already have this method. Let's see if anyone else has any opinions on this.

@DasLixou
Copy link
Contributor Author

yeah but boundingbox can only check for containing other boundingboxes. and this seems pretty clean to me (here are my two usages):

WindowEvent::MouseDown(_) => {
    if let RelativeResult::Inside((rel_x, rel_y)) =
        cx.relative_position(cx.mouse.cursorx, cx.mouse.cursory)
    {
        // implementation
    }
}

WindowEvent::MouseMove(x, y) => {
    let (rel_x, rel_y) = cx.relative_position(*x, *y).unwrap();
    // implementation
}

@DasLixou
Copy link
Contributor Author

But for .unwrap() I force the user to a for them maybe unused isInside check

@geom3trik
Copy link
Collaborator

I think for this we could rename it to something like cursor_pos_relative(), and rather than passing an x and y to the function instead just return the relative position for the mouse cursor. Because I imagine this is the primary use-case for this. Also I'm not a fan of unwrap here, could we come up with a different name?

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 this pull request may close these issues.

None yet

2 participants