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

PopupWindow does not resize to the content size #6000

Open
Tracked by #1143
FloVanGH opened this issue Aug 29, 2024 · 1 comment
Open
Tracked by #1143

PopupWindow does not resize to the content size #6000

FloVanGH opened this issue Aug 29, 2024 · 1 comment
Labels
a:builtin elements The runtime data structures related to the items (mO,bT) bug Something isn't working

Comments

@FloVanGH
Copy link
Member

I have started with the implementation of this #5917. If you start the time picker in the edit mode, what needs less space and then you toggle selection mode with the clock what needs more space, you see that the content of the popup is resized correctly but not the PopupWindow itself. That prevents e.g. from interaction of buttons that are now outside of the origin size of the popup.

Tested with winit backend on Linux

Minimal example:

import { Button, VerticalBox, HorizontalBox } from "std-widgets.slint";
export component Demo {
    in-out property <bool> show-buttons;

    width: 600px;
    height: 400px;

    Button {
        text: "Show popup";

        clicked => {
            popup.show();
        }
    }

    popup := PopupWindow {
      
        close-on-click: false;
         
        content := Rectangle {
            border-width: 1px;
            border-color: black;
            background: green;
        

          VerticalBox {
                if root.show-buttons : HorizontalBox {
                    Button {
                        text: "Button top"; 
                    }

                    Button {
                        text: "Button top"; 
                    }

                    Button {
                        text: "Button bottom"; 
                    }
                }

                Button {
                    text: "Show buttons";

                    clicked => {
                        root.show-buttons = true;
                    }
                }

                if root.show-buttons : HorizontalBox {
                    Button {
                        text: "Button bottom"; 
                    }

                    Button {
                        text: "Button bottom"; 
                    }

                    Button {
                        text: "Button bottom"; 
                    }
                }
            }
          
        }
    }
}
@FloVanGH FloVanGH added bug Something isn't working a:builtin elements The runtime data structures related to the items (mO,bT) labels Aug 29, 2024
@ogoffart
Copy link
Member

This works "fine" with the Qt backend, but is a problem with the winit backend.

Just some preliminary investigation:
When showing a popup, we compute the size of the popup based on its with and hight property, as well as preferred size.
Then we set the with and height property to the actual size.

width_property.set(size.width_length());
height_property.set(size.height_length());

Note that we do the same on a normal Window

The difference with a normal Window is:

  1. For normal Window, we preserve the width and height bindings in lower_layout::check_window_layout
    This pass is currently only run on the top-level windows, but not on PopupWindow.
  2. For a normal Window, we have an actual slint::Window and WindowAdapter that will add a tracker for the layout constraint and call WindowAdapter::update_window_properties that will take care on the resize. This works fine for the Qt backend, but for the winit backend, we don't have such WindowInner/WindowAdapter at runtime right now.

So in order to fix that we need:

  1. run the check_window_layout pass on popup menu so that explicit bindings on width: and height: are kept
  2. Find a way for backends that don't have a runtime Window per popup to still work. One way to do it could be to create an internal PopupWindowAdapter, or implement that with a tracker without such an adapter. (Then we could also track the x and y coordinate)

@ogoffart ogoffart added need triaging Issue that the owner of the area still need to triage and removed need triaging Issue that the owner of the area still need to triage labels Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:builtin elements The runtime data structures related to the items (mO,bT) bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants