Valgrind was reporting some "Conditional jump or move depends on
uninitialised value(s)" and "Invalid read of size 4" when hovering
year-view.
It was found some uninitialised variables in the code and they were
initialised before being used.
https://bugzilla.gnome.org/show_bug.cgi?id=781430
There are two mapped events for each back/forward buttons in this
widget: button-press and button-release.
When you reach the limits like January and December, button-release is
lost, and you don't get it anymore. That caused button_timeout function
to not be disable anymore, so it's kept in loop forever.
This code fix checks in button_timeout function if any of the back/
forward buttons are still mapped. If not, it prevents from calling
button_timout, stopping the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=776459
When user changes the date in month-view, there is no sync with
year-view. The other way around works just fine, when user selects a
date in year-view, month-view goes to the same date.
Both views share an "active-date", but year-view doesn't obey that
property in some cases. Month-view also doesn't warn when changing that
property.
This commit fixes both views to keep them in sync, updating and using
"active-date" correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=750478
Edit dialog headerbar tooltip was reading: "Click to select event's
agenda" and a user asked to change it to: "Click to select the
calendar", so it would be more natural and familiar for non-native
English users.
https://bugzilla.gnome.org/show_bug.cgi?id=772103
Year view was placing popover to mouse click (x,y) position. That was a
little odd because sometimes popover was placed above the selected day.
This patch address that by placing popover always out of the day box.
When selecting the whole month or more than one day, popover will also
be placed out of the month box. reducing the chance to cover selected
days.
https://bugzilla.gnome.org/show_bug.cgi?id=743306
The view had a maximum of 6 month columns, leading to a huge amount of
vertical spaces, so it was requested to reduce that.
The maximum number of columns was reduced to 4, so the view will have a
maximum 4x3 months layout.
https://bugzilla.gnome.org/show_bug.cgi?id=753533
Improve year-view code, removing hardcoded values.
year-view have hardcoded values for grid cell sizes (width and height).
Those values need to be recalculated every time a change in font or any
other style are changed.
Sidebar width was also hardcoded instead of getting its value directly
from the ui file. That would prevent it from drawing the content
accordingly when ui file is changed.
This patch fixes those two issues by retrieving those values from CSS or
ui files.
This patch also adds code to resize and redraw the window when
show-week-numbers property is changed.
Popover mode was also changed and now sidebar will always be shown when
show-week-numbers is set or when there is space for only 3 or less
columns.
https://bugzilla.gnome.org/show_bug.cgi?id=753533
Calendar is not handling locale correctly, e.g. user’ set language to
English (en-us) and format to Norwegian (nb-no), but Calendar assumes
English format rather than Norwegian.
Calendar code was ready to use the correct format, just like Shell and
GtkCalendar. The issue was in the build script which was setting the
correct locale variable responsible to make that code work.
This patch fixes the build script.
https://bugzilla.gnome.org/show_bug.cgi?id=762428
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
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
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
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
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
Previous fix was considering Jan 1st and Dec 31st to find the week
number, using ISO 8601 standard, and that was causing an issue with some
dates like Jan 1st, 2017 which was displaying week# 52 instead of
week #1.
The issue happened because ISO 8601 always consider Monday as the first
weekday, so as Jan 1st, 2017 is a Sunday, it' still considered week# 52
and not week# 1.
After checking GtkCalendar code I noticed it uses the same ISO 8601
standard but instead of using Jan 1st or Dec 31st, it always get the
week number based on the last day of that week, taking account if the
week starts on Sunday or Monday, depending on the locale. In our
example, using a calendar based on Sunday, Jan 1st, 2017 is the first
day of the week and Jan 7th, 2017 is the last one. Therefore I changed
week number code to always use the last day of the week.
https://bugzilla.gnome.org/show_bug.cgi?id=757622
Year view didn't have hints for days with events and this feature was
requested to be added to gnome-calendar.
This is an old request but in the past gnome-design team though it would
be better to keep the layout simple without hints for days with events.
Now with the changes in gnome-shell calendar and in order to keep them
in sync, this feature was added to gnome-calendar.
In order to implement this code we had to add a few css styles and a
code to add a small circle below everyday with events. Although
gnome-shell calendar uses an svg image with a 3x3 dot, we chose to use a
pango function to draw the dot.
https://bugzilla.gnome.org/show_bug.cgi?id=743317
Changed year view to use ISO 8601 standard to display the week #s
correctly when showing first and last weeks.
Year view was always starting week #s as 1, based on Jan 1st, and it
kept count the weeks until Dec 31st. But according to ISO 8601 standard,
that's not always true, i.e. Jan 1st 2016, is still in the 53th week of
2015, while Dec 31st 2014 is already in the 1st week of 2015.
Now the code is using ISO 8601 GDate function to get the correct week
number for the first and the last weeks of the year only. Other weeks
continue to use the same logic.
More about ISO 6801: https://en.wikipedia.org/wiki/ISO_8601#Week_dateshttps://bugzilla.gnome.org/show_bug.cgi?id=757622
Isaque Galdino