The previous approach was causing an error on the animation code of
GtkStack because the search-view's GdkWindow was banishing before
the end of the animation.
The call to GtkWidget::unrealize was destroying GtkStack window because
of the reference increasing on GcalWeekView when setting the
parent_window as its own.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=739554
This patch mainly implements GCAL_RESPONSE_SAVE_EVENT. It updates the event correctly, no matter in which source it is.
Signed-off-by: Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
There are some other changes:
1. Renamed widget class to "event-widget" to avoid collisions
2. Added contrasting event title coloring
3. Use gtk_render functions
GcalEditDialog::clear_data was clearing the summary on the internal
ECalComponent instance. Blocking signal handler call allow to clear the
widget without clearing the component.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=739307
This works in conjunction with code implemented in GcalSubscriber where
the ownership of the event widget passes into the container, so the
container is free to delete it in case it does not fit into the range
represented by the view.
GcalView::draw_event overlapped a bit with GcalView::will_add_event, so
the same reasons for removing one stand for the other.
GcalView::clear was a hack for the composited GcalDayView which has
gone, and was a bad experiment.
As Lapo rightfully explain, providing a button there for creating a new
event is way to prominently and might divert users of the intended click
on a cell behavior to create an event.
New event will be also accessible from the hamburger icon on the left of
the header-bar and Ctrl-N key shortcut.
Also as Lapo suggestion Today button fall better on the header bar than
between the navigation buttons.
ECalDataModelSubscriber interface notify each view only about the events
beloging to the subscribed range so there's no need of checking if the
event widget will be added.
The safety check of not adding the same widget twice its stil being made
on each GtkContainer::add implementation.
By making GcalMonthView a descendat of GcalSubscriber it gets
implementation for each of the methods on ECalDataModel subscriber and
utomatically gains the functionality of adding and removing events widgets
GcalSubscriber abstract class is meant for handling the implementation
of ECalDataModelSubscriber interface. The code in each vfunc implemented
is the same for each view, then it makes sense to have a class holding
these implementations and make every views descend from it. This class
sits in the middle between GtkContainer and each of the views.
