Guest - Testers are needed for the reworked CDateTime core component. See... https://forum.kodi.tv/showthread.php?tid=378981 (September 29) x
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 7
Release Open-Meteo Weather
#16
@bkury: thank you so much for your efforts on that addon! Is it planned that it will be added to the official Kodi addon channel (for direct installation from within the Kodi menu)?
Reply
#17
(2024-09-30, 12:44)spinmaster Wrote: @bkury: thank you so much for your efforts on that addon! Is it planned that it will be added to the official Kodi addon channel (for direct installation from within the Kodi menu)?
No problem! 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.
Skin: Night | Weather: weather.openmeteo | Metadata / News (soon): plugin.universal.data | All-in-one KODI client & Night v3 (soon): OpenHT
Reply
#18
weather.openmeteo v0.9.2 and skin.estuary.openht (mod) are now available ...
(see screenshots for more info)


Changelog:
Code:
v0.9.2 (30/09/2024)
-------------------
* Added translation: French (thanks @nic020)
* Added check if addon is enabled
* Fixed DayX.LowTemp, DayX.HighTemp
* Fixed some graphs/autoscaling
* Fixed exception when changing languages (possibly a KODI bug)
* Added moonphase image
* Added map history setting
Skin: Night | Weather: weather.openmeteo | Metadata / News (soon): plugin.universal.data | All-in-one KODI client & Night v3 (soon): OpenHT
Reply
#19
Thank you for this.
Reply
#20
Just a quick one but daily.[DAY].hightemperature & daily.[DAY].lowtemperature don't include the °F or °C suffix like they do in other weather addons.

Thanks.
Reply
#21
(2024-09-30, 11:00)bkury Wrote:
(2024-09-30, 07:44)Raitsa Wrote: Sorry, the skin in my post is skin.transparency.ssedition-0.0.7 by @mikeSiLVO


edit:
After some more digging it seems like that your setup might have an older (or slightly different) version of python3 which doesn't support non-zero padded strftime values like %-d or %-m.

Please try to change your KODI regional settings to a different shortdate format (Advanced/Expert KODI settings)
  • Settings --> Interface --> Regional --> Short date format --> Change it to something like DD.MM.YYYY or DD-MM-YYYY
  • Restart KODI
Wow, that info solved it.
Changing to DD.MM.YYYY did not help but DD-MM-YYYY helped, now the dates are shown ok.
That was a clever find, thank you very much for your work and help @bkury Smile
3 * Nvidia Shield + Synology NAS DS218+ 2 * LG 77" + Genelec + WiiM Pro Plus & Mini + Adam T5V + T7V + T10S - ArcoLinux
Reply
#22
(2024-09-30, 20:07)Hitcher Wrote: Just a quick one but daily.[DAY].hightemperature & daily.[DAY].lowtemperature don't include the °F or °C suffix like they do in other weather addons.

Thanks.
Yes, and to be honest, I want to keep it that way.

There are no other window properties which include the unit, so this would just add another inconsistency on top of the already existing weather addon and KODI ones, especially if the proper "fix" for it is to add a $INFO[System.TemperatureUnits] like you do for every other temperature value anyway.

Let me know if I'm missing something or if there is a valid reason for it. Thanks!
 
Quote:Changing to DD.MM.YYYY did not help but DD-MM-YYYY helped, now the dates are shown ok.
Great! I hope this isn't very common, because a fix/workaround for it would be pretty ugly Smile
Skin: Night | Weather: weather.openmeteo | Metadata / News (soon): plugin.universal.data | All-in-one KODI client & Night v3 (soon): OpenHT
Reply
#23
(2024-09-30, 21:07)bkury Wrote: Yes, and to be honest, I want to keep it that way.

There are no other window properties which include the unit, so this would just add another inconsistency on top of the already existing weather addon and KODI ones, especially if the proper "fix" for it is to add a $INFO[System.TemperatureUnits] like you do for every other temperature value anyway.

Let me know if I'm missing something or if there is a valid reason for it. Thanks!
Isn't that what daily.[DAY].hightemp & daily.[DAY].lowtemp are for?
Reply
#24
(2024-09-30, 21:23)Hitcher Wrote: Isn't that what daily.[DAY].hightemp & daily.[DAY].lowtemp are for?
Yes, if you want to be fully compatible with every weather addon you should use those because these properties are the only ones which are actually defined by KODI.
And even those properties are only defined for DayX.Lowtemp because daily.X are all custom window properties anyway.

So, hightemperature and lowtemperature are basically just custom window properties which one day a weather addon developer decided to use for temperature+unit for whatever reason.
I would have adapted it but the fact that it would be the only value with a unit (out of 1000+) and that it's just unnecessary makes me want to ditch it now rather than carrying along.

It's difficult to explain but basically I'm just trying to clean things up a little bit
Skin: Night | Weather: weather.openmeteo | Metadata / News (soon): plugin.universal.data | All-in-one KODI client & Night v3 (soon): OpenHT
Reply
#25
(2024-09-30, 22:36)bkury Wrote: It's difficult to explain but basically I'm just trying to clean things up a little bit

I fully understand this, downside is that your addon is not 100% "compatible" with the other weather addons, making it not a perfect replacement. Maybe you can rethink your approach and bite the bullet for the sake of compatibility?
Reply
#26
(2024-09-30, 22:36)bkury Wrote: So, hightemperature and lowtemperature are basically just custom window properties which one day a weather addon developer decided to use for temperature+unit for whatever reason.
I don't know how the short and long versions came about but they've been standard for a long time now and are used in the default skin:

