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
The problem is that the end date might change to one before the
start date when modifying the start time.
Treat some cases taking into consideration the start date and start
time related to the fact that an event is spanning all day or not.
Separate the handling of the start date and start time.
https://bugzilla.gnome.org/show_bug.cgi?id=772100
When the first weekday wasn't monday, we were
miscalculating the initial and final positions
of the widgets.
Fix that by properly calculating the initial and
final positions.
The week view was being subscribed to the wrong dates,
because the window was miscalculating the start of week
on sundays.
Fix that by properly calculating the start of week offset.
Add timeout and minimum string length (3 characters) before triggering
searching routine.
App freezes and lags for a few seconds once one starts typing due to
the huge amount of matched events.
Search will be triggered only if passed time since last inserted
charactere is at least 500ms and three characteres have been entered.
If length is already >= 3 but user keeps typing in a quick fashion
(i.e. faster than 500ms per charactere) pre-scheduled search routine
(timeout from the last inserted char) is cancelled and a new one
is created.
https://bugzilla.gnome.org/show_bug.cgi?id=775549
In this commit, the first weekday is set for week-header & week-grid.
The issue is, the first weekday is being set only for week-view,
resulting in incorrect display of weekdays in the week-header.
To fix this, the first weekday for week-header & week-grid is set
along with that of week-view.
https://bugzilla.gnome.org/show_bug.cgi?id=779346
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
Currently, we keep the to-be-edited event of the Edit
dialog when it sends any response. However, this can
cause issues since we can edit the event, press Esc and
see that the event didn't change but Edit dialog keeps
the changes.
Fix that by always resetting the edited event to NULL
after a response.
https://bugzilla.gnome.org/show_bug.cgi?id=778644
Calendar now segfaults due to faling function
gtk_style_context_remove_provider_for_screen in application finalize method.
As application finalize method is called only when the application closes,
there isn't any hard requirement to cleanup every trailings. Operating
System shall take care of that.
So removing the failing functions so as to not segfault on exit anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=773871
When finalizing the application, it is possible that the main window
had already been destroyed and the Gtk+ CSS machinery to stop working.
We currently try to remove the CSS providers from screen when finalizing,
which (i) has no effect, and (ii) causes a segfault.
Fix that by simply destroying the CSS providers, and not trying to
remove them on finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=773871
The Week view exposed a bug where we had different
CSS selectors for the exact same label. This made
them look inconsistent, with different colors and
paddings.
Fix that by ensuring they all use the same style
class. The Year view drawing code needed to be
reworked a little.
https://bugzilla.gnome.org/show_bug.cgi?id=778391
