Question about the xml components

[AlainProvist]

Hey there, I'm trying to create a custom watchface for my stratos3, and I have a few question about the syntaxe.

I saw that we can have a configuration entry for watchfaceitems using configList="@wfz/background_list.xml" to change both model and datatype
But is there a similar way to have that for the datatype of a watchfacecomponent of type gtrwidget ?

I also tried to use a watchfacecomponent for the weather datatype. After setting a custom font with most common symboles, I get a resulting display like this ":./:.". Is this some weird encoding way to let me know the weather type (sunny, raininy etc...) or the temperature in a generic format including both °C and °F ?
Does someone knows how to deal with that and create the appropriate font folder to display that ?
I'm currently getting this using :
<WatchFaceComponent
type="gtrwidget"
id="0"
dataType="8"
x0="162"
y0="96"
x1="212"
y1="112"
align="0"
space="0"
font="@wfz/digits/14p"
fillZero="0"/>


Thanks in advance.
Cheers

[DxP]

I saw that we can have a configuration entry for watchfaceitems using configList="@wfz/background_list.xml" to change both model and datatype
But is there a similar way to have that for the datatype of a watchfacecomponent of type gtrwidget ?

Unfortunately, this is not possible with the GTR widgets, as far as I know.
You can only change the background image in this way.

I also tried to use a watchfacecomponent for the weather datatype. After setting a custom font with most common symboles, I get a resulting display like this ":./:.". Is this some weird encoding way to let me know the weather type (sunny, raininy etc...) or the temperature in a generic format including both °C and °F ?
Does someone knows how to deal with that and create the appropriate font folder to display that ?

The weather has never worked for me.

[AlainProvist]

I saw that we can have a configuration entry for watchfaceitems using configList="@wfz/background_list.xml" to change both model and datatype
But is there a similar way to have that for the datatype of a watchfacecomponent of type gtrwidget ?

Unfortunately, this is not possible with the GTR widgets, as far as I know.
You can only change the background image in this way.

Well that's not totally true because I was able to put any watchfaceitems in the config too, beeing then able to change the type and model. But the same syntax doesn't work with gtrwidgets as watchfacecomponent.

As I'm speaking I now have an additionnal problem falling on me: my 3rd progress bar is no more displayed in 8c mode only. I tested it with the same source datatype (battery) on my 3 widgets with the exact same code inside (only the additive images differ). instead of having it displayed in 8c I get a single pixel line across the middle top of my screen with something like weird corrupted white pixels, and no gauge there. I used the same images as the high res images in my 8c folder (the same way for my 3 gauges). But for some reason only this one if affected by the bug. Is there some limitation in term of total number of images or widgets for a watchface?

I also had to disable the support26w option because my background and my widgets were also disappearing too when in that mode (handwrist raised). I can't figure how fuck my background can disappear only in that mode when I put my same lo-fi background in both slpt and 8c folders, without having that same behavior in lo-fi mode :s

Anyway thanks for the answer

[DxP]

().... But the same syntax doesn't work with gtrwidgets as watchfacecomponent.

This is what I say... It doesn't work with the gtrwidgets.
There are not "model"-type to choose.

[DxP]

As I'm speaking I now have an additionnal problem falling on me: my 3rd progress bar is no more displayed in 8c mode only. I tested it with the same source datatype (battery) on my 3 widgets with the exact same code inside (only the additive images differ). instead of having it displayed in 8c I get a single pixel line across the middle top of my screen with something like weird corrupted white pixels, and no gauge there. I used the same images as the high res images in my 8c folder (the same way for my 3 gauges). But for some reason only this one if affected by the bug. Is there some limitation in term of total number of images or widgets for a watchface?

I also had to disable the support26w option because my background and my widgets were also disappearing too when in that mode (handwrist raised). I can't figure how fuck my background can disappear only in that mode when I put my same lo-fi background in both slpt and 8c folders, without having that same behavior in lo-fi mode :s

Anyway thanks for the answer

I have no idea....

[AlainProvist]

