Port to Geoclue2

[jonls]

Development on the original Geoclue has stopped and there is still a ton of issues with it (most importantly random segfaults), so it seems reasonable to move to Geoclue2 as soon as possible as future improvements will happen there. (As an example this bug https://bugs.freedesktop.org/show_bug.cgi?id=39234 basically means that the new dbus-service branch of redshift crashes on every startup; it is marked as WONTFIX).

Geoclue2 has no C library interface so it is necessary to go directly through the DBus interface. It seems that the high-level DBus API in Gio (https://developer.gnome.org/gio/stable/) can be used. I don't know if it is worthwhile to set up gdbus-codegen to generate an interface or if it is easier to just instantiate GDBusProxy objects. As with the old Geoclue code I don't think we can easily get location updates without replacing the core of Redshift with a Glib main loop (also worth considering).

Another consideration is whether Geoclue2 is mature enough. I did a quick test to check that it works (Geoclue2-2.0.0 in Fedora) and it seemed to work although the implementation has to be done carefully. One thing in particular is noteworthy: It appears that the location cannot be read before a LocationUpdated signal is sent. This means that a main loop is needed even for reading the current location, so Geoclue2 support cannot be easily added to the current Redshift implementation.

[xrchz]

👍
Can this be broken down into subtasks? (e.g., maybe Glib main loop should be a subsidiary issue?)

[jonls]

@xrchz , sorry for the late reply.

I recently ported Redshift to OS X and using the CoreLocation framework as location provider also requires a main loop. I realized that I can just run a main loop inside the location provider for a few seconds until the location becomes available, then stop the main loop and return the location to the main redshift loop (i.e. redshift.c). Of course we should prefer a proper solution that allows Redshift to obtain continuous location updates but I think this is a fine solution in the meantime. This should also be possible as a solution for Geoclue2 as well, and this is how I'm currently trying to add Geoclue2 support.

When we have that part working we can come up with a plan for using a Glib main loop in redshift so that we can get continuous location updates. Having the main loop inside the location provider means that part of the implementation is already there, it just has to be expanded and moved to redshift.c substituting the current loop there. However, these changes are probably better suited for a major revision of the code ("Redshift 2.0" or something like that). I already had a few complaints when I mentioned moving to a Glib main loop that it adds too many dependencies for Redshift. I think it may be necessary to do so, but it has to be done carefully.