Open creativecreatorormaybenot opened 3 years ago
Hello @leisim, is there any future plan for this enhancement or hack turnaround solution?
Much thanks!
@creativecreatorormaybenot @luqmanhakem This seems like a problem we should fix. I probably won't have time to implement it in the near future but I'll review any PR proposal as quickly as possible.
This also means AutoSize
can't be used inside SliverFillRemaining
:(
Using a layoutbuilder to find the width i can "Take" to auto size button actions on the app bar and overflow the rest to a ... more menu.
I cant do this because there is an intrinsic height sizing the app bar in my ui framework. I dont even care about the height constraint in my layout builder, even though I agree with the issue, my situation is just dumb, i should be able to use intrinsic height and get the width constraint at later.
The problem
So,
AutoSizeText
does not work usingIntrinsicWidth
orIntrinsicHeight
because:You might say: just do not use either of these widgets, however, I believe that that is a naive approach. The reason for this is that intrinsic sizing is an integral part of the Flutter framework. It can be used anywhere.
Example
We have a custom table widget. And because tables are intricate things, they will rely on intrisic sizes. We do not use
IntrinsicWidth
orIntrinsicHeight
- we simply use theRenderBox
contract:Consequences
If you have any
AutoSizeText
widget in a widget that makes use of the intrinsic sizing contract,AutoSizeText
will completely break that widget because it usesLayoutBuilder
.Solution
Here is a solution that could work (have not thought it through yet):
We should probably rewrite
AutoSizeText
to ditchLayoutBuilder
.We could do this by writing our own
RenderBox
(leaf render object) subclass. This would allow us to fulfill the intrinsic sizing contract and also properly perform the layout.We would be able to directly access the text painter instead of proxying through the layout builder.
Related issues