Currently, we keep the to-be-edited event of the Edit
dialog when it sends any response. However, this can
cause issues since we can edit the event, press Esc and
see that the event didn't change but Edit dialog keeps
the changes.
Fix that by always resetting the edited event to NULL
after a response.
https://bugzilla.gnome.org/show_bug.cgi?id=778644
When finalizing the application, it is possible that the main window
had already been destroyed and the Gtk+ CSS machinery to stop working.
We currently try to remove the CSS providers from screen when finalizing,
which (i) has no effect, and (ii) causes a segfault.
Fix that by simply destroying the CSS providers, and not trying to
remove them on finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=773871
The Week view exposed a bug where we had different
CSS selectors for the exact same label. This made
them look inconsistent, with different colors and
paddings.
Fix that by ensuring they all use the same style
class. The Year view drawing code needed to be
reworked a little.
https://bugzilla.gnome.org/show_bug.cgi?id=778391
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.