My corruption is apparently coming from a limit of either the total number of images displayed or something linked, because reordering my widgets in term of declaration order in the xml makes the last one be corrupted. I'll continue investigating that by reducing the number of additive images for my gauges.

BTW, is the additiveimage type adding any index image on top of previous ones or just display the correct index image alone? In the first case, is there some other gauge type to do the second solution?

Edit: Ok I think I just found a way to fix that and answer my question. I just replaced

Codice: Seleziona tutto

	<WatchFaceComponent type="progress" dataType="10">
		<Item 
			type="AdditiveImage" 
			additiveBitmapConfig="@wfz/steps" 
			additiveBitmapCount="10"/>
	</WatchFaceComponent>
with
	<WatchFaceComponent type="gtrwidget" id="0" dataType="10">
		<Item type="batteryimage" x="0" y="0" bitmapArray="@wfz/steps" count="10" NewDisplayStyle="1"/>
	</WatchFaceComponent>

Edit2: Maybe I was too fast to say it fixed everything... it actually fixed my pixel corruption, but the last gauge is still not displayed if I put 2 arrays of 10 images and one of 12.

Codice: Seleziona tutto

	<WatchFaceComponent type="gtrwidget" id="0" dataType="10">
		<Item type="level" x0="188" y0="234" x1="249" y1="250" align="72" space="0" font="@wfz/digits/14p"/>
		<Item type="batteryimage" x="0" y="0" bitmapArray="@wfz/battery" count="10" NewDisplayStyle="1"/>
	</WatchFaceComponent>
	
	<!--Steps (1)-->
	<WatchFaceComponent type="gtrwidget" id="0" dataType="10">
		<Item type="level" x0="122" y0="266" x1="172" y1="282" align="69" space="0" font="@wfz/digits/14p"/>
		<Item type="batteryimage" x="0" y="0" bitmapArray="@wfz/steps" count="10" NewDisplayStyle="1"/>
	</WatchFaceComponent>
	<!--Distance (3)-->
	<WatchFaceComponent type="gtrwidget" id="0" dataType="10">
		<Item type="level" x0="162" y0="96" x1="212" y1="112" align="0" space="0" font="@wfz/digits/14p"/>
		<Item type="batteryimage" x="0" y="0" bitmapArray="@wfz/distance" count="12" NewDisplayStyle="1"/>
	</WatchFaceComponent>

If I reduce the number of images of gauge 2, then I can get my 3rd gauge again in lo-fi. So there seems to be a limitation of the number of images after all.

Edit3: And now I realize that additiveimage and batteryimage are both displaying all the images on top of each others... So my initial question still remains: is there a way to display only the image at the index and not all the previous ones?

[DxP]

BTW, is the additiveimage type adding any index image on top of previous ones or just display the correct index image alone? In the first case, is there some other gauge type to do the second solution?

No, there is no index picture. It always starts with 00.png and then counts up. With 10 images (10 percent steps) 09.png would be the end, or 100 percent.

---

As far as I know, you can only display values with a progress bar and the AdditiveImages that have a fixed end. E.g. Steps and heartbeat (200 BPM). Calories should work too, but it never works for me.

With distance, however, I cannot imagine that something meaningful can be displayed. How should a percentage value be visualized if there is no defined end with which the value can be calculated?

[AlainProvist]

No what I mean is that if you write that there are 10 images, if the current battery level is currently 87% it will just say the current index is the integer part of (0.87 * 10) (probably -1 because 0% is not using any image at all). This value can then only display the image set for this index or display every images of lower indexes until this index on top of each others. This totally makes sense for the term "additiveImage", and maybe also for "batteryimages". Since nearly every watchface I've seen including mine is using gauges already filled to the expected level, it doesn't matter if all lower levels are displayed or not.

I just got the answer to that question by simply creating images that won't overlap, and the answer is that it display all lower level until the expected one, on top of each others... which probably explains that some arbitrary limit is probably reached with my 3 gauges.

