sWeather

[skwire]

"Feels like" unit problem is solved -- imperial temperature measures still display in status bar with clear indication of "converted".

I'm not sure what if you're reporting something broken or not. The "converted temps" shown in the status bar should show the other temperature scale values when you hover over certain parts of the GUI. For instance, if you have metric units chosen, your main GUI will show values in Celsius, km/h, millibars, etc. If you hover those values, the values shown in the statusbar will be imperial values. I added it as an easy way to see converted values without having to constantly change the actual setting back and forth. Make sense?

The "LocalTime=1" doesn't break the main dialog anymore -- what it does is show the (almost) literal date format mask in the title bar.

This feature uses a different site's API but it seems to work fine for me. What is the format mask string you're using?

Displayed time formats unchanged: e.g., "Conditions for Lisbon, Lisbon, PT at 10:00 AM WEST" in status bar -- WEST is confusingly Western European Standard Time, as opposed to CEST and EEST...

This is another change I made and now is shows what Yahoo! sends back in the API. Beforehand, I used a different API value, "lastBuildDate," and now I use "Title." With the lastBuildDate value, it just updated the time to whenever the data was refreshed regardless of what time the actual weather data was generated. I think the Title value is the more accurate value. As for the WEST/CEST/EEST part, it's just displaying what the API returns.

Overall, sWeather seems snappier. Placebo?

Yeah, probably placebo. It seems quicker for me today as well. *shrug*

With the new API changes, I have to use the Yahoo! console and YQL (Yahoo! Query Language) calls. For the weather data, I know that the Yahoo! console aggregates the data from the Weather Channel website and, possibly, a few other sources. What I'm getting at is Yahoo! are at the whim of the other sites it aggregates from. So, when it seems slower, it makes me wonder if Yahoo! are being rate-limited or other issues are at play. I'm just hypothesizing; I really don't know for sure.

[Midas]

Thanks for the continued feedback, skwire.

"Feels like" unit problem is solved -- imperial temperature measures still display in status bar with clear indication of "converted".

I'm not sure what if you're reporting something broken or not. [...] Make sense?

• Not. And although it is of little use for me (I'm not British ) it does make sense.

The "LocalTime=1" doesn't break the main dialog anymore -- what it does is show the (almost) literal date format mask in the title bar.

This feature uses a different site's API but it seems to work fine for me. What is the format mask string you're using?

• "YYYYMMDD (dddd) HH:mm:ss" -- I considered removing those colons, too, but decided against for ease of reading.

This is another change I made and now is shows what Yahoo! sends back in the API. Beforehand, I used a different API value, "lastBuildDate," and now I use "Title." With the lastBuildDate value, it just updated the time to whenever the data was refreshed regardless of what time the actual weather data was generated. I think the Title value is the more accurate value. As for the WEST/CEST/EEST part, it's just displaying what the API returns.

• I was just reporting back what I saw. The part about WEST/CEST/EEST was a personal commentary.

Overall, sWeather seems snappier. Placebo?

Yeah, probably placebo. It seems quicker for me today as well. *shrug*

• It's great, anyway. Thanks for your work.

[skwire]

Thanks for the continued feedback, skwire.

You're welcome.

• "YYYYMMDD (dddd) HH:mm:ss" -- I considered removing those colons, too, but decided against for ease of reading.

I think what you want is: yyyyMMdd (dddd) HH:mm:ss

[Midas]

I think what you want is: yyyyMMdd (dddd) HH:mm:ss

• I see -- silly me for not detecting that. Thanks.

[skwire]

Arghhh, the performance of this new API is frustrating. After several hours of testing, I'm certain this is not an sWeather; hell, even the official Yahoo! developer page doesn't return data a lot of the time. I really hope they fix the issue but, in the meantime, I figured out a way to get data from the old API and have added an option for that (enabled by default). As the changelog entry states below, I have no idea how long Yahoo! intend to make the older API available. Please read the changelog entry for more caveats to this workaround.

Website | Download

Code: Select all

v1.6.3 - 2016-04-03
    + Due to Yahoo!-realted issues with the new API, I've added a workaround
      option to use the old API.  This option is enabled by default.  That said,
      while the older API seems to be much more reliable, I cannot guarantee how
      long Yahoo! will make it available.  Maybe this workaround will buy enough
      time for Yahoo! to get their stuff together regarding the new API.  Please
      note that the data is slightly different between the two APIs and that the
      "Full forecast" link doesn't appear to provide proper links when using the
      old API.
    * Prettied up the Options dialog with some icons.
    * Made the main form display missing data more elegantly.