Earlier the height of event-widget with duration of 30 mins or less exceeded
the desired space in week-grid. As height available was not checked beforehand,
this resulted in some event-widgets getting height assigned which was more
than the height available.
This patch fixes the erroneous assignment of event-widget's height by first
comparing the required height with the available height. If the required
height exceeds the available height, then the display-text is given as a
single-line for the widget to fit properly.
https://bugzilla.gnome.org/show_bug.cgi?id=778070
When dragging events around, the cursors show a + as opposed to a
an arrow indicating that the event is being moved. This can confuse
users.
The fix is to tell GTK that the drag being performed is a move.
https://bugzilla.gnome.org/show_bug.cgi?id=774922
Instead of using a pixbuf and relying on the underlying GdkWindow,
simply perform a custom draw() over a manually created cairo context
and avoid nasty crashes.
When the event widget's GdkWindow receives an event scroll,
the event is lost because it doesn't handle it. It should,
however, propagate the scroll event so that the container
is able to properly parse it.
Fix that by making GcalEventWidget listen and propagate
scrolled events.
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.
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 an event is earlier than the current date, it gets faded out.
Every event from the same calendar showed the same shade of color, either it was an old, current or forward event. That could be tricky for the user to identify which ones were already over.
Now, events that are earlier thant the current date are half transparent to allow the user to easily track where the current date/time is.
https://bugzilla.gnome.org/show_bug.cgi?id=746267
Instead of breaking the vertical alignment of events by
drawing icons both at the start and end of the widget,
only draw them by the end.
This commit also improves drawing for RTL locales.
We differentiate all day events from timed events by their
ordering, but we don't give any visual clues of this
differentiation.
Fix that by adding the start time of the event when it's a
timed event.
https://bugzilla.gnome.org/show_bug.cgi?id=753131
When we finalize, we remove the event. Normally this means
that the event also gets finalized, as the widget almost
always holds the only reference to the event.
However, there are some rare cases where we finalize the widget
but not the event. If the event the updates the color or the
summary, we try to redraw the finalized widget and crash.
Fix that by disconnecting the signals when finalizing the widget.
The compare_for_single_day() method is reproducing the
same functionality from gcal_event_compare(), and the only
consumer is the Year View. So, for now, simplify the
comparing function and put it in year view file.
Also, this commit vastly improves and documents the year
view's algorithm to add events to the sidebar list.
For now, we're going to convert every widget time into our timezone
without question. Further along the way, when we have a more complete
edit-dialog we can handle this in a less strict manner.
Size requisition previously add margin to the size requested. Margin
should be taken into account outside of the widget. Moving margin to the
container and use border, which previously was not used.
This compare function is made to sort using the same two methods used
before but together, giving priority to the longer events.
The idea is sort event properly on year-view's sidebar.
This function will probably change later.
When an event is marked all day, the end-date is always one day ahead of
the true end of the event, and both dates are marked as date. We need to
take this into account.
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.
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
