This is still not the ideal solution, but now that we have widgetry
that can handle hundreds of thousands of events, no limitations to
the maximum number of events, and no crashes related on the search
engine, we can increase the search range to a broader value and
show more results.
Helps: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/624
When I originally wrote the code, I expected to create a new icon
every time that function was called. That expectation changed, but
the code wasn't fully updated.
Use g_value_set_object() instead of g_value_take_object().
The Month view is a complicated beast when it comes to allocating
events, but it's unnecessarily complicated since it tries to take
margins of events into accounts. With GTK4, that's not necessary
anymore, as GTK4 will independently and correctly apply margins
in widgets by itself, we don't have to do manually anymore.
Clean that up.
Port the search results list to GtkListview. Use bindings to set
the title, icon, and subtitle of each row. Remove GcalSearchHitRow
as it's unused now.
We end up losing minutes information when running through this code
path. Technically it's fine, because we copy the minutes from the
event, but it's better nonetheless to operate on the level of
granularity that Calendar supports.
I don't know what I had in mind when I wrote this, since 2017 self
did not bother adding a proper commit message, but 2023 me is pretty
convinced we never want to change the event length when dragging it
around.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/896
They behave slightly differently from smooth scroll events, and
they don't emit 'scroll-begin' nor 'scroll-end', so we have to
execute that the callbacks of these signals do inside the scroll
callback itself.
GtkSpinner queues relayouts even when the stack is not displaying
it, and this causes excessive redrawing. This button design looks
obsolete and should eventually be reworked, but for now, let's
just stop spinning when the spinner is invisible.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/971
The people who introduced this code were not careful enough to
make sure the code they removed from GcalWindow was added back
in GcalToolbarEnd.
They also simply commented out some code instead of properly
reimplementing that.
I regret having trusted their code :(
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/880
The implementation of the credentials popover has relied on a hack,
and sadly this hack doesn't work anymore.
It's too late for a redesign, so for now, just put it into a dialog
and show it on top of the calendar management dialog.
This is to show how much I suck at reviewing code. Look at this
massive gold nugget of garbage. Nobody on their serious mind would
have let that pass code review.
But I did. And now I deserve the punishment to deal with this.
Of course, the author didn't seem to have spared more than a fraction
of a second of their brain power to even consider what they were
doing here. But that's what code review is for - preventing garbage
like this from landing. And yet, here we are, removing an invisible
Week view from the sidebar.
When a recurrent event is edited, we now are able to only offer the
MOD_ALL option when it actually will work. However, we're still left
with the problem that we end up applying the instance-specific data
onto the main event, through an old hack.
The views already aren't able to offer the MOD_ALL property, since
they all change the dates of events, but GcalEventEditorDialog can,
and it must handle that properly.
For now, do the simplest possible approach, which is: retrive the
template event and apply all properties that can be applied to it,
without letting the start and end days leak into it. We already only
allow passing MOD_ALL on situations where the dates aren't really
modified, so it should be safe.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/882
We get into seriously tricky situations if we try and change the
date & time of an event with recurrency, and pass MOD_ALL. That's
because it is ambioguous *where* the change must be applied.
Don't allow selecting MOD_ALL when the scheduling of the recurrent
event changes.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/882
The only field that views may change using DnD is the start date
field (and, consequently, the end date), and that's exactly what
we must not show the MOD_ALL option for.
Don't show it.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/882
When we receive the 'objects-modified' signal, we get components
that may represent main events. We also may receive components
that have no recurrency because they were just changed from being
recurrent to non-recurrent.
We need to handle all these cases properly.
If the event has no recurrency set, remove any potential old
recurrence instance lingering around. If we're changing an event
with recurrency, make sure the recurrency instances are in sync
with the new recurrency.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/881
(or so I hope.)
We'll start accessing the hash table from multiple threads, so
it must be in the shared section of the structure, and it must
be encapsulated by locking.
