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.
If the user quickly performs a search, open up the calendar
and close it immediately after, the timeout for showing the
event is mistakenly called after the window is destroyed and
causes Calendar to crash.
Fix that by keeping the source id tracked, and realizing it
on finalize().
Currently, the user performs a search in Shell and activates
the result. That should show the edit dialog with the event
being edited, but it's not happening correctly.
Debugging the warnings generated, it was found that the event
was being unref()d and, obviously, that was not what we wanted.
Fix that by only unref()ing the events we don't want, and keeping
the wanted event alive.
Year view was placing popover to mouse click (x,y) position. That was a
little odd because sometimes popover was placed above the selected day.
This patch address that by placing popover always out of the day box.
When selecting the whole month or more than one day, popover will also
be placed out of the month box. reducing the chance to cover selected
days.
https://bugzilla.gnome.org/show_bug.cgi?id=743306
This magical commit finally implements the Drag n' Drop
feature for Month view by changing the start and end dates
of the events according to the cell where the user drops
the event.
When dragging an event, it is very important to have
a visual feedback of the possible target areas.
As such, add a gtk_render_background() call to render
the drag cell's background.
Ideally, every single view will support drag and drop. So
let's just assume that and make the event widget set itself
as a drag source, and let each view set itself as a drag
target.
When we modify an event, the start date may change
and there is no way to retrieve it back. Since we're
relying on the start date to get the cell number and,
remove the widget, it leads to a crash because the
widget is not removed.
Fix that by brute-forcely search the widget in the
correct table.
The current implementation of the Year navigator gives
absolutely no clue that the days are actually selectable,
which may confuse some users.
A simple way to inform the user that the Year navigator
is actually interactive is the hovering effect.
Fix the lack of feedback by adding the hover effect to the
year navigator.
https://bugzilla.gnome.org/show_bug.cgi?id=762462
The view had a maximum of 6 month columns, leading to a huge amount of
vertical spaces, so it was requested to reduce that.
The maximum number of columns was reduced to 4, so the view will have a
maximum 4x3 months layout.
https://bugzilla.gnome.org/show_bug.cgi?id=753533
The previous commit introduced many changes in the way
the conditions are done. Unfortunately, one of these
conditions was only partially fixed.
Fix that by using the correct function to compare dates.
The current code does multiple needless unrefs, uses the
GDateTime API in a wrongly manner and leaks references
all around.
This causes the Calendar application to emit multiple warning
messages and in the worst case, crash immediately.
Fix that by rewriting the critical sections of the code that
deals with the start and end mark cells.
https://bugzilla.gnome.org/show_bug.cgi?id=763641
