After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 161388 - changes to the locations file do not propagate to existing users' settings
changes to the locations file do not propagate to existing users' settings
Status: RESOLVED OBSOLETE
Product: libgweather
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: future
Assigned To: libgweather-maint
libgweather-maint
Depends on:
Blocks:
 
 
Reported: 2004-12-15 17:14 UTC by James Henstridge
Modified: 2021-06-09 21:01 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Patch (5.54 KB, patch)
2005-03-09 06:47 UTC, Frank Solensky
none Details | Review
Patch (6.54 KB, patch)
2005-04-16 11:52 UTC, Frank Solensky
rejected Details | Review

Description James Henstridge 2004-12-15 17:14:07 UTC
At the moment I have two weather applets on my panel: one for Perth (Australia),
and one for Barcelona and my timezone is set to European time (+0100).

It is 6PM here in Spain and 1AM in Perth, yet the Perth weather applet shows a
day icon while the Barcelona one shows night.  Both should be showing night time
for this time of day.

I haven't investigated the code, but I'd guess it is an incorrect timezone
calculation.

I haven't tried with the very latest CVS (the last message in gweather/ChangeLog
is dated 2004-12-05), but none of the newer change log messages indicate that
the situation would have changed.
Comment 1 Danielle Madeley 2004-12-16 01:52:36 UTC
Hmm, this was meant to be fixed.

What sunrise and sunset times are you given for Perth? Are they correct based on
your timezone at the moment?

Picking something in GMT+1 (Hamburg) I have a sunrise of 15.33 (8.33) and sunset
of 23.02 (14.02) which seems consistant with European winter.
Comment 2 James Henstridge 2004-12-16 09:57:14 UTC
I just checked, and it shows -/- for sunrise/sunset.  For Barcelona, it gives
08:13/17:25 for sunrise/sunset (which seems about right).

Looking at the prefs in gconf-editor, it seems that there is a
"prefs/coordinates" subkey for the Barcelona applet instance, but none for Perth.

So I tried changing the settings for the Perth applet by switching to a
different location and back again.  Now it lists 22:04/12:17 for sunris/sunset
(I'll have to see if the icon actually changes at 12:17 today).

So it seems that this new feature is not going to work for people simply
upgrading from Gnome <= 2.8.
Comment 3 James Henstridge 2004-12-16 11:47:17 UTC
Okay, after switching to a different location and back (which added the location
information to gconf), the Perth icon shows a night time icon.  So this isn't a
timezone related issue.

Retitling the bug report to take this into account.
Comment 4 Danielle Madeley 2004-12-20 10:56:48 UTC
I have added an entry into the schema. This might help.
Comment 5 James Henstridge 2004-12-22 02:21:22 UTC
How is a schema entry going to help?  Having a schema attached to the key won't
cause it to contain the correct value for the selected location.

In order to pick up new information from the locations file, you really only
want to store a key for the location in gconf, then look up the corresponding
data in the file at startup.

Of course, it takes quite a while to read the locations.xml, which doesn't help ...
Comment 6 Danielle Madeley 2004-12-22 03:53:37 UTC
From my very quick look at that part of the code the other day. gweather will
load the correct values if the current value it reads is DEFAULT_whatever.
Hence, having the schema coordinates be DEFAULT_COORDINATES should solve at
least the miagration part of the problem. I think...
Comment 7 Danielle Madeley 2005-01-09 09:33:52 UTC
This really needs to be confirmed to be working.
Comment 8 James Henstridge 2005-01-10 01:15:35 UTC
It doesn't seem to be working.

I just created two weather applets on opposite sides of the world (Perth and
Mexico).  The Perth one shows as daytime, and the mexico one shows as night
time.  Then I did the following:

1. killall gweather-applet-2
2. run gconf-editor and choose "unset key" for the "coordinates" key in the
   prefs of each applet instance.  This set the value to DEFAULT_COORDINATES.
3. clicked the reload button in each of the two "the applet has crashed"
   dialogs.

At this point, both applets were running and showing a daytime icon.

I had just run "cvs update" and "make install" in the gweather directory so
everything should have been up to date.
Comment 9 Frank Solensky 2005-03-09 06:47:10 UTC
Created attachment 38451 [details] [review]
Patch

If coordinates aren't already set, this patch will find them in Locations.xml
based on the station code.  It's a very quick implementation but seems to work.
Comment 10 Frank Solensky 2005-04-16 11:52:45 UTC
Created attachment 45325 [details] [review]
Patch

Same patch; synch up with current code
Comment 11 Danielle Madeley 2005-08-03 16:51:46 UTC
This needs reviewing.
Comment 12 Allison Karlitskaya (desrt) 2005-08-03 19:42:21 UTC
I'm not convinced that it's a great idea to do a lookup in the Locations.xml
file on every load.  This takes a long time and will add about 5 seconds to
session start time on an averageish (not blazing fast) machine.

Gweather only does Locations.xml lookups when you configure it.  When you load
it it just uses the values in gconf (or the defaults).  This, of course, means
that if Locations.xml is updated then your data won't be unless you switch
away/back-to a location.

I think we'd solve an awful lot of problems if we used some sort of a better
file format for the locations database.  If we had a unique key to refer to
locations (location code?) and an O(lg n) searchable database then we could just
store the unique key in gconf and properly resync the information on every
startup without incuring huge performance hits.

So I'd say: "let's rewrite the file format for 2.14!".

but.... Davyd, what's up with weather.g.o?  If your contact isn't going to make
it happen then we need to start making it happen ourselves.
Comment 13 James Henstridge 2005-08-04 00:21:02 UTC
One of the quickest ways to speed up reading of Locations.xml would be to remove
all the translations.  That'd quickly cut the amount of data that needs to be
processed: one file with locations data, one with translated strings for just
the language in question.

The file for storing the translated location names could be a standard gettext
MO file.
Comment 14 Frank Solensky 2005-08-04 02:43:26 UTC
#12: the intent was that Locations.xml would get loaded in only when necessary.
 If location4 is already set then it should just come in from there.
Comment 15 James Henstridge 2005-08-04 03:02:12 UTC
How can you tell whether the information in gconf is up to date without actually
reading the locations file?

If there is missing data in GConf, you might guess that the missing data might
be in Locations.xml.  But how do you detect the case when data in Locations.xml
has been corrected?

Storing the modification time of the Locations.xml file in GConf would be
problematic in cases where a user logs into multiple machines while using the
same home directory.
Comment 16 Allison Karlitskaya (desrt) 2005-08-04 03:16:54 UTC
I was thinking by version number.  New gweather version = new locations database.

As for the XML file, I'd rather ditch it entirely.

Certainly, it makes sense to keep it in the source, but I think maybe we should
compile it to something mmapable.
Comment 17 Danielle Madeley 2005-12-21 05:33:52 UTC
Ryan, have you done any work on this?
Comment 18 Allison Karlitskaya (desrt) 2005-12-21 16:10:14 UTC
not a thing.
Comment 19 Danielle Madeley 2006-01-06 03:38:53 UTC
Marking this patch as rejected to get it off my list.
Comment 20 Dan Winship 2008-06-18 17:34:55 UTC
Moving libgweather-specific bugs out of gweather-applet
Comment 21 GNOME Infrastructure Team 2021-06-09 21:01:51 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgweather/-/issues/88.