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.
This commit introduces the ability in Edit dialog to
display the currently available alarms, as well as basic
editing of these alarms.
Currently, only removing the alarms and modifying it to
play a sound or not is available. The following up commit
will add the ability to add new alarms.
Instead of keeping a ref to the GcalEditDialog::select-calendar
action, use the builtin facilities and simplify the action
handling by using a const structure.
This is also a preparation for the next few commits where alarms
will be added.
The edit dialog time picker didnt take into account GNOME's hour format.
The edit dialog time picker didnt take into account GNOME's hour format because the desktop settings clock-format from gcal-window was not passed to gcal-edit-dialog.
Now the data is passed through the function gcal_edit_dialog_time_format and everything works as required.
https://bugzilla.gnome.org/show_bug.cgi?id=703321
