Instead of the manager. This adds multiple lines retrieving
the manager from the context, but throughout the course of
this rework, they will probably be simplified.
This is mostly a nice touch of integration for when
using the Night Light feature. It can be disabled by
switching the 'follow-night-light' dconf key to false,
but no user interface widgetry was added.
The "New Event" menu item is confusing and misleading, since
it is contextless item that has a context-aware action. The
result varies depending on which view you are, but this is in
no way communicated.
So just remove that, and all the GcalWindow API that is not
used anymore altogether.
GcalManager is basically an object that is shared
among classes that need to modify calendars, while
GcalClock is just a wall clock implementation.
Move it to GcalApplication, so that objects without
access to GcalManager can still access the clock.
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
The first outcome of the test suite. This separation does
not make much sense now, and GcalManager is basically a
holder for all data types.
This commit moves the GSettings to the GcalManager instance
of the application. Of course, in the future, the plan is to
split GcalManager nicely.
Commandline arguments are now handled by the primary instance of the
application. And so outputs for --help, and --version are shown there.
Not where the application is invoked.
So hook to handle-local-options so that the arguments are parsed locally,
and sent unparsed ones to primary instance in case it is required.
As a side effect, the arguments passed to --date and --uuid are not updated
in the primary instance on subsequent runs (ie, when the primary instance
is already up and running). So check the commandline arguments as they
arrives rather than saving them to a variable, which won't then be updated.
https://bugzilla.gnome.org/show_bug.cgi?id=773152
Calendar now segfaults due to faling function
gtk_style_context_remove_provider_for_screen in application finalize method.
As application finalize method is called only when the application closes,
there isn't any hard requirement to cleanup every trailings. Operating
System shall take care of that.
So removing the failing functions so as to not segfault on exit anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=773871
