When we escape first, then truncate, we might end up truncating at
the middle of a special character sequence, breaking the markup.
Fix that by escaping after truncating.
By storing the coordinates array in a local pointer,
we avoid 9 super slow full memory lookups. That matters
when we're inside the drawing function, trying to keep
60fps.
The current implementation is deficient in many ways, the
worst one being the it relying on GObject semi-synchronous
property emission.
This issue was exposed by the Week view code, where the active
date was updated, but delayed to reach the Week header and some
events were being added ~before~ the active date changed.
With this work, I was also able to figure out a bunch of code
that relied on this (i.e. luck) to work.
On RTL languages, the calcs to detect the start and end
of the new event were wrong, leading to the weird behavior
it currently has.
Fix that by correctly calculating the start and end cells
on RTL languages.
https://bugzilla.gnome.org/show_bug.cgi?id=777429
The code in ECalDataModelSubscriber:component_changed() and
:component_removed() was actually duplicated, and we can
simplify the :component_changed() routine by simply removing
and readding the event.
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.
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.
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
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
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.
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
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
When adding an event with the same start and end dates and
times, the event effectively spans 0 minutes, leading a division
by zero and causing varius UI glitches.
Fix that by making sure events span at least 1 minute.
https://bugzilla.gnome.org/show_bug.cgi?id=777414
Because we were blindlessly decreasing the search hit counter without
considering that we could've not removed anything, the search hit
counter is going nuts.
Fix that by properly checking if something was removed, and only decrease
the search hit counter when that happens.
