My First Skin Help

[MourningStar]

Hello -

I have made my first skin based on the weather tutorial, bits of Yincognito's code and parts of zivallh's code. Before presenting it to the community I would like to have it inspected for approval. Then I will request a little help for a few issues I noticed. How should I proceed?

-thx

[jsmorley]

Hello -

I have made my first skin based on the weather tutorial, bits of Yincognito's code and parts of zivallh's code. Before presenting it to the community I would like to have it inspected for approval. Then I will request a little help for a few issues I noticed. How should I proceed?

-thx

Create a .rmskin of it using https://docs.rainmeter.net/manual-beta/distributing-skins/.
Add a reply to the thread here, and attach the .rmskin to the reply.

[MourningStar]

attached ...

the first issue I have is that the fahrenheit value take about 30 seconds to appear (i.e. change from 0 to the temperature value) compared to celsius instant display.

[balala]

attached ...

the first issue I have is that the fahrenheit value take about 30 seconds to appear (i.e. change from 0 to the temperature value) compared to celsius instant display.

Comments / questions:

• Why have you added the UpdateDivider=33 option to the [CurrentTemperatureF] measure? Not a good idea, because when the skin is refreshed / activated, the [@CurrentTemperature] measure returns the temperature in a few seconds, but the [CurrentTemperatureF] measure is updated after up to 33 (in most cases something around 30) seconds (this causes the delay you were talking about). I'd tend to remove this UpdateDivider. Not telling that there is no real reason on using it, the [CurrentTemperatureF] measure must be updated on each update cycle, it doesn't load too much the computer. Additionally note that as i said above, since the temprature in Celsius is returned by WebParser measure, it is not returned instantly, it takes a few seconds to be got.
• Even if this is not really a mistake, but the IfMatch option (IfMatch=^$) of the same [CurrentTemperatureF] measure is practically useless. I'd remove it.
• The Scale variable is not defined in the skin, but is used in the X, Y and FontSize options of the [MeterTemperature] meter, so this leads to error messages in the log. Define it either in the [Variables] section, or in the included BasicDualTemperature\@Resources\Variables.inc file.
• When you refresh / activate the skin in the log a Calc: Extra operation error message appears. This is due to the fact that the [@CurrentTemperature] measure didn't get its value yet, but this value should already be used into the [CurrentTemperatureF] measure and this always leads to error. To avoid it, disable the [CurrentTemperatureF] measure (by adding it a Disabled=1 option) and include the measure into the Times measure group (by adding a Group=Times option). This group of measures is enabled through the FinishAction option of the parent [@CurrentConditionsParent] measure (within the BasicDualTemperature\@Resources\WeatherComJSONMeasures.inc file). By disabling it, you avoid the error.

I think this is all for now, at least what I figured out.

[MourningStar]

thank you balala for your reply. Removing the UpdateDivider line resolved the delay and was very easy for me. Your last points are in terms beyond my comprehension. Other than this line removal fix, it still works. Perhaps my next issue will resolve your last points ...

Currently, the font is too small and I have no clue how to to make it bigger. I would like to add the capability for the user to change the font and font size to whatever they have on their system. I hope there is a an available template I can simply copy-paste into the code.

[balala]

Your last points are in terms beyond my comprehension. Other than this line removal fix, it still works. Perhaps my next issue will resolve your last points ...

I suppose with "Other than this line removal fix, it still works." you're talking about removing the IfMatch option (second point). The skin definitely works with it as well, and as said, having that option IS NOT A MISTAKE, just it's useless. Keep it if you want, but me personally don't see the point. An IfMatch, without IfMatchAction (or IfNotMatchAction) makes no sense, because why to check if the returned string is empty or not, if we don't do anything in any case?
For third point see below.
For the fourth (last) point, just follow the log when you're refreshing the skin. There you'll see a Calc: Extra operation error. I described in my previous reply what is causing this as well as how can you avoid it: by adding the Disabled=1 and the Group=Times options to the [CurrentTemperatureF] measure (and obviously refreshing the skin).

Currently, the font is too small and I have no clue how to to make it bigger. I would like to add the capability for the user to change the font and font size to whatever they have on their system. I hope there is a an available template I can simply copy-paste into the code.

The fonts are so small because as said in the third point, the Scale variable is missing. But the FontSize option of the [MeterTemperature] meter is using this variable (FontSize=(55*#Scale#)). The variable not being defined, the meter uses the default size, which is 10 (quite small). If you define the Scale variable (as said in my reply), you'll get the temperatures with much larger fonts (for Scale=1 for instance the size of the temperatures is 55 x 1 = 55 pixels).

[Yincognito]

Why have you added the UpdateDivider=33 option to the [CurrentTemperatureF] measure? Not a good idea

I added that option here, and I think it's a very good idea. The skin used lots of CPU without that - I don't care if some computers are more powerful or some users are more careless to resource consumption, it was simply a waste of resources, especially considering that the skin's dimensions and complexity (both low) shouldn't have produced such a waste.

Sure, it could have been -1 instead of 33, or some other number, but I didn't know and bother to check out if it was ok with when and how the WebParser parent measure got its data. Anyway, if that UpdateDivider bothers the meter, a very simple [!UpdateMeasure ...] or similar approach when the Celsius data measure (or the WebParser parent, for that matter) updated as well should solve this, very importantly, without increasing the CPU usage, because the calculation and basically everything else in the skin were to be done just once, when the data was received, and not every freaking skin update.

If you ask me, everything in that skin, bar the animated icon and the WebParser parent, should have had UpdateDivider=-1 set on them, but then, that was the original skin designer responsibility, at which he failed miserably, IMHO. In the end, folks do things as they wish, and my opinion on this will remain just an opinion. A just one, but affecting nothing whatsoever.

[MourningStar]

I added that option ...

And it was appropriate, for THAT skin. This skin, however, has no animation/graphics and is quite spartan in regards to bells & whistles, as is my intent for this skin. So, I think I understand balala's position in this light. Apparently, it was my skillset lack that it was left in there, as are other things that are being noted. I will try harder.

The op was for having it inspected for compliance with community standards prior to public offer. The feedback provided indicating errors or useless and missing code is, of course, warranted and needed.

Perhaps, in the end, it will not be something worth offering to the community. I still want to refine it to my liking and, if no help with the font request, will stumble and fumble my way.

-thx

[MourningStar]

...

[balala]

I added that option here, and I think it's a very good idea.

Sorry, didn't realize the code is yours, however I definitely didn't talk about your code, but about the code of MourningStar's skin.