So does someone knows if there is a way to have a non Additive Image type but rather a selected image from a list of images to reduce the number of images displayed?

[DxP]

is not known to me

[AlainProvist]

Ok... I just decompiled huamiwatchfaces app from my stratos3. I'll come back with some findings shortly

Edit:
1. For additiveImage, there is a parameter "continueMode" that seems to only display the image of the current index if set to 1. Otherwise or default, it will display all previous images one by one until the current index.

2. Data type 8 is supposed to return high degrees and low degrees, but for some reason I need to determine, the value are not set resulting in ":." result value for both (explaining my weird display). We can use data type 65544 or 524296 for high degree and 131080 for low degree only and 1048584 with a bitmap array to display the weather image only.
-> OK I found out why only the item of datatype 8 for weather is working... it relies on some weather data from "WeatherCheckedSummary" that are valid, when on the other hand both gtrwidget of type 8 or weather gtrwidget are using the weather info from "WeatherInfo" that are invalid on the stratos3 at least.

3. There is a watchfacecomponent timehand allowing to have different centers for hours, min, sec and also some additional "point".

4. There is a "goal" type for components where you can display an image when a datatype goal (for example steps) is reached.
-> actually goal seems to be only usable with steps datatype...

5. You can use "graduation" type of gtrwidget to display a simple image on top of the background (used for the timehand graduation normally). Config asset's folder must be named graduation.png

6. gtr widget's item types "batteryimage" , "level" and "percent" can only work with battery data type.

7. There is a gtr widget's item type "pointer" allowing to display an arrow (like the timehand) for any data type with a max value (steps, sport distance, battery, heartbeats etc). You can specify an image with a rotation center, a position, and a min/max angle and the widget will rotate it accordingly (params, x, y, xCenter, yCenter, a0, a1).

8. The color property is a signed 64bits integer value. You can get the value from ARGB code using the windows' calculator in programmer mode. Just select the hexadecimal display, type FFFFFFFFAARRGGBB with AA RR GG BB your hex ARGB color. Then change the display to decimal and you should get signed integer value you can then copy paste in your xml. Transparency can be set to anything (not only full or no transparency).

9. For arcs, there is a cap value that was confusing me a lot because it sounded redundant to me with the a0 and a1 for min and max degrees. Actually cap value is absolutely not used in the code

10. There are an additional model 5 and model 19 for the watchface item weather (datatype 8).

11. align property is a bitmask : by default (0) it's top left aligned to the box defined by x0, y0 and x1, y1. Then 2 means left aligned (same as 0), 4 means right aligned, 8 means horizontally centered. And 16 or 0 means top centered, 32 means bottom centered, and 64 means vertically centered. So if you want something centered you should set 64+8 = 72.

12. The backgroud watchfaceitem is actually binding the full res image to both 26w and full res widget. This explains why the image in slpt or 26w folder is never used for the background. If you want the slpt folder's image to be used you need to declare a watchfacecomponent of type background instead.

[DxP]

That's sounds awesome.
Have you code examples or can you share the decompiled data?

[AlainProvist]

