2024-10-01, 17:55
Maybe one final question: How would Estuary xml look like if we want to support both your addon and let's say "weather.multi"? Will this end with skin xml having conditions for the different addon ids?
2024-10-01, 21:15
(2024-10-01, 17:50)ksooo Wrote: I'm also missing "%" values for rain likelihood, for example. Instead of 10% I see only 0.1Thanks, that's another "wrong" weather property I've missed ...
Estuary requests
$INFO[Window(weather).Property(Hourly.$PARAM[item_index].Precipitation)] and per definition this means you want to have the amount of rain/snow in mm/inches that falls back to earth. Then there is precipitationprobability what you are referring to, my weather addon provides both values under the correct properties. (see screenshot of my mod here: Screenshot ) And that would be the next workaround if I would provide precipitationprobability under precipitation which again is wrong ... And about values and units in general:
It's not a good idea to add units directly to values if you are working with a GUI. Why? Because what if I want the unit to be bigger, smaller or above/below the value? Or if I want the unit the have a different color/font or animation? Also, I can work with skin conditions like
Integer.isGreater/Smaller on values without units.Quote:I really like your addon, and really do not want to demotivate you, so I will just be quite now. Obviously I was not able to make my point, which mainly is that you should take into account that adapting many skins is definitely more effort than to make one addon (yours) behave like all the other weather addons which would result in no effort for any other addon. You really cannot know how many times the 4 line change needs to be done by different people.That's nice of you, but there really is nothing to worry about.
I really don't want to be complicated here but you also have to understand that all these minor issues quickly add up into a workaround mess for skin developers & weather addon developers.
edit:
I just think that this discussion is odd especially with a KODI dev. I mean, imagine if I would submit a PR which adds or changes some PVR stuff and the code would have variable names which doesn't match the content or are inconsistent, lists where the content starts at index 1 instead of 0 (don't really know if that's the case in c++ but I assume it) so you have to adjust your for loops and so on ...
We wouldn't have this discussion, you would reject it instantly with a "try again" comment and rightfully so ...
Quote:Maybe one final question: How would Estuary xml look like if we want to support both your addon and let's say "weather.multi"? Will this end with skin xml having conditions for the different addon ids?No need for conditions. There are multiple solutions for estuary, the safest would be to remove/disable the custom daily.X properties and go back to the already existing DayX approach which all weather addons support.
The only difference would be that you can't have more than 7 days forecast (I think)
Estuary patch:
This would fix the list index and would use DayX properties instead of the custom Daily.X. ones
2024-10-07, 21:06
Is there a way to add an entry via the user interface using latitude and longitude? I'm trying to add the North/South Pole but keep getting results for cities and not the geographical poles.
2024-10-07, 23:08
(2024-10-07, 21:06)cage Wrote: Is there a way to add an entry via the user interface using latitude and longitude? I'm trying to add the North/South Pole but keep getting results for cities and not the geographical poles.No, I don't think such a feature would be useful even for those rare cases.
But you could use the location name "Antarctica", which should give you what you want. Another option would be to go to Open-Meteo's API and use the "Search" button to find another suitable location name.
