Changed internals data structures in order to handle allocation of
multidays events properly.
Modified GtkContainer::add, GtkContainer::remove and
GtkContainer::forall according to this new internal structure.
Commented out GcalView::get_by_uuid since it might get deprecated.
Added GcalEventWidget::is_multiday to check if an event span more than
one day.
Added GcalEventWidget::compare_by_length which compares two event
widgets according to the duration of the events they represent.
There's a bunch of stuff missing here, but this code is already working.
This includes only part of the drawing code, I already take into account
here LTR and RTL languages.
Here month-view make use of classes for styling different regions of the
grid, there are:
1. header class, which is used for the font and color details of the
days naming on the top of the grid
2. current class, which is used for drawing the current day number and
its background
3. lines class: which set the color property of the lines in the grid
4. :selected pseudo-class is used for drawing the font on the days
marked when creating an event. This will work as well for keyboard
navigation
What's missing here:
1. properly update click/press marks to new model
2. draw border around the selected days
Fix the sigsegv in edit-dialog and event-widgets when there's no
end-date set.
Set a guard in Utils::gcal_dup_icaltime function.
There's still some problems with the events showing the first time but
not anymore.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=736002
GcalWindow got connected to GcalManager, and pass just created component
to GcalEditDialog
GcalEditDialog gained support to handle component not committed to
manager singleton instance yet.
The ::remove_event handler was not connected to the GtkRevealer so it
was not executing itself when the notification was closed. That caused
the application never removed any events. Fixed now.
Probably I can load the GMenuModel of the popover directly but I don't
know exactly how, and I've asked already and you can set bindings using
builder's ui file, just like before I don't know how at this time.
Previously the scaling was made to the size of the text layout which
caused a blurriness of the icon. Making its size a multiple of 16 made
the icon preserve its sharpness.
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
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.
