NumberInput surprising/wrong behaviour with width & content_width
the number_input widget has two functions for setting the width (width & content_width). and as far as i call tell its also the only widget that has content_width
setting none or both (of width & content_width) to Fill works as expected, but using only one of them can result in (imo) surprising/wrong behaviour
as an example having two elements in a row, a number_input and a button(that is set to Fill):
let txt_minute = number_input(self.value, 0..999999, Message::NumInpChanged)
.style(number_input::number_input::primary)
// .width(Length::Fill)
// .content_width(Length::Fill)
.padding(0);
let btn_btn = Button::new(Text::new("Button"))
.width(Length::Fill)
.height(Length::Fill);
let content = Row::new()
.push(txt_minute)
.push(btn_btn)
.align_y(Vertical::Center);
left: default width; right: setting only width to Fill; they work as exepcted
but if they each are in a column (together in a row)
let content = Row::new()
.push(Column::new().push(txt_minute))
.push(Column::new().push(btn_btn))
.align_y(Vertical::Center);
then the number_input will only render as if not set to Fill, but with the column as Fill
and setting only content_width to Fill will take up all space (in both row and rowcol layouts)
im also wondering why there are both width and content_width functions, other settings like padding only have one and set the property on both the number_input and the text_input content.
It's really hard to determine the correct path here, especially since iced keeps changing how Fill and Shrink work. I believe he is finally leaving those alone, but before his last change this use to work fine.
if the handling of Length is unstable (or more specifically in this case, the interaction between different Length kinds) then thats not ideal.
but the question as to why both width and content_width functions exist still remains. because this odd behaviour does not occure if they are kept in sync.
if there is a reason that i cant think of rn, then that might help determine the path forward
if not then removing content_width might be better
I don't mind removing it, as generally the content should resize with the leftover space anyway. We just need to remember to add the button sizes in before we pass the leftover to the inner Textbox. This way it will resize correctly. I think the original usage of this was before a lot of major changes in iced occurred, and it was required at the time to function correctly.
It may be related to #278. I don't know if someone is working on either issues.
Of what I understood of the widget implementation, the width of the widget while content_width is the one of the underlying Typed input.
I don't see a configuration where keeping both of them is relevant.
If the user want the widget to be smaller they could use a container or something similar.
yeah the main issue is the Buttons. We would need to Adjust the height or Layout of them based on where they need to be.
If I have the time, I'll try to investigate it and see if we can get rid of it
@StillGreen-san Could you give the main branch on our git a try as @Ultraxime pushed some new changes which might fix the issue.