The current implementation of the new calendar widget
accepts showing the week numbers in a modern and much
more consistent way.
The behavior, however, is not aligned with the rest of
the application and the desktop, which share a setting
to show or hide the week number.
Fix that by synchronizing the new calendar's week number
property with the specific setting.
After making the date selector use the brand
new date chooser widget, it is now time to make
it an entry.
This commit, then turns GcalDateSelector into a
GtkEntry subclass, and add all the plumbing that
is necessary to make it work as such.
As a side effect, this commit adds rudimentary
natural language support for parsing dates.
After adding the new GcalDateChooser widget, change the
current date selector to use it as the internal widget
of the popover.
The next logical step is turning GcalDateSelector into
an entry.
Using a GDateTime improves consistency with the
other components (ideally, we'll move completely
to GDateTime) and simplifies the code.
This commit adds a new property GcalDateSelector::date
and adapts the API to use GDateTime.
There is no subclass of GcalDateSelector, and
actually it isn't needed. So, turn the class
into a final class and get rid of the needless
private field.
As stated on the bug below Calendar crashes in some locales because of the
parsing of the string representing the date. Since parsing this string can be
very tricky, we decided to make a simple translatable string with the format it
is needed and th translators can set the proper order according to his locale.
The translatable string goes as "%d/%m/%y" being %d the representation of the
day, %m the representation of the month and, %y, the year. The translators
should place it in the correct order for its locale, for instance en_US, should
place it: "%m/%d/%y"
The validation of the translated string is lacking some strength. It could use
some improving.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1226823
This was causing double actualization of internal day,month,year
variables because GtkCalendar::day-selected signal handler is run by
default after the user connected ones.
Since GtkCalendar widget is a bit clunky to navigate fast between years,
using a four years digits it's better because we are still
very close to the change of the century.
