Hi all, I am looking for the best settings that would display 3 images side by side in a square shape on different phone screens.
Currently I have width of each image component set to 30% but struggling to figure out how the height value would be to avoid distorting images.
Thanks
The problem is that you cannot find a universal proportion that would work for all phones and tablets.
There are phones that have resolution of such that height is 1.86 times the width (in portrait mode, evidently) and tablets with a 1.5 height to width ratio.
Set the height to 30% and the width cannot be 30% to make the square. And if you find the right width, it will not be correct for another device.
Tools like Stencyl, Bubble.is, etc do give you options to get the current width size of the image based on the width of device and set the height to use same dimensions.
So if width of screen is 100px, then set height to current width size. So as image scales up or down relative to width of device, so will the code change height size accordingly.
Unfortunately for Thunkable, there is no way to get device width.
If there was a way to convert the relative size of for instance 20% width to pixel, then that might work.
Classic Thunkable has many of the components able to have their width and height set in pixel and in %.
Since you can also query the width and height in pixel, setting one of the property in %, getting that component resulting height or width in pixel allowed to set the other property to the right value for the image to be just the desired proportion. Alas, this is a feature that is not present in X thunkable… One of several widgets and facilities that prevent me from entertaining the eventual port of my app from Classic to X.
If you do not absolutely need to target iOS, you may consider going with Classic.
It looks like my porting of my PolyUnit app towards iOS will have to be through Xcode… Yet another learning curve ahead.
Looks like I might just go with classic even though classic isn’t user friendly but would do the trick
classic does not have the search option to locate components so u just have to know where each is. Maybe also I have not used it much so might just need to get used to it
There is a total of 48 components in X, a search does not strike me as a necessity, but you have a point; Classic could use it more with over 80 components.
But it ends up being the 80/20 Pareto principle again: 80% of the time, you use components from a small set of 20% of them; so those that you need frequently, you quickly learn where they are.
But what I like about the Classic can be summarized in two very important elements:
1- web viewer with the webview string. The string is needed because it allows the thunkable part to send and receive data with an HTML/Javascript file. And that gives you POWER.
2- the canvas. Since it has a touched down event that returns the X and Y location, with the right code, you can turn a blank space into some sort of dynamic interactive area, with ‘floating’ button zones. I have that app where a varying number of components may exist. I started by making those elements a bunch of varying width labels (as a function of how large a caption there was, of if it was not needed). I couldn’t do that with buttons because I would have needed 30 to span the width, and buttons have that margin where the caption cannot extend all the way to the edge, meaning the text could never really appear on the buttons. But with canvas? No problem (well, a LOT of coding is needed, but it works). I just DRAW the zone, fill it with the text under my control as far as margins are concerned. I just need a sophisticated procedure to determine which caption corresponds to the area that was touched and manage what the touch means. Basically, one could make the whole screen a canvas and draw whatever is needed and redraw as one wish. Of course that would take an awful lot of blocks, but you get my drift. There are things that you end up needing that do not exist, and with canvas you can make it. Without canvas, X is just not capable of this level of adaptability yet.
Yep I am in agreement with you. BTW I keep seeing thsi bit " 1- web viewer with the webview string . The string is needed because it allows the thunkable part to send and receive data with an HTML/Javascript file. And that gives you POWER ."
Can you show example of where this is used and what it can do.
I’ll give you 3.
My app is a unit calculator. Not a unit converter–there are plenty of those around. What I mean by unit calculator is that you can put “5 inch + 6 cm” and get the answer in pica (pica is a typographic font size unit) if you wish. Or add US gallon to UK pint and get a result in litre. Whatever. You don’t convert, the calculator takes care of it. You enter what you have and specify in what unit you want your result, and it handles the rest.
In keeping with the Pareto principle, there are units that someone will be using a lot more often than others (my app has almost 400 units, including 90 currencies – and m and cm are NOT two different units. both cm and m are metre. The “c” is a prefix. There are 24 metric prefix defined; so if one wanted to count cm and mm as separate units, we’d be talking thousands of units), and the ones a user considers popular are likely to change over time (if you are on a trip, you will use currency conversions, but when you start working on the deck in your backyard, you will be more heavily using linear measures).
So, in order to speed up access, the app offers a ‘favorite’ key that keeps tabs on the recently frequently used units. This implies sorting the frequency of use score. And that is where it gets tricky.
The best algorithm for sorting is heapsort. Coding this in Thunkable Classic blocks was shown in my test to take over 3 seconds to sort the unit usage and display the 20 most popular ones in order for the user to pick. Evidently, 3 seconds delay after clicking a button is very long if the intention is providing the means of avoiding going through two scrollable menus (one for the type of unit, one for the unit from the type); that saves little time, if any.
But taking all the unit frequency scores, putting them in a webviewer string, sending this to a webviewer component (it does not even have to be visible!) that loads a file with the same heapsort logic coded in HTML/Javascript, and returns the resulting sequence for the front end to display in a menu; well, that was running about 700 times faster. I actually had to make mock tests with list of thousands of entries to accurately measure the speed gain, because it was going so fast. I would have been happy with half a second, but I got 4 millisecond.
Another case was with the trigonometric functions. Sine of 30 degree is supposed to be 0.5.
Except that the “sin” function in Classic Thunkable returns something that displayed as 0.499999999482 on the 12 decimals display. So, I modified my code to send the trigonometric functions to be processed by a Javascript code using the webviewer string. Now, I have sin(30 degree) = 0.499999999999999944489 which renders as 0.5 up to 16 digits. Problem gone.
I told you about those 90 currencies?
The app has a page that shows the exchange rate, allowing someone to tweak them (suppose that the rate needs to be the one from last week for instance, or needs to include some processing fee, or whatever – anyway, just looking at them with their little flags is kind of neat). I could never put 180 text fields (2 for each currency, conversion from and conversion to US dollar) logically linked so that changing the ‘to’ rate changes the ‘from’ rate in the reverse proportion, in a scroll table (since you only have the room to show a dozen currencies at a time) with the processing required using thunkable blocks, that would have been crazy complicated. But with HTML and Javascript? A cinch.
