ANNOUNCE: xfce4-weather-plugin 0.8.2 released

[Harald Judt]

Am 20.09.2012 09:19, schrieb 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.

Could be this one then:
http://git.xfce.org/panel-plugins/xfce4-weather-plugin/commit/?id=2b202977830b2c61e5cfa34768ae88fb9c02fb6b

Though I don't know what's wrong with it, I only followed the 
instructions in bug #6920. Could you try reverting the commit and see if 
that helps, so we know for sure?

Anyway, this only affects people compiling from git, right? The official 
0.8.2 tar.bz2 package you can download shouldn't need any changes. So if 
xfce4-dev-tools-4.10.0 works and can be used with 4.8.0 for compiling 
git HEAD I don't think we should spend too much time on this.

Current Xfce stable release is 4.10, and the next one won't take too 
long either, so 4.8 will get deprecated soon. Using 4.10.0 dev-tools 
seems to be an easy fix and additionally solves problems with other 
plugins too.

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

Thanks, this way I'll remember it ;-)

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

On a second thought, isn't that a bit overkill? I mean, "today" and 
"tomorrow" are quite clear to me, easier to grasp than a date which you 
have to translate into a weekday ("Now what weekday is that date? Oh 
yeah, that is today."). If you need to know the date, why not simply 
look at the calendar or datetime plugin? Using such strings seems ok for 
a calendar or clock where that is the main interest, but here I think 
they may even mess up the layout of the forecast window, and then you 
have to care about the parsing too etc.

[...]

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

Ok, I'll look into it another time, currently too much other stuff 
piling up.

Thanks for your ideas.

Harald

-- 
`Experience is the best teacher.'