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.
These are still hardcoded instead of measuring the available space,
but it's better than nothing in the meantime.
Decent WMs size the window correctly if width/height exceed the screen.
Also, allow the Notes field to expand vertically, to fill the space.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/602
Mnemonics are useful for navigating through the interface more easily,
besides improving the accessibility. Since the calendar button is an
important button for using the application, it is interesting to have
a mnemonic associated with its label.
Using the letter C for this label seems reasoable, since there is no
conflict with the labels simulteneously active in the application, and
it is easy to remember.
Users should be able to navigate through the interface ideally using
only the keyboard, as specified in the GNOME Human Interface Guidelines.
This however is currently possible in the window page with shortcuts
when it comes to switching among week and month views, and jumping to
today's date. It is also interesting to have access keys attached to
such labels, so that the user does not need to look for the keyboard
shortcuts.
Using the first letter for each of the labels as mnemonics suffices in
this case, since there is no conflict, none of them is a thin letter nor
has descenders, and they are easy to remember.
The GcalDateSelector returns an internal instance, while the 'until' date/time
is meant to be an own instance, which is freed by the GcalRecurrence instance
in its free function. That means the 'until' date/time is supposed to be reffed
when being assigned into the GcalRecurrence structure.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/892
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
