The current Year view drawing routine gathers events
every single time we draw the navigator. This is, to
the best case, slow to death. In fact, this is why
year view's navigator is so memory and processor
consuming.
To fix that, cache the added components and simply
query them at drawing time.
One of the biggest issues of GNOME Calendar views right now
is that they rely on GObject property system to update the
active date. Even gcal_view_set_date() is just a wrapper
around GObject set.
Because GObject asynchronously updates the property by letting
the mainloop handle it, we can never be assured that all the
views had their views updated before updating the data model.
This patch temporarily adds sanity checks to GcalWeekHeader
to prevent making Calendar unusable, until we fix GcalView.
Earlier the height of event-widget with duration of 30 mins or less exceeded
the desired space in week-grid. As height available was not checked beforehand,
this resulted in some event-widgets getting height assigned which was more
than the height available.
This patch fixes the erroneous assignment of event-widget's height by first
comparing the required height with the available height. If the required
height exceeds the available height, then the display-text is given as a
single-line for the widget to fit properly.
https://bugzilla.gnome.org/show_bug.cgi?id=778070
As the assignment of display-text, and in turn that of event-widget's height,
is taken care of in event-widget, we no longer need to consider natural-
height, while assigning height in week-grid.
This patch fixes this issue by removing natural-height, and directly
assigning the desired value to height.
https://bugzilla.gnome.org/show_bug.cgi?id=778070
When dragging events around, the cursors show a + as opposed to a
an arrow indicating that the event is being moved. This can confuse
users.
The fix is to tell GTK that the drag being performed is a move.
https://bugzilla.gnome.org/show_bug.cgi?id=774922
When comparing events' dates against week dates, we must
be careful to compare UTC with UTC. Otherwise, some events
will be left, specially at the first and last days.
This is a big cleanup commit where I tried my best to
make GcalManager code more structured and readable. This
included both cosmetic and functional changes.
In this commit, the correct week number is set in week-view.
The problem is, the week number of week-view is being set according to
the first day of the week (if the first and last day of the week
are in the same year), or the first and last day of the week
(if the first and last day are in different years).
To fix this, the week number is being set according to the middle day
of the week (according to ISO 8601 standards), resulting in correct
week numbers.
https://bugzilla.gnome.org/show_bug.cgi?id=779331
There are some weird cases around the globe where the timezone
changes in the middle of the day. In GMT-8:00, for example, the
DST changes at 2:00 am. This makes the timezone of thestart of
the week different from the event's timezone, and somehow the
GLib API doesn't take that into account when calculating the
diff between two dates.
Fix that by also considering different timezones when calculating
the event start and end positions.
https://bugzilla.gnome.org/show_bug.cgi?id=780079
Sometimes, we'll need to ignore the reported minimum sizes
to be able to set the width of events to an acceptable
size. This is the case of the week grid.
https://bugzilla.gnome.org/show_bug.cgi?id=780052
The auxiliary functions to calculate the week start
already takes the first weekday into account. We,
however, were considering it again when calculating
the event position.
Fix that by only considering it once, through the
get_start_of_week() function.
https://bugzilla.gnome.org/show_bug.cgi?id=780051
The rudimentary drag n' drop support should also deal
with the following corner cases:
All Day
Multiday | TRUE | FALSE |
|----------|------------|
TRUE | utc | no changes |
FALSE | utc | utc |
https://bugzilla.gnome.org/show_bug.cgi?id=777424
Previous commits broke the week view's date range (more
than it was already broken). This patch fixes that by
using the correct method to get the week start.
https://bugzilla.gnome.org/show_bug.cgi?id=779967
Earlier the app used to crash when a new event was added using the
'Edit Details' buttion/dialog. This was happening because edit dialog's
event was set to NULL before the event was being stored in the calendar
through the 'edit_dialog' and hence the app was crashing.
This patch fixes the above-mentioned issue by saving the event before
setting the edit dialog's event to NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=779733
We were using gtk_widget_queue_draw() as a callback to
a GTimeoutSource, which expects a boolean return type.
This is clearly wrong, and has the chance to cause
a segmentation fault.
Fix that by passing a function with the apropriate signature.
https://bugzilla.gnome.org/show_bug.cgi?id=779823
