Fallback location provider

[Phyks]

Hi,

I'm often not at home and I'd like to use GeoClue provider to not worry about updating my location when using redshift. But it depends on an internet connection, which may not be available at startup.

I saw in an issue that you are planning to enhance this provider to check periodically for the location. But would it be possible to implement also a fallback mechanism ?

For example, if my internet connection is down and redshift can't get the location from the geoclue provider, then it uses the manual configuration instead, and will use again the location from the geoclue provider when it will be available ?

Thanks

[jonls]

I think that is reasonable. I'm wondering if it should also cache the last location returned by Geoclue and use that if Geoclue becomes unavailable. Then the question is, should the cache or the manual setting be preferred?

[Phyks]

👍 for the geoclue caching.

I'd say the cached value as you can still temporary force the manual value to be used by disabling the geoclue method.

[maandree]

I agree with Physks, but definitely print a warning.

[allentiak]

More information on Launchpad: https://bugs.launchpad.net/ubuntu/+source/redshift/+bug/868904

[igorrs]

Complementing the great ideas already suggested, I'd propose the following scheme:

• Don't exit if no network connection is available. Just keep trying to query GeoClue and, meanwhile, use cached coordinates.
• Cache the last used coordinates, no matter if they came from GeoClue or were specified manually.

This way:

• Users that don't expect to have an Internet connection can set the coordinates manually (once) and have them cached.
• Users that don't have a connection at startup (but usually do afterwards) can have cached coordinates used at startup, but updated when possible.

[eddie-dunn]

@igorrs, that solution won't work if it fails the first time you try starting the program (happened to me).

It was kind of confusing for me when redshift-gtk wouldn't start, and I had to guess that manually providing lat+long would magically make the program work. Imagine some total n00b trying to run it, and have it just silently fail. They will (rightly) conclude that the program is broken.

I say that if a location is not available, for whatever reason, the program should gracefully fallback to using the local time for setting the redshift. Red between 21:00 and 06:00 would be fine, I think.

[llucax]

It was kind of confusing for me when redshift-gtk wouldn't start, and I had to guess that manually providing lat+long would magically make the program work. Imagine some total n00b trying to run it, and have it just silently fail. They will (rightly) conclude that the program is broken.

What you could do in this case is start the daemon but just let the screen untouched until you can get a location (probably showing a warning to the user). Not starting the daemon at all doesn't make all that sense :)

[llucax]

I say that if a location is not available, for whatever reason, the program should gracefully fallback to using the local time for setting the redshift. Red between 21:00 and 06:00 would be fine, I think.

You could probably get a bit smarter and adjust that given the date and timezone...