I will for sure once I get something functionnal. For now I'm still investigating that weather shit for the stratos3... So disappointing that the weather provider is not working withh the gtr weather data, and that there is no way to use the data coming from the normal weather data :'(

link to the decompiled code: http://www.mediafire.com/file/m3uj77022 ... s.zip/file

[DxP]

Thanks for sharing....it's very interesting

The parameter "continueMode" has no effect, i tried out today.

continueMode="1" - nothing is happend
continueMode="0" - nothing is happend

always the same result, like without the parameter, it is show all images according to the index

[AlainProvist]

True... :s (I did not check if it was actually working...)
I don't understand why it doesn't do what the code is supposed to do...

[AlainProvist]

FFS this is so stupid... just replace "progress" by "gtrwidget" and it will work
"progress" will instanciate a gtrwidget but instead of using the generic gtrwidget parser, it will use the gtrprogress parser, which, for some weird reason won't parse the newdisplaystyle and the continueMode which will in the end stay at the default value.

Edit: I'm continuously updating my previous post with my findings

[DxP]

you mean, I can replace

Codice: Seleziona tutto

<WatchFaceComponent type="progress" dataType="10">
  <Item type="AdditiveImage" additiveBitmapConfig="@wfz/steps" additiveBitmapCount="10" continueMode="1"/>
</WatchFaceComponent>

with

Codice: Seleziona tutto

<WatchFaceComponent type="gtrwidget" dataType="10">
  <Item type="AdditiveImage" additiveBitmapConfig="@wfz/steps" additiveBitmapCount="10" continueMode="1"/>
</WatchFaceComponent>

and it works?

I will try it tomorrow, today I have no time for that.

[AlainProvist]

Yes exactly.

btw I think there is a serious memory leak in humamiwatchfaces app when applying a new external watchface and even worst when using the settings of a configurable watchface. My watch is slower and slower each time I do that and I have to reboot it in the end when it becomes too slow. I did not reboot my watch yesterday before going to bed (nearly 2am and it was 100%), and this morning I wake up with a 26% battery watch :s

Edit: Mmmh it seems my watchface is draining the battery actually... nice punch in my face... (I think the basic meteo widget is the culprit but I will need further investigations)

[DxP]

My "Carmen Phoenix" watchface also sucked on the battery in the first version. The reason for this was the graphics for the curved text values (date and battery). When I reduced it, the battery consumption returned to normal.

[AlainProvist]

What do you mean by reduce ? The size of the font images ? the size in kb of the images ? The number of images ? What is weird is that I nearly didn't change anything compared to the last time it worked correctly, except adding the weather widget and suddenly it started to drain the battery like hell.

[DxP]

In an early version I just used 320x320px images with the text in the correct position for the day of the week and month. I tried the easy way . Result> The battery runs out extremely quickly. Now I have reduced the pictures to the bare minimum and the battery consumption is fine again.
I conclude from this that large graphics massively increase battery consumption.

[AlainProvist]

Haha that's exactly what I did for my gauge's pictures :p but with the continueMode only one should be displayed at the same time. I'll run some tests be removing elements one by one to get which one is the culprit. I'm betting on the weather widget but let's see :p

Edit: definitly the weather widget x_x That could explain why some ppl complaint about battery drained in one day on some forums. Maybe they simply used a custom wfz watchface using that widget...

Edit2: I got the bug again without the widget I think... Didn't change anything to fix that except reapply the config on my watchface... The craziest thing is that the bug occured just after a reboot of the watch. What I noticed during the bug is that the sleep mode was actually never triggered; it stayed with the screen off with the high def images and seconds displayed.

[AlainProvist]

I give up... Too many bugs I can't even understand with my watchface... I keep struggling with the same issues over and over :
- random battery drain issue
- random widgets not displayed in lo-fi mode
- random freeze of the time digital in lo-fi
- random offset appearing on my font in lo-fi (the "." and "km"/"mi" characters are shifted 1pxl down for no reason (tex size is the same for all my charset)) -> aparently you need font textures' height be a multiple of 2 otherwise separators will be centered 1 extra pixel lower than the digits in the charset!!!
- random alignement change in lo-fi.
- random texture corruption in some rare cases

All that happens randomly without even modifying my watchface... just reboot/apply/use settings. I'm just wasting too much time for absolutely no chance of having a watchface usable by me or any end user...

[DxP]

Can you send me your WFZ file? Maybe I can help you...

[AlainProvist]

I removed the settings options and some list xml file I was actually not using, and it seems now more stable. I finished everything in a hurry and put back the weather widget. Let's say this is the first draft of what I planned to do. Looks a bit dense in term of information to me now, but at least if I can get something fully fonctionnal and bug-proof before puting more work on this, it would be great.

I finally fixed my offset shifts in lo-fi by changing my font's textures height to a multiple of 2.

[DxP]

I have the file downloaded. You can delete it in post, if you want. I take a look at Sunday, tomorrow, I don't have time for it.