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 code block for the commit message contains blank characters that are
breaking the markdown rendering engine, making the message block to
stop right after the first paragraph, and getting rid of the last line.
Simply cleaning these blank characters make the code block to render
properly. Note that I've also specified the type of the block, which is
plain text.
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
Fran Dieguez