We currently rely on connecting the `notify::value` signal,
which is emitted every time the value is changed explicitly or
implicitly. This can be problematic when, for example, the user
scrolls in the month view, which changes the value of each
GcalDateChooser widget, and each minor difference will re-emit
the signal until it's over. The `GcalMultiChoice::user-changed`
signal will only emit when the user presses the
previous/next buttons.
The next commit will port GcalDateChooser
to `GcalMultiChoice::user-changed`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/837>
If the user has 12h time and sets a properly formatted but invalid time,
Calendar would crash because `date_time` would be `NULL`. This would
specifically happen if the time was set over 23:59 AM or 11:59 PM (ex:
19:00 PM).
By breaking if `date_time` is `NULL`, the crash can be avoided.
Closes#1602
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/848>
Using GtkToggleButton in this case is not only overkill for our
intended use case, it is also a hinderance, as the states and focus
of the widget are handled by the widget itself, which can lead to
unpredictable and undesired behavior.
Using AdwBin solves this problem by allowing us to set the styles
and states from the parent, provided that the CSS name is changed
to "button". Switching to AdwBin also allows us to not override the
`focus()`, `grab_focus()`, and `get_platform_state()` virtual methods.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/841>
This is a prerequisite for removing the strong dependence on the
child GtkToggleButton widget, removing the platform state override,
and adding binding actions in later commits.
Inheriting AdwBin was attempted but it didn't work, as AdwBin
presumably messes with focusability and activation, making
it insufficient for this use case.
`hexpand=true` needs to be explicitly set.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/841>
We no longer use this property. Removing it will then allow us to
directly set the label without having to use GtkStack, but this
will be done in a later commit.
This also sets all transitions to "none".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/840>
Only GcalCalendarComboRow, GcalAttendeesSection, and GcalRemindersSection
remain unfocusable on read-only events.
In the case of GcalRemindersSection, we eventually want to allow setting
reminders regardless of the writable state of the event; however, since
dialog is centered around the assumption that a read-only event should
never be edited, which includes reminders, these changes will have to be
done in a separate merge request.
Closes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/737>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/499>
Currently, GcalEventEditorSection is an interface that doesn't
really do much apart from requiring a property and providing
virtual methods.
This proposed approach turns it into an abstract class, derived
from AdwPreferencesGroup, which gives access to virtual methods
as well as public methods. It comes with the same benefits of
an interface, while sharing a lot of code that were duplicated
in the previous commits.
As a stopgap measure, it overrides several GtkWidget virtual
methods to smoothly transition without causing the commits
to break. These overrides will get removed in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/711>
Hari Rana