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
Using a GDateTime improves consistency with the
other components (ideally, we'll move completely
to GDateTime) and simplifies the code.
This commit adds a new property GcalDateSelector::date
and adapts the API to use GDateTime.
Instead of using the ESource + ECalComponent combination,
use the new GcalEvent class, which wraps up and simplifies
most of the code.
This commit adds a GcalEditDialog::event property, and
adapts the dialog (and everything dependant on it's code)
to use the GcalEvent class.
When we check start & end time selector's sensitivity before
notifying the property change, the check is overriden by the
binding.
Fix that by performing the checks after the notification of the
property change.
By using these properties, we gain the possibility to
bind them to the widgets and save some needless code.
This commit adds GcalEditDialog::writable and ::manager
properties. Other needed properties will be eventually
added in the subsequent commits.
This commit updates GcalEditDialog's code for
it to be a final class. As such, we don't need
the GcalEditDialogPrivate type - we can simply
move our data to the GcalEditDialog struct.
