ANNOUNCE: xfce4-weather-plugin 0.8.2 released

[Liviu Andronic]

On Wed, Sep 19, 2012 at 1:20 PM, Harald Judt <h.judt at gmx.at> wrote:
>> To solve this I had to upgrade to xfce4-dev-tools-4.10.0 (even if I'm
>> running Xfce 4.8). See "trouble compiling plugins on Xubuntu Precise"
>> thread. This may be worth mentioning in the installation instructions.
>
> That's bad, the weather plugin is supposed to build and run with Xfce 4.8
> and 4.10. I will need to look into why it doesn't work with the older
> dev-tools. Unfortunately only Xfce 4.10 is provided by my distribution, so
> that's a bit complicated and needs a lot of time. Just to narrow down the
> issue, can you try to build 0.8.0?
>
0.8.0 configures fine with xfce4-dev-tools-4.10.0.
0.8.0 fails to configure with xfce4-dev-tools-4.8.0.
0.7.4 configures fine with xfce4-dev-tools-4.8.0.


>> - The morning/afternoon/evening/night breakdown is very useful.
>> - Is it necessary to have such temperature precision: 19.8 degrees or
>> 17.3. Personally I usually look at the weather estimates and try to
>> round to the nearest multiple of 5. Say, if the estimate is 17
>> degrees, then I will try to remember 15 degrees. If the estimate is
>> 18, I will think of it as a 20 degree estimate. So in this sense, is
>> the decimal precision really useful? Wouldn't it be better to round
>> 19.8 to 20 and 17.3 to 17? (The same doesn't hold for speed estimates,
>> where decimal precision looks nince.)
>
> Please file a bug report so I don't forget about that.
>
https://bugzilla.xfce.org/show_bug.cgi?id=9318


>> - It may be interesting to put the forecast dates to the right-hand of
>> the forecast table. Say, you would have 'Today' on the left-hand side
>> and '19 Sep' on the right hand side, 'Tomorrow' and '20 Sep', 'Friday'
>> and '21 Sep'. Sometimes people function in terms of weekdays, while
>> other times they prefer actual dates.
>
> That's a good idea. Either make an option for selecting what is shown on the
> left side (weekdays, dates, maybe both), or add another column on the right
> (but then that might not look very nice).
>
On the right side it might be too cluttered, indeed. But building on
your idea, I would suggest using a scheme similar to that used by
OrageClock: A user-configurable string similar to '%A (%d %b)' would
result in 'Wednesday (19 Sep) being displayed. Allow only the use of
relevant 'date' macros, and provide some sensible defaults, and the
implementation would be flexible and useful.


>> Moreover, I see a strange artefact here: Outside my window it is
>> 'Cloudy', and the plugin uses the 'Cloudy' icon and label. However,
>> the temp estimate is 19.8 degrees (2 hours in the future) with an
>> associated 'Sunny' icon/label. Shouldn't the icon used by the plugin
>> reflect this future estimate?
>>
>> Reading "Precipitation and the weather symbol have been calculated for
>> the following time interval:" it seems to me that the behaviour above
>> is intended. But it is a bit confusing to mix 'actual' weather symbol
>> and 'future' temp estimate. Couldn't an 'actual' temp estimate be
>> computed using the past "future" estimates?
>
> It's not really intended, but it's the way that met.no service works. It
> gives symbols for certain intervals, and raw data like temperature at
> certain points in time. For the panel icon the shortest possible interval is
> taken, and for the icons in the forecast window intervals of six hours are
> preferred. So it may rain the next hour, but be sunny the remaining five
> hours.
>
This reminds me: It would be nice if a tooltip defined what met.no
means by the morning/afternoon/evening/night breakdown. Morning could
mean anything from 0 to 6h or from 6h to 12h, etc. The info could get
inside parentheses alongside the label, too.


> One annoying problem with the met.no service is that you don't get "actual"
> raw values when you do a query. You get the "actual" interval data
> (symbol/precipitation), but not the values at the start of the interval.
> That's limiting.
>
> Of course, when data at the start of the interval is available it could be
> used. At the moment, always data at the next future point in time will be
> used because that's how it worked when I took over development, and I
> decided to leave it that way (and partly because of the limitation mentioned
> before). But I'm planning to save data between requests and even plugin
> restarts, so it can be reused again later when not available. Then maybe the
> (temperature) values could be interpolated so that you have (faked) values
> at the current time. How satisfying this will prove I cannot say, but let's
> give it a try.
>
Yes, I think caching something like the last 4 data points would allow
the plugin to present "past" information that would be currently
blank. To indicate to the user sure that this info is for reference
only, it could be displayed in some gray shade (instead of
disappearing, as it currently does).

And it may or may not be a good idea to use "past" temp forecasts
alongside "actual" interval data. This would avoid the mix-up I
reported above and maybe provide more useful data to the user. I think
it's worth a try.

Regards
Liviu