[Resolved] How to make a circular button in drag and drop?

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:

image

In the browser preview, it looks right:

image

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?

1 Like

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! :slight_smile:

3 Likes

Yes please!

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:
screen
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.

@mimostel
See the first post, it says in the DnD UI. Will your blocks work in DnD?

1 Like

Gosh, I always forget about DnD as I’m using only StP :innocent:
My mistake
Doesn’t work in DnD as I don’t find any block to set button width/height :blush:
P.S. One more reason for me to keep going with StP :rofl:

1 Like

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.

This is a 100x100 circle in StP (project link):

Live Test:

Downloaded app:

So I assume Thunkable is resizing components in the background to fit them onto a non-square screen. Why can’t that be done for the DnD interface?

2 Likes

Hey everyone! Great update here!

@tatiang @mimostel @muneer

Screen Shot 2022-06-01 at 3.15.11 PM

1 Like

Great update…
But… again, is for DnD… As I started my main app here in StP, until I can convert to DnD, I’m struggle with that. And latest update just messed my app :frowning:
Android Thunkable Live v.312-14 - Thunkable v.308-59-prod bugged? - Feedback - Community

I appreciate that you’re working on a fix for this but I don’t think this is the right way to approach this.

For one thing, there is already a “Resize Mode” property:

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.

1 Like

If you ask me better test on android meaning the white bar should be medium sized.

this doesn’t solve the apk though.

What does this have to do with circular buttons?

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.

Your two screenshots are:

  1. white bar is stretched so the button stretches sideways

  2. white bar compressed, so the button stretches up&downwards.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.