When adding an event with the same start and end dates and
times, the event effectively spans 0 minutes, leading a division
by zero and causing varius UI glitches.
Fix that by making sure events span at least 1 minute.
https://bugzilla.gnome.org/show_bug.cgi?id=777414
Because we were blindlessly decreasing the search hit counter without
considering that we could've not removed anything, the search hit
counter is going nuts.
Fix that by properly checking if something was removed, and only decrease
the search hit counter when that happens.
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.
On week view, we want to create events that span 1 day, but with
different hours. The current code of Quick Add popover, however,
doesn't support that, as the only test case up to now was month
and year views - both not making use of timed events.
Fix that by adding the necessary comparisons, adapting the strings
and allowing events with the same date but different times.
When two or more events overlap, the week grid almost
does the right thing and correctly calculates the width
of the events.
It fails, however, in calculating the position of the
events.
This commit introduces a simple yet efficient way to
position the events. It uses a temporary range tree to
efficiently store already positioned widgets, and checks
for their indexes looking for a hole to position the
new event.
In order to correctly implement the week grid, we must
have a fast and optimized data structure to handle date
intervals.
This commit introduces, then, GcalRangeTree. The range tree
is an augmented AVL tree designed to handle intervals (i.e.
ranges) rather than single-dimensional keys.
It is a very good struct since common operations like insert
and removal are O(log n). It also is optimized for the ranges
we work on, so the nodes only take up the absolutely minimum
space required.
I'm simply too tired to split them off in separate commits,
so let me explain here. This commit:
* Remove debug messages
* Fixes many off-by-n and const-mistakes
* Simplifies the code
The current code does not move the remaining events up and,
when changing the week header various times, it ends up
showing completely bogus events at bogus positions.
Fix that by properly moving events up when removing them.
Instead of using a single, giant GList to store all the available
events, use an array of sorted GLists.
This commit adds temporary debug messages, beware the huge output.
By moving the drawing area to a separate place, we're
able to avoid having to manually calculate the sidebar
width.
Also, because we can, the drawing code was simplified a
little bit by moving the bottom border to CSS.
If the header is a GtkScrolledWindow, all the content
(including the top labels and week names) are scrolled.
This is a wrong behavior, since only the events should
be scrollable.
Fix that by making GcalWeekHeader a GtkGrid, and adding
the scrolled window in the correct position.
It looks like the cursor at the "Notes" section of the
edit dialog has no vertical space to breath, and it's
a little bit annoying as it runs away from the expected
position.
Fix that by adding a small margin at the top and the bottom
of the text view at the "Notes" section.
If we scroll to a month that has no event widget to
display, the redraw is not dispatched and looks like
Calendar is broken.
Fix that by always queuing a redraw.
Instead of using the old GLib boilerplate code, use the new
utilities and simplify the code a little bit. This also allows
us to remove the private field of month view.
Following the previous work on month view, this commit
implements scrolling capabilities to Year view. We do
this not only with the :scroll-event, but also using the
:edge-overshot signal of GtkScrolledWindow.
It is very natural and intuitive to try and change the current date
by scrolling. The current implementation of the Month view, however,
blatantly ignores scroll events.
Fix that by hearing to the scrolling events and changing the month
when the scroll is enough.
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.