https://github.com/xbmc/xbmc/blob/777b96...e.xml#L923
Reply
#27
(2024-09-30, 22:41)ksooo Wrote: I fully understand this, downside is that your addon is not 100% "compatible" with the other weather addons, making it not a perfect replacement. Maybe you can rethink your approach and bite the bullet for the sake of compatibility?
I knew from the start that my weather addon probably won't be 100% compatible with existing weather addons/skins without very minor skin changes.
That's to be expected if you do some things differently and I would gladly bite the bullet if this minor issue would be the only thing that bothered me. I'll try to explain below
 
(2024-10-01, 00:53)Hitcher Wrote: I don't know how the short and long versions came about but they've been standard for a long time now and are used in the default skin:
https://github.com/xbmc/xbmc/blob/777b96...e.xml#L923
Yes, I know that this is in the default skin but that doesn't make it right. It's just something that's being dragged along and nobody cared about. 
It's interesting that you pointed out this exact position/label because only 15 lines below you will find the right way to do it: https://github.com/xbmc/xbmc/blob/777b96...e.xml#L938
So, if you replace L923 with L938 you basically fixed your issue at it's core without the need for my and future weather addons to add a custom property / workaround. Isn't that a better solution?

But let's not focus on the "low/high temperature" value. I know it's a minor issue, so let's say I've implemented a workaround for that. Then, what about the wrong weather item index which is also in estuary?
KODI itself and my addon are using 0 for list start (e.g. day0.XXX, daily.0.XXX = today, hourly.0.XXX = now/current hour) while estuary / weather addons adapted "daily.1.XXX = today, hourly.1.XXX = now/current hour" for whatever reason.
Should I also add a workaround for that although it's obviously wrong/inconsistent with KODI itself?

And if I workaround that, then what about "shortdate" and "longdate" format which my addon pulls directly from KODI settings instead of using a fixed date format. This might also break some skins because a label might not be big enough. I can think of at least 3 more examples where I can't guarantee 100% compatibility because my addon is doing something in a different (and hopefully better) way.

So yes, I could bite a bullet for the sake of compatibility but in this case I would bite so many bullets that I wouldn't have any teeth left and I don't think it's a good way going forward to add workarounds for stuff that has been done wrong in the past.
Skin: Night | Weather: weather.openmeteo | Metadata / News (soon): plugin.universal.data | All-in-one KODI client & Night v3 (soon): OpenHT
Reply
#28
I generally agree, but:

You not biting the bullit has some serious implications.

Every skin out in the wild needs to be fixed to support your addon properly, not just Estuary. That’s huge effort in total compared to just you having to do something.

All skins need to be fixed to support both the other addons and yours - ugly. Or all other weather addons would need to be adjusted to work together with the fixed addon api.

So, what you want to achieve from a theoretical standpoint is just fine, but in practice it induces lots of work for people you do not even know, you cannot „control“ at all.
Reply
#29
Quote:You not biting the bullit has some serious implications.
If you don't change anything in the skin, the worst case is that you don't have the tempunit in the forecast and that your hourly/daily forecast starts with tomorrow rather than today. That's it, everything else is working perfectly fine.
Quote:Every skin out in the wild needs to be fixed to support your addon properly, not just Estuary. That’s huge effort in total compared to just you having to do something.
"Every skin out in the wild needs to be fixed to support your PVR changes properly, not just Estuary. That’s huge effort in total compared to just you stopping to change the PVR API."
Please don't take this the wrong way, I just want to point out that there are always GUI / API changes which skin developers including myself should/need to adapt.
Quote:All skins need to be fixed to support both the other addons and yours - ugly.
So, changing 4 lines of skin code to their correct values to fix the core problem and increase the compatibility with already existing, current and future weather addons is "ugly" but having 5+ workarounds in weather addons, including some really nasty ones like the index stuff, is fine?
Quote:Or all other weather addons would need to be adjusted to work together with the fixed addon api.
You don't need to touch any weather addon with the skin changes.
Quote:but in practice it induces lots of work for people you do not even know, you cannot „control“ at all.
That's not true, we are talking about changing ~2 labels and adding an additional "0" item index for daily/hourly weather items. Every major KODI release or even your PVR/Favorites changes required a lot more work from skin developers than fixing 2 broken labels.

Anyway, I leave it to the actual skin developers to decide if they want to support the additional features of this weather addon. And if they do, they probably want to add stuff like alerts, animated maps, graphs and in doing so the question to fix 2 labels becomes irrelevant.
Skin: Night | Weather: weather.openmeteo | Metadata / News (soon): plugin.universal.data | All-in-one KODI client & Night v3 (soon): OpenHT
Reply
#30
> If you don't change anything in the skin, the worst case is that you don't have the tempunit in the forecast and that your hourly/daily forecast starts with tomorrow rather than today. That's it, everything else is working perfectly fine.

Depends on your definition of "fine". :-)

Hourly/Daily forecast starting tomorrow - esp. for hourly, today is what I'm most interested in.
I'm also missing "%" values for rain likelihood, for example. Instead of 10% I see only 0.1

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.
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 7

Logout Mark Read Team Forum Stats Members Help
Open-Meteo Weather0
This forum uses Lukasz Tkacz MyBB addons.