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
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)
Follow https://wiki.gnome.org/HowDoI/SaveWindowState
* Use tuples in gsetting schema to save size and position
* Save changes to variable instead of saving to gsettings after every timemout
* Save the changes back to gsettings when the window is finalized.
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.
When deleting events with recurrence, we want to hide the event
widgets according to the modification type. So that selecting
e.g. subsequent in the modification type dialog hides the event,
and the subsequent ones, truly reflecting the operation that will
happen.
Currently, however, the views don't do that, and only hide the
event that was asked to be deleted.
Fix that by passing the object modification type, and adapting the
views to take that into account.
Earlier, the recurrence-dialog would pop up even when user only
wanted to change the recurrence-property of an already recurring
event. This is incorrect behavior.
This patch fixes this issue by making sure that recurrence-dialog
doesn't pop up when the new recurrence-property chosen by the
user is different from what the event already has. In this case,
the user only wants to change the recurence-property of the event
and there's no use of the recurrence-dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
The recurrence-dialog opens only if the event to be modified
is a recurring event and only if the user doesn't cancel
the modification in the edit-dialog. If the user presses
'Cancel' in the recurrence-dialog after making modifications
in the edit-dialog, then no changes are applied.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
Currently, GcalManager always assumes E_CAL_OBJ_MOD_THIS
when modifying or deleting events. Since we're landing
the groundwork for recurrence management, we can't assume
this anymore.
This patch, then, allows GcalManager:modify_event() and
:remove_event() receive the ECalObjModType instead of
assuming E_CAL_OBJ_MOD_THIS. However, this commit does
not add recurrence support yet, and every call to these
functions are still passing E_CAL_OBJ_MOD_THIS.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
g_strcmp0() is used when comparing the display name of the ESource.
This is not a valid sort, because in this case we will get an order
like "a" < "z" < "B" < "Z", but it should be like "a", "B", "z", "Z".
We will use g_ascii_strcasecmp to fix it.
https://bugzilla.gnome.org/show_bug.cgi?id=781231
The function is supposed to run once every minute. So after
the function is run, just remove it from main thread. So that it won't
act as a time bomb.
https://bugzilla.gnome.org/show_bug.cgi?id=781081
The current implementation is deficient in many ways, the
worst one being the it relying on GObject semi-synchronous
property emission.
This issue was exposed by the Week view code, where the active
date was updated, but delayed to reach the Week header and some
events were being added ~before~ the active date changed.
With this work, I was also able to figure out a bunch of code
that relied on this (i.e. luck) to work.
