2024-09-30, 12:44
@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)?
(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.
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
daily.[DAY].hightemperature
& daily.[DAY].lowtemperature
don't include the °F
or °C
suffix like they do in other weather addons.(2024-09-30, 11:00)bkury Wrote:Wow, that info solved it.(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
(2024-09-30, 20:07)Hitcher Wrote: Just a quick one butYes, and to be honest, I want to keep it that way.daily.[DAY].hightemperature
&daily.[DAY].lowtemperature
don't include the°F
or°C
suffix like they do in other weather addons.
Thanks.
$INFO[System.TemperatureUnits]
like you do for every other temperature value anyway.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
(2024-09-30, 21:07)bkury Wrote: Yes, and to be honest, I want to keep it that way.Isn't that what
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!
daily.[DAY].hightemp
& daily.[DAY].lowtemp
are for?
(2024-09-30, 21:23)Hitcher Wrote: Isn't that whatYes, 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.daily.[DAY].hightemp
&daily.[DAY].lowtemp
are for?
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.(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
(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:
(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.
(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: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.
https://github.com/xbmc/xbmc/blob/777b96...e.xml#L923
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."
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.