ANNOUNCE: xfce4-weather-plugin 0.8.2 released

[Harald Judt]

Hi,

Am 19.09.2012 11:51, schrieb Liviu Andronic:
> Hello
>
>
> On Fri, Sep 14, 2012 at 10:22 AM, Harald Judt <h.judt at gmx.at> wrote:
>> I have several versions of automake installed together with some wrapper,
>> but for the plugin 1.12.3 was used. I wonder if this is only specific to a
>> certain version. If it is, then I think adding another instruction step to
>> the build instructions would do. If not, it will need a fix. I will see how
>> other plugins handle it, maybe that gives a clue.
>>
> 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?

> I also uploaded binaries for Precise to my Ubuntu PPA. [1] (They will
> build shortly.)
> [1] https://launchpad.net/~landronimirc/+archive/xfce
>
> As for the plugin itself, I think the changes are great.
> - 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.

> - For each forecast element (cell) there are 3 lines of information,
> and it seems to me that this tends to renders less readable the
> temperature estimates. Perhaps it would be better to use bold for the
> temp estimates. Or maybe to move the 'Sunny', 'Clear', etc. labels to
> a tooltip that would appear when hovering the relevant icon. (Right
> now having both icon and label seems redundant.)

When comparing the amount of information presented to that in the 0.7 
branch, 0.7.x was even more verbose. 0.8 only presents raw facts ;-) But 
of course, the formatting etc. could be improved. Someone would need to 
make mockups and try what looks good. I'm not sure how easy implementing 
tooltips will be because of the several event boxes used, though I had 
plans to do that.

> - 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).

> 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.

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.

> All in all excellent work! Thanks
> Liviu

Thanks,

Harald

-- 
`Experience is the best teacher.'