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.
It seems gtk_style_context_add_provider_for_screen increase the ref
count of the GtkCssProvider (maybe copy it to GdkScreen and this isn't
releasing it correctly). We're forcing an _unref to keep the destruction
process working as expected. Previously gtk_css_provider_finalize was
not called at any time on the closing process.
Fixes destruction process. Calling g_application_quit skip the reference
decreasing process of GApplication and that resulted in a bunch of
_finalize methods not being called. By removing the windows GApplication
finalize properly.
Initial work implementing ECalDataModelSubscriber interface. As
explained before, on each set of GcalView:active-date property the range
the view its subscribing gets updated. Allowing this to obtain
notification through ECalDataModelSubscriber::components_added and
ECalDataModelSubscriber::components_removed vfuncs.
Since a pointer to the GcalManager instance it's needed at construction
time and GtkWindow::application property is not set as construction
property. We need to add this property to have a reference to pass to
the instantiated views.
Just like the views, this isn't ref/copied or anything, it's just a
dummy pointer. The application objects is the respnsible of handling
GcalManager instance initialization and destruction.
Events related signals from GcalManager had been removed previously,
those handlers aren't needed anymore.
Second, there's no need to inform GcalManager of the new range since
every view will do so internally. Also, there's no need of removing
children widgets from the active view, since each view will do so on its
own by implementing ECalDataMoelSubscriber::components_removed vfunc.
