It should be simple to make a circular button, right? In the Drag & Drop interface, I made a button component with width & height equal to 100. Done. It looks like a circle:
In the browser preview, it looks right:
But when Live Testing on an iPhone, it gets stretched:
I assume this is because of the white bar area at the bottom of the screen. The same amount of vertical space in the browser has to be squished to fit a smaller amount of vertical space above the white bar. Okay, that makes some sense.
But when downloaded on an iPhone 11, it still gets stretched:
Shouldn’t the final version of my app display a circle when I created a circle? What’s the fix for this? I really don’t want to adjust the height and width to unequal values to make the shape appear as a circle.
Is there a way to set the dimensions of the screen to better match my device?
I’m excited to mention our layouts component that should be released sometime in the near future hopefully!
That will bring back the flex environment to drag and drop. We’re brining back rows and columns yall! It’s just not ready to go live yet. I’ve done some testing and it’s dope, it’s just not 100% ready yet!
If we do user beta testing, i’ll be sure to ping you for that!
This should not make a visually rounded button unless you use a square device’s screen.
According to the documentation, Thunkable uses the screen size of 375x669 to import Figma files so if you use the same ratio you should get a nearly circle button. You are right because you can never know who will use your app and in what screen dimensions.
So for every 100px of width you should have about 88px of height.
… I think that, after set absolute values for height/width for a button, and use something like this:
you don’t have to take care about other ratio, no matter the screen.
You need to use that repeat while block tho, to let the app have time to display and have computed value.
Gosh, I always forget about DnD as I’m using only StP
My mistake
Doesn’t work in DnD as I don’t find any block to set button width/height
P.S. One more reason for me to keep going with StP
But this is unique to the DnD interface. In StP, circular buttons appear as circles. That’s why I was surprised to find that the DnD interface stretches them.
Two properties with the exact same name but with different value choices and different functionality is going to be really confusing for people.
For another thing, this is something that should “just work.” It doesn’t make sense to me that we would want to toggle this on or off. It’s not the way it works in the StP interface, as far as I know.
If I make a circle, it should render as a circle whether it’s a browser preview, a web app, in Thunkable Live, or a downloaded/published app. Automatically, behind the scenes.
This will be updated in future iterations of the platform coming soon hopefully. The updates that I preview today will absolutely remove the confusion! I’m not sure when we’re going to release it yet but just know that we see you too and we’re going to get rid of that confusion.
I think that there’s really valid use cases for both so I asked one of our engineers their input on why we would use either or and why we’ve defaulted to what we have and the following was the response which I think is pretty good
Use case 1. Expecting a component at the edge of the screen
If users wanted a component that was at the edge of the screen, it essentially wouldn't be possible with float in place.
Use case 2. Expecting an image to fill the screen.
If a user has an image that is completely fills the width of the screen in the designer, it should fill the width of the screen on the users' device. Float in place would put spaces on either side
In theory, we don't want to encourage building tablet/responsive apps on the phone designer. Users should use the tablet builder for tablet/large screen apps. In the context of building apps for phones, given how little the widths don't change that much on phones, stretch should generally be appropriate to maintain user expectations for the two points above.
For now, if a user really wanted float in place to be the default, they can create a group that covers the full screen and set it to float in place. It's an easy workaround.