-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Stop scrollview from consuming the interface #715
Comments
+1 for this |
This is caused by a limitation / bug of the current layout engine and widget implementation. In order to fix this, you have to explicitly state In any case, we should really tackle this limitation soon. I will work on it right away! |
Fixed by #2192. |
This fixes an issue where Fill-width elements in the column would disappear, maybe because of these issues: iced-rs/iced#715 iced-rs/iced#2186 iced-rs/iced#2192
I think this is still happening with version 0.12. I have a scrollable which can become quite lengthy and two buttons beneath it. If the scrollable takes up more space than the window offers, it pushes the button out of the window. My proejct Input file: This is the default for me when it opens: Then, enlarging the window to make everything fit: If there is barely space for the buttons, they are rendered very small (without text, I think) The view is created in src/gui/band_selection_view.rs and src/band.rs (and excuse the hardcoded parts, this is still very much a work in progress). |
My application has a main UI page which is broken down into 2 parts:
With the UI with explain enabled, you can see this:
Under log view in this image is a scrollview. Below that is a space followed by the status bar. It is drawn like so:
however, when I keep adding elements to the scrollview, this eventually happens:
Here, the scrollview has completely consumed the interface.
How would it be possible to stop this behavior?. I don't want to use the max_height function on the scrollview as i still want the entire UI to be adaptive according to the window size rather than creating a hard limit.
The text was updated successfully, but these errors were encountered: