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 555468 - weather part of clock applet is no longer usable
weather part of clock applet is no longer usable
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: clock
2.24.x
Other All
: Normal major
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-10-07 21:38 UTC by Ralf.Nieuwenhuijsen
Modified: 2008-12-11 18:23 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
patch to add some inline documentation (7.14 KB, patch)
2008-10-08 20:34 UTC, Dan Winship
committed Details | Review

Description Ralf.Nieuwenhuijsen 2008-10-07 21:38:15 UTC
Please describe the problem:
In the past there was the ability to configure a location from a preset list of places. This would then automatically provide lat. and lang. and weather info for the area.

However, this functionality appeared to be stripped out, with no clue given how to set the weather part of the clock. 

When I submitted that bug report to launchpad, it was explained to me that the name of the location has an auto-complete entry. And when, instead of typing the name of the location, the location is selected there, the coordinates are set. And mysteriously; even the weather is now reported again.

The thing is, I'm not an elite hacker, but I'm not Ms. Simpleton. If I can't figure this out, I'm quite sure very few (except hardcore puzzle fans) will figure out how this works. Even less new users will even know it's possible to get weather info from their clock applet, because it no longer has a default location setup based on the locale.



Steps to reproduce:
1. Look at your clock applet: no weather info reported, no location configured
2. Try configuring a location, because somebody told you that you would get weather info

3. Search google, report bugs, to get info on how to actually get the coordinates for your town and the weather info. Turns out you have to use the auto-completed suggestions. 

4. But not all towns are in there; and they are sorted by the name of the town, not the country. So I have to go through the whole alphabet, just to see all the options and find a nearby town.


Actual results:
I get frustrated. 

Expected results:
To have it to some sane default value for my locale. 
To have it communicate that it actually supports to show weather information.
To have it make obvious that by selecting from a town from a list, i'm getting weather information and coordinates automatically. (perhaps with a find button like it was?)
To have the list of towns sorted by country, so it's easier to find a nearby city.


Does this happen every time?
Yes, this happens every time.

Other information:
Please just revert behaviour back to how it was.

Although the current solution appears clever, configuring the clock and weather applet is not something we do often. The interface needs to be intuitive and communicative; not efficient or clever.
Comment 1 Dan Winship 2008-10-08 20:34:58 UTC
Created attachment 120229 [details] [review]
patch to add some inline documentation

This patch adds the note:

  (Type a city, region, or country name and then select a match from the pop-up.)

underneath the location entry (which hopefully makes it more understandable, and also points out the fact that you can just type a country or state/province name, and see all cities within that region).

Would this help?

This would be a string freeze break.
Comment 2 Ralf.Nieuwenhuijsen 2008-10-09 05:49:46 UTC
I think this will take away most if not all of the pain.

The only future thing I would focus on is having _some_ location as default, when none is configured .. so, people see a sun or cloud and with a mouse-over notice .. hey .. that's not my town .. (then they go in and change it). 

Perhaps it was downstream customisation, but it did previously behave like that, which is how I discovered that the clock applet could do the weather thingie all on its own.

But I think that might be wiser to target with the next release. Should I file a separate bug about that?
Comment 3 Dan Winship 2008-10-20 13:13:42 UTC
The old gweather applet has a default location, but I don't think the clock ever did. Please file a separate bug about that.

Meanwhile, the 2.24.1 deadline snuck up on me, and even assuming the string freeze break were approved, there's no way this could get translated by tonight, so this will not be in 2.24.1.
Comment 4 shirish agarwal 2008-10-31 03:27:07 UTC
So when can we see this patch in action? In a 2.24.2(November 24) or 2.25.1 (November 3) . Would be interested to know. 
 
Comment 5 shirish agarwal 2008-10-31 03:28:31 UTC
just to add those dates were taken from http://live.gnome.org/TwoPointTwentyfive/
Comment 6 Dan Winship 2008-11-17 15:02:17 UTC
Vincent: are you ok with this patch? Can I request a string freeze break for it for 2.24.2?
Comment 7 Vincent Untz 2008-11-21 16:44:42 UTC
Oops, sorry, missed the mails about this :/ It's clearly too late for 2.24.2 now (unless we want translators to kill us) -- apologies, that's my fault.

On the other hand, I would only have considered this for 2.25 by default, but it's true it makes sense to push this to 2.24. And I got pinged on the openSUSE side to add something like this. Hrm. I'll ask on gnome-i18n what translators think.
Comment 8 Vincent Untz 2008-11-21 16:45:26 UTC
Oh, btw, I think it's better to not have the parenthesis in the label.

(marking as commit after freeze so it gets in when someone branches the panel for 2.24)
Comment 9 Ralf.Nieuwenhuijsen 2008-11-22 15:52:36 UTC
Considering it will likely come with the next version of gnome, wouldn't it be wiser to re-evaluate the setup.

