This magical commit finally implements the Drag n' Drop
feature for Month view by changing the start and end dates
of the events according to the cell where the user drops
the event.
When dragging an event, it is very important to have
a visual feedback of the possible target areas.
As such, add a gtk_render_background() call to render
the drag cell's background.
The previous commit introduced many changes in the way
the conditions are done. Unfortunately, one of these
conditions was only partially fixed.
Fix that by using the correct function to compare dates.
The current code does multiple needless unrefs, uses the
GDateTime API in a wrongly manner and leaks references
all around.
This causes the Calendar application to emit multiple warning
messages and in the worst case, crash immediately.
Fix that by rewriting the critical sections of the code that
deals with the start and end mark cells.
https://bugzilla.gnome.org/show_bug.cgi?id=763641
When the mouse button is released, only the bottom padding was being
taken into account to calculate whether the click was in the "Show
N events" area.
This commit fixes this issue by considering the top padding as well.
https://bugzilla.gnome.org/show_bug.cgi?id=765678
In this commit we change the data type of start_mark_cell and end_mark_cell to GDateTime from gint
Currently, the mark_cell's are gint and while moving across months, they cause a problem as they don't take the new month into consideration but the cell value of the selector.
To fix this, we changed the data type of the mark_cell's and modified all the functions dependant on it.
https://bugzilla.gnome.org/show_bug.cgi?id=763641
The selection mode was drawing a number of boxes on multi-row
selections, resulting in unwanted outlines within the selection area.
This patch adds a multirow mode that just draws the outline of a
selection.
Make cell_{width,height} integers so divison lines always get drawn on
exact grid coordinates, otherwise line calculations could result in
fuzzy lines.
https://bugzilla.gnome.org/show_bug.cgi?id=763217
The line width used for the grid changed over time, resulting in
different values used at different places. Introduce a LINE_WIDTH
definition and use it consistently throughout when drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=763217
In this commit, we modify the position of the selector in the month view when the selector is out of bound of the present month
Presently, the selector in the month view doesn't move when it reaches the border of the month.
To fix this, whenever the keyboard_cell is less than first index of the month, we reduce the value of month by 1 and in the case it is greater than the max key cell, we are increasing the value of month by 1.
https://bugzilla.gnome.org/show_bug.cgi?id=763198
It was possible to select the cell after the last day of the month by
clicking on it.
The days variable is the first day of the month cell + the number of
days in the month, so only cells less than this cell should be
considered actual month days.
https://bugzilla.gnome.org/show_bug.cgi?id=763495
We were mistakenly using the style context of the view
to retrieve the child's margin.
Fix that by retrieving the child margin from the child's
style context.
If an event is from a different timezone, the headers of
the overflown popover should be translated to the current
timezone.
For example, if an event happens at 17h -0300, the translated
hour is 22h +0200. The current code already handles these
differnces, but the listbox row wasn't updated.
After we added GcalEvent::is_multiday(), there is no need to
wrap it in a vfunc anymore.
To fix it, simply use is_multiday() function and get rid of the
vfunc.
The subscriber does not add components who are already
added to the view - and doesn't need to do it. To overcome
that fact, we have to reallocate the events even when
nothing was added.
Fix that by setting the GcalSubscriberView->children_changed
to TRUE and queueing an allocation right after the date
changes.
https://bugzilla.gnome.org/show_bug.cgi?id=762066
Conceptually, we need to compare the event's dates to make
sure we're allocating the widgets correctly, as widget's
dates may not represent the event's ones.
GcalEventWidget added API to automatically change
the widget rendering according to the initial and
final dates. Month view, however, was still handling
it manually (and wrongly).
Fix that by reworking the allocation code, documenting
it and using the apropriate API from GcalEventWidget.
Using libical with libecal means that the dates
are always stored as UTF dates, and we receive the
timezone as the ECalComponentDateTime::tzid value.
This fact was net being considered when adding date
support on GcalEvent, and was causing various issues
when displaying dates.
Fix that by properly handling timezones in GcalEvent.
The current lines are very light and people
with visual issues may not find them easy.
To fix that, make these lines slightly stronger,
enough to make them clearly visible.
https://bugzilla.gnome.org/show_bug.cgi?id=758679
We were calling gtk_style_context_get() with a state
different than that of the style_context, which yiels
warnings.
Fix that by saving, setting the flag and restoring the
context.
Because we're using a simple (gint) cast to round y value of
the clicked point, a negative y was rounding to a valid cell
position and showing the popover even when the user clicked
on the blank cells before the actual month view.
Fix that by properly checking if y is negative.
https://bugzilla.gnome.org/show_bug.cgi?id=755910
For this to be made, some significant changes on the inners
of GcalMonthView had to be done. Later on, I'll do a complete
rewrite of it, deprecating the use of 'sw' and 'k'.
