Bug 71263 - Gnome weather does not update the weather
Summary: Gnome weather does not update the weather
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: gnome-applets
Version: limbo
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mark McLoughlin
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks: 67218
TreeView+ depends on / blocked
 
Reported: 2002-08-11 16:02 UTC by Scott Schmit
Modified: 2007-04-18 16:45 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-08-14 01:20:52 UTC
Embargoed:


Attachments (Terms of Use)

Description Scott Schmit 2002-08-11 16:02:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020724

Description of problem:
No matter what city I pick, or how often I try to click "update," or how long I
wait, the weather applet does not show the current weather and complains that
"Retrieval failed."

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Add Gnome Weather to your panel
2. Right click, choose Preferences, choose a city (a major city like NYC if you
suspect a lack of weather data for my city (though that isn't the case))
3. Wait as long as you like for the weather update to take place (or try to
force the issue with "Update" on the right-click menu)

Actual Results:  Nothing happens. Everything remains stuck at the "no weather to
show" defaults.

Expected Results:  I should see the current weather in my area, or at the least,
if I pick a major city, I should see weather data there.

Additional info:

There is no firewall to block web connections, and other network connections are
working just fine.
There are no errors in .xsession-errors for gnome weather.

Comment 1 Scott Schmit 2002-08-11 20:32:16 UTC
I just figured out how to get it to pick a location--if I *double-click* the
name of the location I want the weather checked for, it will update as appropriate.
I can't say this is particularly obvious behavior, since I know of no other
program requiring this sort of action to select out of a tree. Also, if I bring
the preferences back up, my prior selection is not highlighted.

Comment 2 Scott Schmit 2002-08-13 10:26:45 UTC
To make things worse, the applet consistantly forgets where I am when it is time
to update the weather automatically. (I.e., after about 30 minutes of showing
current local weather, it switches back to its original "huh?").

Comment 3 Tadej Janež 2002-08-13 20:00:25 UTC
Same here. 
Applet always *forgets* which city I chose and the only way to get weather
report is to double-click on a city in preferences dialog box again and again.

Maybe it's solved in GNOME 2.0.1 (RC1)

Comment 4 Havoc Pennington 2002-08-13 20:25:28 UTC
The upstream ChangeLog contains the following (bug numbers are on
bugzilla.gnome.org):

2002-07-16  Kevin Vandersloot <kfv101>

        * gweather-pref.c: properly save the new location when changed
        in the prefs dialog. Adapted from patch by Deepa Chacko Pillai.
        Should fix bug #86631, #88182, and #79787

Are you guys using gnome-applets 2.0.1? It should contain this change, I believe.



Comment 5 Scott Schmit 2002-08-14 01:04:09 UTC
Ok, with 2.0.1 the applet now remembers where I am.

However, should I really have to *double-click* the city name in the tree to
select it? That seems utterly at odds with how the rest of the user interface
works/used to work, but GNOME 2 has changed other things as well. Is this some
new GNOME 2 thing or am I right that this is incorrect/poor behavior?

Comment 6 Havoc Pennington 2002-08-14 01:20:47 UTC
I agree the double-click is wrong, but it is much less wrong than the applet
just plain not working. ;-)

I filed the double click issue upstream, we will get a fix if it's made there:
http://bugzilla.gnome.org/show_bug.cgi?id=90691

Closing bug since the main issue is resolved.

Comment 7 Jay Turner 2002-08-14 17:26:25 UTC
Fix confirmed with gnome-applets-2.0.1-2.


Note You need to log in before you can comment on or make changes to this bug.