GNOME Bugzilla – Bug 150132
Cities should have support for multiple Locations
Last modified: 2004-12-22 21:47:04 UTC
from bug #139820 Cities which have multiple weather stations (ie. Boston) should have those stations available in a sub-tree of the city. XML should be formed similar to: <state> <_name>My State</_name> <location> <!-- Translators: Location in My State --> <_name>My Location</_name> ... </location> <city> <!-- Translators: City in My State --> <_name>City with Many Locations</_name> <location> <!-- Translators: Location in City in My State --> <_name>a location</_name> ... </location> <location> <!-- Translators: Location in City in My State --> <_name>another location</_name> ... </location> </city> </state> This will allow for a much greater list of weather locations, as well as giving much finer grained control over the weather location you choose.
Should I check this in now? And with or without the additions from the METAR list?
The branch for 2.9 is about a month away by my reckonin'. I want to get it merged into 2.9, so feel free to start working on it now. Then we can get it merged straight away for 2.9. In order to make things smoother, we should start with a patch against the XML parsing, and display code, with perhaps a test location (like Boston) in the Locations file. Once we're happy with that, we can go through the locations file, and add and change things until we're happy.
Created attachment 31599 [details] [review] Proposed fix with several examples
Comment on attachment 31599 [details] [review] Proposed fix with several examples You're on the right track. However it's not quite working. >+ * *untrans_city untranslated city name or NULL >+ * *trans_city translated city name (un)trans_name are ** yet these are only * > * **untrans_name: returns untranslated name > * **trans_name: returns translated name ^^ like this > /* If this location is actually the currently selected one, select it */ > if ( loc && weather_location_equal (new_loc, loc) ) { This appears to have stopped working. >+ /* TRANSLATOR: This is 'city' / 'location' */ >+ location->untrans_name = g_strdup_printf(_("%s / %s"), untransCity, Personally, I don't much care for this. I would just display "City: Acid Rain". Plus for me it appears to be broken and is displaying "Australia / Perth". You might also be leaking some memory, but it's hard to tell, the entirely of gweather leaks memory (have a look at bug #150707). Is it possible to plug up these issues?
Sure thing: I should be able to get to it tonight.
Or tomorrow night.. > Personally, I don't much care for this. I would just display "City: Acid Rain". So the only way to know which city's station is used is to change location? > Plus for me it appears to be broken and is displaying "Australia / Perth". Sorry: just noticed that -- will get that too.. wrt 150707: should I keep those fixes separate or combine them here?
> So the only way to know which city's station is used is to change location? I'm tempted to say yes for simplicity. Most people don't want to read "Perth (Perth International Airport): Few Clouds" They just want "Perth: Few Clouds" Does anyone else have any opinions on this? If you have fixes for #150707 then put them in. We'll then look at #150707 later and see what leaks remain.
Created attachment 31963 [details] [review] Second approach This avoids the "Austrailia/Perth" problem by creating an intermediate level procedure specifically for cities. The location is displayed as the city name instead of "city/station". I'm a bit partial to the latter since the cases I'm generally familiar with (Boston, New York) often qualify their temperature announcement with which station was used. OTOH I can see where the "City / City International Airport" comes across as redundant. Another option would be to include the choice in the preferences menu.
Comment on attachment 31963 [details] [review] Second approach Ok, I've committed this. Thanks for your excellent work on it. How does this patch affect bug #150707 ? I'll leave this bug open for the time being so that we can slowely move more places to using the <city> node as appropriate. While only slightly related, are there any new developments on bug #68616 ?
Thanks! I had added a few lines of code that would avoid a leak if some tag were to be used more than once for a location. It's more of a defensive move, though: I didn't see any actual instances in the Locations.xml.in file that would lead to it. I'm not familiar enough with valgrind yet. Once these changes are available via anonCVS I'll merge with my other changes for #68616 and submit using just the locations that are within the "city" tags, then the rest of the changes to Locations.xml.in after that.
I guess this bug can be closed.