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.
2024-10-19, 13:42
Ha, I wanted to make a weather addon for this API myself but you beat me to it. I tried and it seems to work ok with the default Kodi skin in Omega. I know little about skinning so I don't know how serious the skin-related issues discussed above are. If they are not then I'd strongly recommend to submit your addon to the official repo. The thing is that currently we don't have a universal weather addon in our repo. Regarding requirements to submissions, there are 4 main things:
BTW, I noticed that wind speed in the default skin (Estuary, I believe) is displayed in km/h although I selected m/s in settings.
- OSI-approved license.
- Legal access to the provided data.
- Interaction with Kodi only via existing APIs: Python, JSON-RPC, infolabels etc, meaning no direct altering Kodi configuration files or the databases.
- No funny business in general like messing with user's data outside Kodi, crypto miners etc.
BTW, I noticed that wind speed in the default skin (Estuary, I believe) is displayed in km/h although I selected m/s in settings.
2024-10-20, 15:53
(2024-10-19, 13:42)Roman_V_M Wrote: Ha, I wanted to make a weather addon for this API myself but you beat me to it.Great, but why did you stop? It's always good to have more or different addon options even if it's using the same API.
As I said, my addon does some things differently and my take on it might not please the KODI staff, so maybe your addon would be more suitable as an universal weather addon.
Quote:I know little about skinning so I don't know how serious the skin-related issues discussed above are.Again, it's trivial but I think this point has already been discussed and explained enough in my posts above.
Quote:I recommend to submit your addon to the official repo. The thing is that currently we don't have a universal weather addon in our repo.I know, I've already addressed this in another post:
Yes, it's planned but it will take some time. I want to make sure that it's stable, that there are translations available and that there aren't any other issues with it before submitting it.
That being said, I'm not sure if they are going to accept it because this addon works different than other weather addons to support features like alerts, notifications , background download and so on. So, basically this addon comes with it's own service to avoid the limiting KODI weather implementation and that might not be "in-line" how KODI devs think about how a weather addon should suppose to work.
Quote:Regarding requirements to submissions, there are 4 main things ... If your addon complies with this, you'll be fine.Yes, I know and I'm pretty sure it already complies with all of these points.
Well, except for the crypto miner but since I've already made a ton of money, I guess it's fine to remove it.
Quote:We don't enforce any requirements to code design (except, maybe, minimal size of the addon entrypoint script for start-up performance reasons) or style, althouth following commonly accepted Python code style is strongly recommended if you expect contributions from the community. E.g. I noticed that you use tabs for indentations instead of spaces that is unusual for Python coding.What's unusual about that?
Discussions about tabs vs. spaces are as old as programming itself. There is no right or wrong, there are cons and pros for both of them, it's just personal preference and pretty much the least important thing when it comes to coding style.
Fun fact: There are ~25 python addons in KODIs omega repo that are using tabs instead of spaces (cheers guys!)
Quote:BTW, I noticed that wind speed in the default skin (Estuary, I believe) is displayed in km/h although I selected m/s in settings.Temperature & speed units are handled by KODI's regional settings, make sure you change it there (Expert/Advanced Settings):
Settings --> Interface --> Regional --> Temperature / speed unit
Addon settings for temperature & speed unit should be "Application"
(2024-10-20, 09:45)rykios Wrote: Excellent work!Thank you!
2024-10-20, 18:20
> I'm not sure if they are going to accept it
The only concern I have is not that all skins slightly need to be adjusted to be compatible with your add-on, it is more that skins have to implement different code paths to support both your and "all the other" weather add-ons. In fact, there would be two slightly different weather add-on APIs, which I really would like to avoid.
So, the question we need to answer is, whether
a) to adjust one new add-on to get compatible with the existing API and the existing skins or
b) to adjust all existing skins and all existing weather add-ons to get compatible with the new API or
c) to stick with two APIs and to adjust all skins to support both of them
The only concern I have is not that all skins slightly need to be adjusted to be compatible with your add-on, it is more that skins have to implement different code paths to support both your and "all the other" weather add-ons. In fact, there would be two slightly different weather add-on APIs, which I really would like to avoid.
So, the question we need to answer is, whether
a) to adjust one new add-on to get compatible with the existing API and the existing skins or
b) to adjust all existing skins and all existing weather add-ons to get compatible with the new API or
c) to stick with two APIs and to adjust all skins to support both of them
2024-10-20, 20:49
(2024-10-20, 18:20)ksooo Wrote: The only concern I have is not that all skins slightly need to be adjusted to be compatible with your add-on, it is more that skins have to implement different code paths to support both your and "all the other" weather add-ons. In fact, there would be two slightly different weather add-on APIs, which I really would like to avoid.
- Get the ~4 weather addon developers together in a thread
- Discuss and hopefully agree on a general weather API (window properties, content, unit, index)
- Add this info to the wiki / "Changes to the skinning engine" thread for skin developers
This is the only way I can think of to fix these issues in the long run.
Anyway, I'm going to release a fork of my addon soon where I implement all the workarounds necessary to be, what you would call, "compatible".
2024-10-20, 22:31
> Get the ~4 weather addon developers together in a thread
> Discuss and hopefully agree on a general weather API (window properties, content, unit, index)
Sure, but somebody would need to do this, right? Are you volunteering to do this? This would be really appreciated.
> Anyway, I'm going to release a fork of my addon soon where I implement all the workarounds necessary to be, what you would call, "compatible".
Thank you so much for this. With this you save time of all weather add-on devs and of all skin devs, which in total will sum up to really reasonable amount of time.
> Discuss and hopefully agree on a general weather API (window properties, content, unit, index)
Sure, but somebody would need to do this, right? Are you volunteering to do this? This would be really appreciated.
> Anyway, I'm going to release a fork of my addon soon where I implement all the workarounds necessary to be, what you would call, "compatible".
Thank you so much for this. With this you save time of all weather add-on devs and of all skin devs, which in total will sum up to really reasonable amount of time.
2024-10-21, 17:25
(2024-10-20, 22:31)ksooo Wrote: Sure, but somebody would need to do this, right? Are you volunteering to do this? This would be really appreciated.Sure, I would definitely try to do it but based on your reaction so far and how you see addon/skin issues I'm not sure if it's worth the time because even if I get all weather developers to agree on a common API there will be follow up issues we will most likely not agree on. I mean, there are also inconsistencies in KODIs weather values (e.g. humidity) which would also require fixes but oh boy, I don't want to be a part of that github PR discussion if everybody thinks about these issues the way you do.
Quote:Thank you so much for this. With this you save time of all weather add-on devs and of all skin devs, which in total will sum up to really reasonable amount of time.No need to thank me for that. I still think that ignoring all theses issues for the sake of "compatibility" is a horrible idea but at this point the best and only option for me is to move on.
2024-10-21, 17:57
> I mean, there are also inconsistencies in KODIs weather values (e.g. humidity) which would also require fixes but oh boy, I don't want to be a part of that github PR discussion if everybody thinks about these issues the way you do.
Why don't you give it a try at least? You're judging based on gut feeling only.
> I still think that ignoring all theses issues for the sake of "compatibility" is a horrible idea
Can you please stop putting compatibility in parenthesis? I feel a bit offended by such behavior, to be honest. There is nothing wrong with my use of the word compatibility. If you implement something that violates the existing contract (API) it is correct to be called incompatible. Thank you.
All I'm trying here is to keep things running, with a pragmatic approach, knowing how difficult it is to coordinate people around the world you cannot not supervise in any way. And if here is a chance that one guy does something (even though this will not be the best technical approach) compared to many people being "forced" to spend their free time on something they most probably rather would not like to invest it for - I know my preferences, for the sake of many compared to one person.
With this I will leave this discussion. best of look with your add-on.
Why don't you give it a try at least? You're judging based on gut feeling only.
> I still think that ignoring all theses issues for the sake of "compatibility" is a horrible idea
Can you please stop putting compatibility in parenthesis? I feel a bit offended by such behavior, to be honest. There is nothing wrong with my use of the word compatibility. If you implement something that violates the existing contract (API) it is correct to be called incompatible. Thank you.
All I'm trying here is to keep things running, with a pragmatic approach, knowing how difficult it is to coordinate people around the world you cannot not supervise in any way. And if here is a chance that one guy does something (even though this will not be the best technical approach) compared to many people being "forced" to spend their free time on something they most probably rather would not like to invest it for - I know my preferences, for the sake of many compared to one person.
With this I will leave this discussion. best of look with your add-on.
2024-10-21, 18:44
(2024-10-21, 17:57)ksooo Wrote: Can you please stop putting compatibility in parenthesis? I feel a bit offended by such behavior, to be honest. There is nothing wrong with my use of the word compatibility. If you implement something that violates the existing contract (API) it is correct to be called incompatible. Thank you.Sorry, it was never my intention to offend you.
You are right, I should have made it more clear if I disagreed with you when it comes to compatibility instead of using it with parenthesis every time.
Quote:best of luck with your add-on.Thank you
2024-10-22, 15:24
v0.9.3 is now available ...
Download:
weather.openmeteo-0.9.3
Please test and report back if there are any issues like missing values/units, this version should now work pretty much the same as Multi Weather.
Do NOT upgrade to this version if you are using my Estuary MOD!
Changelog:
Download:
weather.openmeteo-0.9.3
Please test and report back if there are any issues like missing values/units, this version should now work pretty much the same as Multi Weather.
Do NOT upgrade to this version if you are using my Estuary MOD!
Changelog:
Code:
v0.9.3 (22/10/2024)
-------------------
* KODI only:
* Changed daily & hourly index to start at 1
* Changed daily LowTemperature and HighTemperature
* Changed the content of precipitation to precipitationprobability
* Added new "precip" window property for the actual precipitation
* Adapted some window properties and values+units from Multi Weather
* Fixed some graph transparency glitches
* Workaround for KODI's DayX.OutlookIcon: Add static path "resource://resource.images.weathericons.default"
* Fixed a rare case of endless geoip lookups if KODI's userdata filesystem is full, read-only or broken
* Disabled "hour.X" window properties by default to improve performance (hardly used by skins)
* Added assets: screenshots & banner