Re: Maybe deprecating libgweather

[Giovanni Campagna <scampa giovanni gmail com>]

On Tue, Aug 30, 2016 at 2:32 AM, Bastien Nocera <hadess hadess net> wrote:

On Tue, 2016-08-30 at 10:19 +0100, Allan Day wrote:
> Giovanni Campagna <scampa giovanni gmail com> wrote:
> ...
> > Any comments / opinions?
> >
>
> The dropdown list of search results that libgweather provides isn't
> great, so  +1 from me.

I've wanted libgweather to move to using geocode-glib for a while, so
this would be useful. But we'll still need an offline database for
those applications that don't need or can't use the network (gnome-
clocks, gnome-initial-setup and gnome-control-center I think)

libgweather does use geocode-glib internally, and has for a while (and that has drastically reduced the number of bugs i get to fix the location db)

I am not sure the offline case is that important. In the initial setup case, aren't you showing the network page before the timezone page to do geoip anyway? And if the network is not available, would it suffice to use the olsom timezone db, given the map is clickable?

Whereas for clocks or control center, it's a safe assumption the network will be there, because they are run in a normally set up session.

 

This could be provided by geocode-glib though, meaning we could stop
relying on a weather library to provide locations. And we'll still need
a "drop-down" for those.

 

 Anyway I would not be opposed to splitting the location part out of libgweather and into geocode-glib. Maybe dropping countries and administrative divisions (because a static list of countries is usually a bad idea, like a map or a list of flags) and doing just cities?

Cheers,

Giovanni