After adding the new GcalDateChooser widget, change the
current date selector to use it as the internal widget
of the popover.
The next logical step is turning GcalDateSelector into
an entry.
This is mainly a copy-paste from an old branch authored
by Matthias Clasen. The code style was updated to match
Calendar's one, and the theming was improved a little bit.
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.
Since we're storing the GdkWindow relative to the event widget,
it's usually safer to create a pixbuf of the widget *after* it's
drawn, and not while it's being drawed.
This commit moves the pixbuf retrieval code to the draw-begin
implementation, so we only create the pixbuf when actually
using it.
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.
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.
