I don't know the reasoning behind it, but sometimes
I see dates like March 32 or February 30. Events are
correctly added, so I suspect it's an issue with another
app.
In any case, we should be able to handle weird dates
without crashing, so normalize the dates before using
them.
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.
When we change a source (aka agenda) color, we have to
restart Calendar in order to see it in action.
After the work on GcalEvent, events are now able to track
the agenda's color changes, and the event widget updates
itself in response to that.
The last step was simple notifying GcalApplication when an
agenda changes, so it knows when to recreate the color schemes.
The compare_for_single_day() method is reproducing the
same functionality from gcal_event_compare(), and the only
consumer is the Year View. So, for now, simplify the
comparing function and put it in year view file.
Also, this commit vastly improves and documents the year
view's algorithm to add events to the sidebar list.
Sometimes we crash the window right after closing it
because we set a timeout for save_geometry() before
destroying it, and the timeout is called after the
window is destroyed.
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.
Instead of using the GcalEventData struct, use the
deleted event. It holds a reference until the event
gets destroyed.
With this commit, we can safely drop GcalEventData
structure, since it's not used anymore.
Instead of relying on the now deprecated GcalEventData,
use the newly introduced GcalEvent class. As a side
effect, the code is simpler and much more saner to
deal with.
Following the sequence of porting commits, make the Shell's
search provider class handle events using GcalEvent classes
instead of the old GcalEventData structure.
Instead of using the ESource + ECalComponent combination,
use the new GcalEvent class, which wraps up and simplifies
most of the code.
This commit adds a GcalEditDialog::event property, and
adapts the dialog (and everything dependant on it's code)
to use the GcalEvent class.
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
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.
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
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.
When we check start & end time selector's sensitivity before
notifying the property change, the check is overriden by the
binding.
Fix that by performing the checks after the notification of the
property change.
This commit sets up the edit dialog from the window's ui
resource file, in a series of commits that tries to move
all C code to the UI definitions.
Also, GcalManager is a full GObject class, not a simple
pointer. As such, update the property spec to be of type
object, not pointer.
By using these properties, we gain the possibility to
bind them to the widgets and save some needless code.
This commit adds GcalEditDialog::writable and ::manager
properties. Other needed properties will be eventually
added in the subsequent commits.
This commit updates GcalEditDialog's code for
it to be a final class. As such, we don't need
the GcalEditDialogPrivate type - we can simply
move our data to the GcalEditDialog struct.
