Question about the xml components

[DxP]

ha ... still had time.
Got out of bed very early today. I looked at your watch face, sorted and commented the code a bit. The changes run fine for me.

Some of the elements doesn't works - I commented it out.

I am currently writing a collection of instructions with all the information and experiences that I have made. As soon as I have received a meaningful translation, I will put it here in the forum.

If you have no problem with the German language, I can send it to you in advance.

Enclosed your modified watch face.

[AlainProvist]

Thanks a lot

I went to bed yesterday with everything fine, and wake up this morning with this crap in lo-fi (see attachment).
Everything is perfect as in my previous screenshot in hi-fi, but in lo-fi and handwrist raised I have this. Note that the screen corruption disappears when the handwrist is raised, but other bugs remain.


Edit: I'll wait for the english version. I could for sure understand it in german but I would need a dictionnary because of forgot way too much german vocabulary in the past 10 years by not practicing :p

[AlainProvist]

Commenting your answers here :
- Yeah lots of cleaning was necessary for sure since it's wip. I have an extra font.xml in the digits sub folders I do not use, and extra separators images I do not use. I did not know that I could put a xml instead of the images in the 8c/slpt folder. So thx for the info :p I think I use the same image for the full and 8c folder for the icons only.
- for the percent item I did it separatly because at some point I put the numbers in a first line and the second line with the percent symbol and the battery icon (but it did not look great).
- for the handwrist mode, I don't really now if I will use it or not in the end (probably not). It seems to me that it can contain images in high colors mode and not 8 colors only, otherwise I can't see any benefit of having that.
- for the alignment I wrote earlier the values that are used in the code, but maybe some are bugged in lo-fi making this jump back and forth you were mentionning.
- for the step gauge, it should work it you look at my first screenshot.
- fillzero is indeed not used at all in the code lol
- About the floot data as gtr widget, indeed it seems to not be plugged correctly (data is never read). About the notification data field it's simply not implemented at all :s (no internet widget object created... just returns 0 and draw the datatype associated icon...)

[AlainProvist]

For the reccords, I'm seriously considering to "fix" and improve the huamiwatchfaces app if I find a way to recompile and re-odex it.


Edit: I think I may have found why the alignment is broken in slpt mode.
*off topic* Fu**ing code display that can't support if followed by brackets!!!!*end off topic*

Anyway, the gtr widget is considering the same way any value for the 2 lowest bits of the align value. Meaning that 0, 1, 2 and 3 will be left aligned. But the slpt gtr widget widget is only considering the 2 as the left aligned value and 0, and 1 as centered... So dumb...

[DxP]

66 (left) , 69 (right) and 72 (center) works fine in every mode. I have no problems with that.

[AlainProvist]

