Fallback location provider about redshift HOT 8 OPEN

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?

from redshift.

👍 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.

from redshift.

I agree with Physks, but definitely print a warning.

from redshift.

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

from redshift.

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.

from redshift.

@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.

from redshift.

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 :)

from redshift.

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...

from redshift.