GNOME Bugzilla – Bug 685433
Names of places change across app restart
Last modified: 2013-02-01 21:26:04 UTC
I just added a couple of clocks, specifically for Boston (in MA) Copenhagen (in Denmark) but when I restart the application it says Cambridge Kastrup which is close but not what I want. I'm using Fedora 18 and gnome-clocks-0.1.3-2.fc18.noarch
Totally agreed. libgweather is not being helpful...
Yes, this is a problem in libgweather, and it was caused by me overlooking this case when designing the find_by_station_code API. Another possibility that I thought at the time (short of rewriting the DB to have an unique ID) was to serialize a location like a GtkTreePath, that is as a sequence of integers starting from world down to location. Alternatively, you take advantage from the fact that yes, multiple locations have the same code in the DB, but they all refer to the same weather station, and it's only the parent-child relation that is wrong. So if you avoid accessing the parent (for example by storing the city name), everything should work fine. This is btw what GWeatherInfo does for the default location.
Created attachment 230429 [details] [review] World clocks: use the new serialization capabilities in libgweather libgweather now can transform a GWeatherLocation into a GVariant and back, and can compare two GWeatherLocation for equality. Use that ability to replace our handling of METAR codes and fix the inability to have two cities that happen to share a weather station in libgweather's database.
Turns out that you really want to have the same GWeatherLocation, or at least you want something close to it, for example to have the right sun calculations, so the serialization format is more complex than name + metar code, but it's private, so it's not your problem really.
*** Bug 688481 has been marked as a duplicate of this bug. ***
Review of attachment 230429 [details] [review]: Patch looks great, thanks for looking into this! ::: gnome-clocks @@ -33,3 @@ else: ENV_PATHS = { - "GNOME_CLOCKS_DATA_PATH": "/usr/share/gnome-clocks/", This part should not be committed... and you should not need to edit it either ;) The idea here is that you put something like the following in jhbuildrc os.environ['GNOME_CLOCKS_DATA_PATH'] = '/opt/gnome/share/gnome-clocks' os.environ['GNOME_CLOCKS_IMAGE_PATH'] = '/opt/gnome/share/gnome-clocks' os.environ['GNOME_CLOCKS_LOCALE_PATH'] = '/opt/gnome/share/locale' ::: gnomeclocks/world.py @@ -39,2 +39,2 @@ def save(self, clocks): - location_codes = [c.location.get_code() for c in clocks] + locations = [c.location.serialize().print_(True) for c in clocks] I think you can simply cast to str instead of using .print_()
Attachment 230429 [details] pushed as 52377a0 - World clocks: use the new serialization capabilities in libgweather
As discussed on irc, when loading a previosly saved file we should just get a null location, which would give us the chance to convert old clocks or at least ignore them silently. However even after a fresh rebuild of libgweather I get Traceback (most recent call last):
+ Trace 231252
self.win = Window(self)
self.world = World()
self.load_clocks()
self.clocks = self.storage.load()
variant = GLib.Variant.parse(None, l, None, None)
return info.invoke(*args, **kwargs)
Fixed as part of bug 689487