GNOME Bugzilla – Bug 161388
changes to the locations file do not propagate to existing users' settings
Last modified: 2021-06-09 21:01:51 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.
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.
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.
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.
I have added an entry into the schema. This might help.
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 ...
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...
This really needs to be confirmed to be working.
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.
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.
Created attachment 45325 [details] [review] Patch Same patch; synch up with current code
This needs reviewing.
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.
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.
#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.
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.
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.
Ryan, have you done any work on this?
not a thing.
Marking this patch as rejected to get it off my list.
Moving libgweather-specific bugs out of gweather-applet
-- 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.