There is a clear chain of properties that must be respected
in order to make Calendar initialize properly:
1. GcalManager, since it provider access to the settings
2. The initial date
3. GcalWeatherService, that depends on settings and the initial date
This commit brings a few changes that I was too lazy to
split in different commits:
* Remove a few useless arguments in the GcalWeatherService API
* Move the weather management code from GcalWindow to GcalWeatherSettings
* A few style changes
Overview: Clicking the close button in gnome-calendar doesn't always close all the instances of the application. The window is closed, but an instance of gnome-calendar is still running as a gapplication-service, which was probably run by gnome-shell search provider.
The two changes made were as follows:
1) added the argument quit to GOptionEntry
2) added the definition of quit to gcal_application_command_line
Using GLists and GSLists is a bad practice. These data
structures are too much inneficient and GPtrArray has
the advantage of having a free function pointer, so we
can hide the underlying free function from the consumers
of this API.
This also gets rid of another allocation cycle in Month
view.
The deprecated GweatherForecastType enumeration was dropped from the
API, and gweather_info_new() lost the forecast type parameter.
This requires bumping up the minimum version of libgweather we require
to build Calendar. Ideally, we could do a version check and an ifdef
dance to keep Calendar building with the previous versions of
libgweather, but since we were requiring version 3.24 I don't think it's
worth it.
To make it more like the actual code style of GNOME Calendar.
Hope Florian doesn't get (too) mad of me removing and modifying
so much on his code. I'm sorry dude, my OCD didn't allow me to
just flood the gate.
This commit triggers two existing issues:
1. window size calculation
(this breaks month-cells)
2. wrong reference counts in views
(I use :destroy to avoid dangling pointers)