Yes because 66 is 2 (left align) | 64 (vertical centered) same for 69 which is 64 | 4 (right centered) | 1 (doesn't matter wether 1 or 0) and same for 72 which is 8 (horizontal centered) | 64

[GIK-Team]

*off topic* Fu**ing code display that can't support if followed by brackets!!!!*end off topic*

Código: Seleccionar todo

if(profanity){
   ban = TRUE;
}

[AlainProvist]

Haha thanks for fixing that (and not baning me for losing my patience actually figuring the if statement was the culprit )


The code I was refering is this one:
code for slpt centering:

Código: Seleccionar todo

public static void setLayoutAlign(SlptViewComponent layout, int Align) {
        layout.alignX = 2;
        layout.alignY = 2;
        if ((Align & 2) > 0) {
            layout.alignX = 0;
        } else if ((Align & 4) > 0) {
            layout.alignX = 1;
        } else if ((Align & 16) > 0) {
            layout.alignY = 0;
        } else if ((Align & 32) > 0) {
            layout.alignY = 1;
        }
    }

As you can see if you leave the Align value to 0 or 1 it will consider it as the default value of 2 the same as the value for horizontal centering.
In the same code handling centering for the normal widget:

Código: Seleccionar todo

int startY = this.y0;
            int startX = this.x0;
            int fontWidth = this.mFont.getFontWidth(result);
            if ((this.align & 2) > 0) {
                startX = this.x0;
            } else if ((this.align & 4) > 0) {
                startX = this.x1 - fontWidth;
            } else if ((this.align & 8) > 0) {
                startX = this.x0 + (((this.x1 - this.x0) - fontWidth) / 2);
            }
            int maxY = (this.y1 - this.y0) + 1;
            Log.d("GtrDataWidget", "startX: " + Integer.toString(startX) + "  startY: " + Integer.toString(startY) + "result:" + result);
            this.mFont.drawText(canvas, result, this.align & 112, startX, startY, maxY, this.mGPaint);

Here the default value is the same as the left centered one, meaning that if align value is set to 0 or 1 it will be left centered.

Long story short you MUST set the value to 18 (or 19) for left aligned and top aligned, 34 (or 35) for left aligned and bottom aligned, and 66 (or 67) for left aligned and verticaly centered, or the behavior may change depending if in hi-fi or lo-fi.

[AlainProvist]

I just found out that 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.

[GIK-Team]

Haha thanks for fixing that (and not baning me for losing my patience actually figuring the if statement was the culprit )

You're welcome.

Código: Seleccionar todo

if(error == "403"){
   SendPMto("GIK-Team");
}

[AlainProvist]

I'm starting to wonder if the only reason why the battery is draining is that "support26w" option. I've spent most of my day comparing a stock internal watchface, my watchface with and without the support26w mode. I looked at and compared the logcat for the 3 of them. And it seems that only my watchface with support26w on is spamming requests from the step sensor.

Código: Seleccionar todo

E/SLPT-native(  606): wakeup source ret  0  wakeup_type:  0
E/SLPT-native(  606): need_to_display  --->  true
E/SLPT-native(  606): need_to_skip_display  --->  false
E/SLPT-native(  606): wakeup source ret  0  wakeup_type:  0
E/SLPT-native(  606): need_to_display  --->  true
E/SLPT-native(  606): start to resume first
E/SLPT-native(  606): get deep watchface  index 0
E/SLPT-native(  606): start klvp request to sensorhub 0
E/SLPT-native(  606): need_to_skip_display  --->  false
E/logwatch--->logwatch(  113): kmsg file is full, file_size:4192061, readcount:2402, fifo_size:4194304
E/SLPT-native(  606): steps array size 10 , show level -1, count 114
E/SLPT-native(  606): steps array size 10 , show level -1, count 114
E/SLPT-native(  606): end klvp  ret  0
E/SLPT-native(  606): wakeup source ret  0  wakeup_type:  0
E/SLPT-native(  606): need_to_display  --->  true
E/SLPT-native(  606): need_to_skip_display  --->  false
E/SLPT-native(  606): wakeup source ret  0  wakeup_type:  0
E/SLPT-native(  606): need_to_display  --->  true
E/SLPT-native(  606): start to resume first
E/SLPT-native(  606): get deep watchface  index 0
E/SLPT-native(  606): start klvp request to sensorhub 0
E/SLPT-native(  606): need_to_skip_display  --->  false
E/SLPT-native(  606): steps array size 10 , show level -1, count 114
E/SLPT-native(  606): steps array size 10 , show level -1, count 114
E/SLPT-native(  606): end klvp  ret  0
E/SLPT-native(  606): wakeup source ret  0  wakeup_type:  0
E/SLPT-native(  606): need_to_display  --->  true
E/SLPT-native(  606): need_to_skip_display  --->  false
E/SLPT-native(  606): wakeup source ret  0  wakeup_type:  0
E/SLPT-native(  606): need_to_display  --->  true
E/SLPT-native(  606): start to resume first
E/SLPT-native(  606): get deep watchface  index 0
E/SLPT-native(  606): start klvp request to sensorhub 0
E/SLPT-native(  606): need_to_skip_display  --->  false
E/SLPT-native(  606): steps array size 10 , show level -1, count 114
E/SLPT-native(  606): steps array size 10 , show level -1, count 114
E/SLPT-native(  606): end klvp  ret  0
E/SLPT-native(  606): wakeup source ret  0  wakeup_type:  0
E/SLPT-native(  606): need_to_display  --->  true
E/SLPT-native(  606): need_to_skip_display  --->  false
E/SLPT-native(  606): wakeup source ret  0  wakeup_type:  0
E/SLPT-native(  606): need_to_display  --->  true
E/SLPT-native(  606): start to resume first
E/SLPT-native(  606): get deep watchface  index 0
E/SLPT-native(  606): start klvp request to sensorhub 0
E/SLPT-native(  606): need_to_skip_display  --->  false
E/SLPT-native(  606): steps array size 10 , show level -1, count 114
E/SLPT-native(  606): steps array size 10 , show level -1, count 114
E/SLPT-native(  606): end klvp  ret  0

DxP, did you ever use this support26w mode on any of your watchfaces? If this is the case (along with a step widget), did you ever notice some battery drain?

[DxP]

No, I don't use this mode. Only the "DOT Watch" watch face has it... As a test, but only the background image is changing. The fonts are even the same in all modes. I have no extensive battery draining noticed. It has a step counter and heart rate.

IMHO, the 26w mode is nonsens, if the watch face is clever designed and has been adapted to the characteristics of the display.

[DxP]

Yes because 66 is 2 (left align) | 64 (vertical centered) same for 69 which is 64 | 4 (right centered) | 1 (doesn't matter wether 1 or 0) and same for 72 which is 8 (horizontal centered) | 64

Can you this more explain?

[AlainProvist]

Well the only benefit of it is to have a better display when raising the handwrist. Having the full def backround and possibly the fonts too is cool, but in that case using the normal settings when raising the handwrist would have been simpler...

[AlainProvist]

Yes because 66 is 2 (left align) | 64 (vertical centered) same for 69 which is 64 | 4 (right centered) | 1 (doesn't matter wether 1 or 0) and same for 72 which is 8 (horizontal centered) | 64

Can you this more explain?

I don't know how well you master bitfields in programming, but to make this simple it's a way to store multiple values into a single integer number. Generally the subvalues are bool values so each bit represents a bool. Now in this particular case they chose to put each possible alignment value in a separate bit, which is a bit weird because you can't possibly want to be left and right aligned at the same time . But theoretically with separate bits for both, you could ask that.

The bitfield is the following one first (lowest) bit is usused. 2nd bit is for left align, 3rd for right align, 4th for horizontal center. Then 5th for top align, 6th for bottom align, and 7th for vertical center.
So in binary if you want something left aligned and vertically centered it will be 01000010 (from highest bit to lowest bit) which is in decimal 66. As the first bit is never used, it could be 01000011 (67) too.

Hope it's more clear now.

Edit: To go a "bit" further :p The code is using masks with & and | operators to "select" or "filter" the alignement. a mask is simply the integer value containing specific bits to 1. This way you can "select" the bit from the bitfield you want: like value & 2 (00000010) to select the value related to the left aligned bit. If this operation does not returns 0, it means the bit is "on". They also do value & 112 (01110000) to filter out the horizontal alignement from the value. The | operator is here to concatenate bits in the value. That's why I was using | previously to explain the possible values.

[DxP]

Ok. Thanks, but I think, this is to high for me or I'm to old for this now.

I'll probably stick to 66 for left-justified, 69 for right-justified and 72 for Center. That's enough for my designs.

[AlainProvist]

Código: Seleccionar todo

2  - 8  - 4
|    |    |
66 - 72 - 68
|    |    |
34 - 40 - 36

or any of these values +1 is the exact same

[DxP]

Código: Seleccionar todo

2  - 8  - 4
|    |    |
66 - 72 - 68
|    |    |
34 - 40 - 36

or any of these values +1 is the exact same

Yeah, now it clicked ... that's how I got it.
I'll take it over in my tutorial.

[DxP]

Tutorial is online... i hope, my english skills are sufficient

[AlainProvist]

Great tutorial. I think there are some minor mistakes like the data type explainations where you tell which datatype is or not working with the gtr widgets. You should put the datatype number in front of what it is instead of using 1. 2. etc because it's a bit misleading :p.

For the folders slpt and 26w for the background I'm pretty sure they are not used at all with the default background watchfaceitem. Only the gtr widget is using them if the support26w mode is on. the default background widget will simply use the normal background image when raising the handwrist wether or not the folder slpt or 26w is present.

I'll try to provide some example watchface with all the stuff I found here when I have time: viewtopic.php?p=6738#p6738
so you can make an even more complete tutorial .

[DxP]

to point 12 - I added / corrected it - but background_list (I also replaced watchfaceitem with watchfacecomponent in the list file) don't work anymore.

to point 2 - Nothing of this is working for me. Have you working code for example?

to point 3 - I tried a little bit with this code

Código: Seleccionar todo

<WatchFaceComponent type="timehand">
	<Item type="hour" x="160" y="160" config="@wfz/timehand/hour.png"/>
	<Item type="min" x="160" y="160" config="@wfz/timehand/minute.png"/>
	<Item type="sec" x="160" y="160" config="@wfz/timehand/seconds.png"/>
</WatchFaceComponent>

If the resolution of the hand graphics are 320x320px, then it works fine. "x" and "y" appear to be the pivot point of the graph relative to the graph. They do not determine the position on the display. With a 320x320px hands graphics it fits with x = "160" and y = "160". Do you know the other parameters?

to point 7 - I don't have tested yet, have you working code for example?

---
edit: Can you say anything to type="gtrwidget" dataType="6"?? Any Parameter or syntax?

[AlainProvist]

For point 12 you're totally right, it is only usable with watchface items. This will work for backgrounds, graduations, timehand, datawidget and timedigital only.

For point 2, the weather data is fucked up because it binds the second weather provider to the components (gtr widget with weather type or weather component type). I could easilly rebind everything to the first provider if I can rebuild the code and provide a fixed version of the huamiwhatchfaces.apk

For point 3, the code is parsing this

Código: Seleccionar todo

for (int i = 0; i < component.ItemList.size(); i++) {
            WatchFaceComponentItem item = component.ItemList.get(i);
            if (item.getType().equals("hour")) {
                hourX = item.getX();
                hourY = item.getY();
                centerHourX = item.getXCenter();
                centerHourY = item.getYCenter();
                hourConfig = item.getConfig();
            } else if (item.getType().equals("min")) {
                minX = item.getX();
                minY = item.getY();
                centerMinX = item.getXCenter();
                centerMinY = item.getYCenter();
                minConfig = item.getConfig();
            } else if (item.getType().equals("sec")) {
                secX = item.getX();
                secY = item.getY();
                centerSecX = item.getXCenter();
                centerSecY = item.getYCenter();
                secConfig = item.getConfig();
            } else if (item.getType().equals("point")) {
                pointX = item.getX();
                pointY = item.getY();
                pointConfig = item.getConfig();
            }
        }

so just set the properties to xCenter and yCenter for each item and you're good

For point 7 I need to check how it works but I think it's nearly the same as the timehand, with an extra min and max degree to map any progress compatible value in. Like step data type.

For datatype 6 with gtr widget, there is no specific code at all so it won't do anything.

[DxP]

That's funny and kind of not as expected...

xCenter and yCenter work, but not as an absolute value for the time hand position. The two values describe the position in relation to the center of the screen. An xCenter="10" moves the pointer 10 pixels to the right, starting from the center of the screen. So at position x=170 y=160. The parameters can also have negative values to shift left and up.

Código: Seleccionar todo

<WatchFaceComponent type="timehand">
	 <Item type="hour" x="160" y="160" xCenter="0" yCenter="0" config="@wfz/timehand/hour.png"/>
	<Item type="min" x="160" y="160" xCenter="0" yCenter="0" config="@wfz/timehand/minute.png"/>
	<Item type="sec" x="160" y="160" xCenter="0" yCenter="0" config="@wfz/timehand/seconds.png"/>
</WatchFaceComponent>

[AlainProvist]

Indeed the android api used here is a bit awkward. It's using a rotation matrix to do the draw, which for some weird reason is using the center of the screen as the zero reference instead of the top left corner for usual x, y draw.
Because of this, the x, y values are used to define the rotation center offset on the image (half width and height if you want it to rotate from the center of the image), and then xCenter and Ycenter define the position of that rotation center on the screen (from the center again).

[DxP]

Can someone explain "graduation" to me? What is it for?
I have not yet found a watch face that uses "graduation"?