Hello everyone. Can you tell me if there is any way to implement text transfer or automatic resizing if it does not fit into a text block?
I have a problem with ([WTHR_COND_NAME]) in different languages. The length of the text varies greatly depending on the language. And as I found out yesterday, the same weather condition on the same OS version in the same language can be written differently on watches from different manufacturers. I tested on the Pixel Watch 2, and for a user with a Galaxy Watch, the same weather condition was called by a longer phrase.
I don’t this can be done in WFS yet. It can be done in raw WFF using isAutoSize or textLength, but WFS hasn’t implemented those features.
as @Gondwana said, I don’t think there is such option in WFS yet. If I had to do it I would make the font size smaller so that even the largest possible text can fit.
In this case, the text will be too small for many languages.
You colud try scrolling the text across the the screen [SRC_MSEC] is not terribly smooth . But for somthing small if could work .
You might be able to ellipsise the text (although I don’t know if WFS supports that; WFF definitely does). Google usually allows ellipsising when they review stuff, although it’s not a great user experience.
it could have worked if I had used one specific language in the watch face.
How to use it? I’ve never seen this before.
I will try make you a test soon . I am not a mathamatician . I have to make practical examples . The problem is the differeing lengths of the text string . We have no test for that . So there is a gap after the shorter strings .
Interesting question. We had similar discussion, “thunderstorms in vicinity” surprised me.
The problem is there are more weather conditions than tags.
If there were tags for every condition two sets of descriptions could be set.
For short descriptions like “cloudy” - set with bigger fonts, for “thunderstorms in vicinity” set with smaller fonts (if-then).
But to do that we need tags for all conditions.
Different languages? That complicates things even more.
Here is a quick test . Choppy on WFS . A bit smoother on a watch .
.
WEATHER_SCROLL_TEST.wfs.zip (1.7 MB)
.
Thank you. It looks interesting, but I didn’t understand how it works. Could you tell us more about this (-(([UTC_TS]/5000)%1)*400)?
I will get back soon .
There are two timers we can use to move things about the screen .
[UTC_TS] and [SEC_MSEC] .
The first is the Universal Time Code which is a big number running in Milliseconds . It is used on most digital products throughout the World . The beautiy for us it just continualy counts it does not go to zero every 60 second like the second one .
We have to make it into a sensible number to use it .
(([UTC_TS]/5000)%1)*400)
Deviding it by 1000 gets round the milisecond and deviding it by a furthur 5 will give us a 5 seconds cycle . Then because that is still a big number we Modulus the number by 1 , % in this formula means modulus .
This givers us a number that runs 0 to 1 every 5 seconds and we Multiply that by the Distance in Pixels we want to travel
. Put the Formula in a text box and delete elements with thier associated () and see the numbers . [UTC_TS] ( UNIX EPOCH TIMER ) is facinating it runs out in Feb 2023.
This should make a completely smooth scrolling but Samsung have introduced a Glitch to it to discourage us from using it because it is a Battery Drain .
Thanks for the clarifications. I wouldn’t have thought of that myself