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
The edit dialog time picker didnt take into account GNOME's hour format.
The edit dialog time picker didnt take into account GNOME's hour format because the desktop settings clock-format from gcal-window was not passed to gcal-edit-dialog.
Now the data is passed through the function gcal_edit_dialog_time_format and everything works as required.
https://bugzilla.gnome.org/show_bug.cgi?id=703321
Year view always shows week numbers and by design team the default show
not display them.
This patch adds support to read "show week numbers" setting from GNOME
Shell (org.gnome.shell.calendar::show-weekdate) and to change year-view
accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=763251
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
Design team testing with GNOME continuous, complained about week numbers
being shown in big dark squares. According to them, these wreck the
layout of the view.
Design team listed the issues, comparing to gnome-shell calendar as:
* The containing boxes are larger in Calendar.
* The background of the boxes has more contrast with the background (it
should be a lot lighter in Calendar).
* Week numbers are an option in the shell, and are off by default.
This patches fixes the two first items: week numbers box' size and
color. Option to set on/off week numbers will be implemented in a future
patch.
https://bugzilla.gnome.org/show_bug.cgi?id=763251
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.
In some conditions when window is narrower than taller, week numbers
overlaps the view edge. That problem started after we added a
background to week numbers and moved it a little farther from the days.
The whole drawing function didn't take in account the space used by the
week numbers.
To fix that we had to move the whole drawing area and start to count the
space for the week numbers. We also had to change the logic to find the
day and month based on x,y coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=763251
Previously we were synthesising an end date of "start + 1 day", but this
isn't necessary. RFC 2445 tells us that no end date already means an all
day event.
Check this case directly.
https://bugzilla.gnome.org/show_bug.cgi?id=762985
In this commit, we fixed a crash report that occurred when an event had no end date.
Events with no end dates are all-day, 1-day length events. But, when an event with no end date set was synchronized with calendar (happened mostly with birthdays), it caused crashes, because the function responsible for getting the end date received NULL.
To correct this, we considered that end = start + 1day when no end date is set. With this, the mistake was corrected. Another thing that was correct along with this were two memory leaks, caused by the allocation of both end and start date that were not been freed.
https://bugzilla.gnome.org/show_bug.cgi?id=762985
Hannie Dumoleyn