For the weather part of the clock to be functional, you'll need:
  a) let new users know that it can do that
  b) make it clear what to do to get correct weather info
  c) have them do it

Proposed solution:
  a) setup a default location per country or locale 
  b) they click the clock and press the 'edit locations' button
  c) they see a list of locations (you can remove the other preferences, they are locale specific and should just work)
  d) when they want to add a location, can you re-use the world map widget?

I'm not very sure, perhaps, on the distrobutions level it would be wise, to put this in the setup/installation tool.

With Ubuntu we already select a city, so it can guess our timezone. It makes sense it this also selects the weather info at the same time. (that both make use of the same list of cities).

  

Comment 10 Dan Winship 2008-11-23 17:21:34 UTC
(In reply to comment #9)
>   a) setup a default location per country or locale 

This already exists in fact (per-locale). The gweather-applet uses it, but the clock does not.

>   c) they see a list of locations (you can remove the other preferences, they
> are locale specific and should just work)

I am not sure what you mean here.

>   d) when they want to add a location, can you re-use the world map widget?

Not really. The existing map is too low-res to allow this, and also it is politically impossible for us to make it show the boundaries between countries.

> With Ubuntu we already select a city, so it can guess our timezone. It makes
> sense it this also selects the weather info at the same time. (that both make
> use of the same list of cities).

Yes, this was supposed to happen in Fedora for F10, but it didn't. FWIW, you can probably make this work just by having the install-time timezone-picker use the libgweather timezone stuff, and then having it set the gconf defaults for the panel to have a location already configured for the clock.
Comment 11 pablomme 2008-11-23 20:49:05 UTC
I'd like to add that the list of locations available for auto-completion is not as exhaustive as the former searchable list used to be, and does not include all locations for which weather information is available.

For instance, one of the locations I had in Gnome 2.22 could be found as

 Europe > Spain > Canary Islands > Tenerife/Tenerife Norte (Los Rodeos) Airport

in the "Find..." dialogue. After selecting it, the "Location name" was filled with "Canary Islands".

In 2.24 I cannot add this location: searching by Spain gives lots of answers but not this one, and "Canary", "Islands", "Tenerife", "Norte", "Rodeos" and "Airport" don't yield any results.

However I have a computer which I upgraded from 2.22 to 2.24, and the old location selection (which was kept in gconf I assume) still works. So the problem is at selection time. Has the database been trimmed down for some reason?

I didn't find it particularly troublesome to use the auto-complete mechanism, but I did expect to find all my old locations again..
Comment 12 Vincent Untz 2008-12-08 15:22:59 UTC
(In reply to comment #11)
> I'd like to add that the list of locations available for auto-completion is not
> as exhaustive as the former searchable list used to be, and does not include
> all locations for which weather information is available.
> 
> For instance, one of the locations I had in Gnome 2.22 could be found as
> 
>  Europe > Spain > Canary Islands > Tenerife/Tenerife Norte (Los Rodeos) Airport
> 
> in the "Find..." dialogue. After selecting it, the "Location name" was filled
> with "Canary Islands".
> 
> In 2.24 I cannot add this location: searching by Spain gives lots of answers
> but not this one, and "Canary", "Islands", "Tenerife", "Norte", "Rodeos" and
> "Airport" don't yield any results.

This has nothing to do with this bug: this is a problem with the content of the locations database. As far as I can tell, this is still available as "Los Baldíos". If it's not the right name, please file a bug against libgweather.

(In reply to comment #9)
> Proposed solution:
>   a) setup a default location per country or locale 

There's a bug in libgweather for that.
Comment 13 Vincent Untz 2008-12-08 15:27:10 UTC
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
Comment 14 Leonardo Ferreira Fontenelle 2008-12-09 00:06:24 UTC
Shouldn't "pop-up" be replaced by "drop-down list"? (And does that need another string freeze break approval?)
Comment 15 Vincent Untz 2008-12-09 00:56:33 UTC
(In reply to comment #14)
> Shouldn't "pop-up" be replaced by "drop-down list"? (And does that need another
> string freeze break approval?)

It's not really a dropdown list, but yeah, popup might be unclear. If you want to change the string again, please do it on gnome-i18n -- I'm not good with strings, and I'll accept anything as long as there's consensus. (fwiw, yes, this will likely require approval)
Comment 16 pablomme 2008-12-11 18:23:46 UTC
(In reply to comment #12)
> This has nothing to do with this bug: this is a problem with the content of the
> locations database. As far as I can tell, this is still available as "Los
> Baldíos". If it's not the right name, please file a bug against libgweather.

The name's perhaps a bit too specific, but that's OK. Thanks!