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.
When the until's time part is invalid, the libical claims the time
as valid, but the conversion into the GDateTime fails and returns NULL.
Such events, which claim to have until-date recurrence, but NULL 'until'
cannot be edited, because they cause a crash of the application.
More information can be found downstream at:
https://bugzilla.redhat.com/show_bug.cgi?id=2135772
Related to https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/892
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
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
