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

core: A small step to better popup placement #6434

Merged
merged 2 commits into from
Oct 2, 2024

Conversation

hunger
Copy link
Member

@hunger hunger commented Oct 2, 2024

This is the smallest possible improvement we can do for popup placement: Do not render popups outside the surface they can paint on!

@hunger
Copy link
Member Author

hunger commented Oct 2, 2024

This is what the combobox at the very bottom of the Propert Editor looks now with this patch applied:

image

not nice, but at least usable!

Copy link
Member

@ogoffart ogoffart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

What does it mean for the function to return None?
And if it returns None we don't show the popup?

Now the question is whether this is good enough to be merged in master. Could it break some usecase?

/// Find a placement for the `Popup`, using the provided `Placement`.
/// When a `clip_region` is provided, then the `Popup` will stay within those bounds.
/// The `clip_region` typically is the window or the screen the window is on.
pub fn place_popup(placement: Placement, clip_region: &Option<LogicalRect>) -> Option<LogicalRect> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does it mean for this function to return None ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current code is a bit limited, that Option in the return value is not used yet. I can remove it again for this initial patch.

I will need to pass min/pref/max sizes of the popup to the placement function. Once I do that, the code can end up in a situation where I can not place the popup at all. E.g. if our window is 200x200px, we need to render into the window surface itself and the popup has a minimum size of 300x300px. There is no way to render that popup fully, so I need to report that somehow.

I was considering using a Result instead, but there is no meaningful way to report that to a user, so a Option should do.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But what can be done if the popup doesn't fit?
Not showing it at all doesn't seem to be the solution.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can have it render centered on its Window maybe?

That might cut off UI elements necessary to dismiss the popup again though, so that is not good either.

@hunger
Copy link
Member Author

hunger commented Oct 2, 2024

The latest version got rid of the Option again and might have fixed the build issue in i32 Coords.

This is the most stupid policy for popup placement
that we can possibly implement: If we render the
popup as a subsurface in our own window, then just
make sure we move to popup so that it does stay fuilly
within our own window surface.
@hunger
Copy link
Member Author

hunger commented Oct 2, 2024

Now the question is whether this is good enough to be merged in master. Could it break some usecase?

I do not expect this to break things:

  • It is only triggered when the backend does not handle the window creation itself
  • If the popup is not in a separate window and shown fully: It changes nothing
  • If the popup is not in a separate window and gets cut off: This patch moves the Popup to make sure it is shown fully (or as much of it as possible).

IMHO moving a popup is always better than not showing all of it.

@hunger hunger merged commit 0723743 into slint-ui:master Oct 2, 2024
36 checks passed
@hunger hunger deleted the tobias/push-xlpylolynwzl branch October 2, 2024 16:14
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.

2 participants