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
tzid can have different formats depending on where it originates from:
regular or prefixed by a libical specific identifier. Use the
right icaltimezone_get_builtin_timezone* for each case.
https://bugzilla.gnome.org/show_bug.cgi?id=763180
Today button in the headerbar was not working when pressed in the
current year.
Button logic to update side panel was only triggered if there was a
change in the chosen year.
Fixed to update side panel whenever date is changed.
https://bugzilla.gnome.org/show_bug.cgi?id=762463
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
format_utc_offset can be called with the return value of
g_date_time_get_utc_offset returning microseconds in a gint64. It is
also still called with the return value of icaltimezone_get_utc_offset
in seconds. Deal with both.
https://bugzilla.gnome.org/show_bug.cgi?id=762438
Week numbers in year view was using a small and very light style and
that was making difficult for users to be able to read it.
After a few conversation with gnome-design team, they proposed the best
approach it would be to use the same style as gnome-shell panel does.
The week numbers style was changed to be as close as possible to the
gnome-shell panel.
https://bugzilla.gnome.org/show_bug.cgi?id=759354
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.
When the user removes an event, we first hide it and,
after a timeout, we remove it. The problem is that if
the user closes the window before the timeout is fired,
the event never gets deleted.
Fix that by deleting the event on finalize if there's
any event queued.
https://bugzilla.gnome.org/show_bug.cgi?id=762284
By using gtk_dialog_run(), we enter in a recursive mainloop
which blocks the parent's one. Because of that, we see weird
things like the quick add popover not still floating around.
