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
meson generates the config.h file with multiple defines to be used
as guards, in the same way as autotools does. However, some of them
are not used.
This patch removes those unused defines.
https://bugzilla.gnome.org/show_bug.cgi?id=790234
Following the new meson porting guidelines, this patch renames the
build options. The list of changes is as follows:
- Remove the enable prefix from boolean options.
- The character separator from multi-word options has been changed
to underscore.
https://bugzilla.gnome.org/show_bug.cgi?id=790234
gnome-calendar uses 1 as the project's default warning level.
However, meson already uses this level as the default warning level.
This patch removes the warning level from project's default options.
https://bugzilla.gnome.org/show_bug.cgi?id=790234
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.