Thanks for the suggestions! Yes, there's definitely room for improvement with the generated code ... I think the padding -> SizedBox conversion at least in some cases (only when main-axis padding is added) can be automated. We can experiment with code improvement features such as that and see how it works.

Expanded + Percentages for widths are possible already

At the risk of seeming a little bit nitpicky here, thing is: the end user shouldnt even use padding in this case. What Im saying is that when I look at a tool like that, what I will look for is how well you embrace the paradigm of the framework. Cause its greater than html5 imo - for the use cases were talking about. It should lead to fewer editor UI, fewer buttons, fewer basic options. Padding in this case should probably be only cross axial (or whatever) and then it becomes rarely used and then leads to better editor UI. Fewer hardcoded values as well - remember its "super cross platform". Should be hard to enter values.

Im only saying this to inspire you - not sure what the solution should ultimately be.

:D

Agreed, making it more natural to create apps in a way that follows Flutter best practices is a desirable end goal. There's so much to improve, it's exciting :-)