In month view, when clicking on a day of the month, every event is
initially an All Day event until the user opens the Edit Details dialog
and unchecks the checkbox. This means that the event is originally
created in UTC time, and needs to be explicitly switched to local time.
An event should be considered as recurring only when it occurs
at least 2 times.
So to make sure the number of occurrences are at least 2,
set minimum value of recurrence spin button as 2.
https://bugzilla.gnome.org/show_bug.cgi?id=787054
As we're adding more and more widgets in the Edit dialog,
it is now growing too tall to fit normal screens. Thus, wrap
it in a scrolled window, and let the content height cover
75% of the main window at most.
The revealer widget in edit dialog's event time interval row uses to hide the
time selector widgets when the event is checked as all-day and also reveal the
widgets when not checked as all-day.
Sometimes edit dialog may turn on the visibility of the time selector
widgets when the revealer's animation already starts, causing a flickering of the widgets.
We remove the revealer widget and leave edit dialog to toggle the
visibility of time selector widgets when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=771572
Set the lower value as 1 and upper value as G_MAXDOUBLE
to make sure that any negative number, or a number greater
than G_MAXDOUBLE is not accepted.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
Instead of hiding the individual children of the
repeat_limits_box, hiding the repeat_limits_box
solves alignment issues, where an undesired gap
was visible below the repeat_combo upon opening
the edit-dialog for the first time.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
The number_of_occurrences was forcefully set to 0,
due to spin_button_set_value being placed incorrectly.
When a recurring event with limit_type as
GCAL_RECURRENCE_COUNT, having some 'x' number of
recurrences was opened in the edit-dialog, it showed
'0' as number_of_occurrences in place of 'x', which
is incorrect.
This patch removes this unnecessary line of code
and leads to correct assignment of number_of_occurrences.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
repeat_combo was assigned a value after repeat_duration
combo was assigned a value, which changed the value of the
repeat_duration combo due to the repeat_option_changed
function.
This patch fixes this issue by assigning the value to
repeat_combo prior to repeat_duration_combo.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
Currently, the repeat widgets - repeat_duration stack
and combobox are visible even when 'No Repeat' is
selected in repeat combobox.
This patch ensures that the repeat widgets are hidden
when 'No Repeat' is selected. When not selected,
repeat_duration_combo becomes visible which itself takes
care of the visibilty of the stack.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
An unnecessary condition check for assigning recurrence-changed
property of edit-dialog was causing a segmentation fault.
This patch removes this condition check and assigns the
recurrence-changed property correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
Currently, creating recurring events is not supported
in gnome-calendar.
This patch adds a Repeat combobox with a list of
simple recurrences such as:
* Monday - Friday events
* Daily events
* Weekly events
* Monthly events
* Yearly events
and also a list of recurrence-duration-types such as:
* If an event should repeat forever
* A date until which the event should repeat
* Number of times an event should repeat
It enables the user to create simple recurring events and
even modify the recurrence-property of an already
recurring event.
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
When setting an event, we might modify the event in such a way that
the edit dialog can be broken if it doesn't update.
Fix that by unconditionally updating the event dialog when setting
an event.
Since gcal_manager_get_sources() returns a GList of ESource received
from the hash table, they are not sorted alphabetically. Because of
this, edit-dialog shows the unsorted list.
I added a function for sorting this GList that is case-insensitive.
https://bugzilla.gnome.org/show_bug.cgi?id=781231
The problem is that the end date might change to one before the
start date when modifying the start time.
Treat some cases taking into consideration the start date and start
time related to the fact that an event is spanning all day or not.
Separate the handling of the start date and start time.
https://bugzilla.gnome.org/show_bug.cgi?id=772100
Checking if a new event is already having a source succeeds
for some reason (which should actually fail).
But thankfully we already have an event_is_new gboolean flag.
Check the status of that flag and add or update the event.
https://bugzilla.gnome.org/show_bug.cgi?id=771566
Since now we manually manage the headerbar title and subtitle, setting
them via GtkHeaderBar API won't have any effect.
Fix that by directly setting the subtitle label.
https://bugzilla.gnome.org/show_bug.cgi?id=771565
Currently, all-day multi-day events are displayed inconsistently with
regard to other calendar applications. That is due to strict following
of RFC 5545, which mandates non-inclusive all-day multi-day event end
dates. This commit makes the edit dialog display a faked date for such
events.
https://bugzilla.gnome.org/show_bug.cgi?id=769300
If GcalEditDialog.format_24h is initialized to zero, the call to
gcal_edit_dialog_set_time_format() from GcalWindow will not make
period_combo boxes visible on systems, where 12-hour clocks are used.
This commit fixes that by removing the if statement from the function.
https://bugzilla.gnome.org/show_bug.cgi?id=765370
After adding the button in the headerbar, it is natural to
bring back the ability to move events between sources.
This commit finally includes the usage of GcalManager:move_event_to_source
function, which was implemented ages ago.