When tabbing into a grid or list of items that are selectable,
we want to focus the selected item when entering it. At the moment,
we only focus the first or last item in the date chooser grid,
rather than the selected item.
Co-authored-by: Niklas Wimmer <niklas@viric.eu>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/869>
`add_event_to_block()` assumes that the child widget has never been
parented, so it will always set the parent widget when the widget
is already parented, which triggers a critical error in GTK.
This patch addresses this situation by only parenting when the
widget has just been created. Additionally, it asserts that the
parent widget is `self` in the end, so that it crashes if this
is incorrect.
Fixes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1643>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/863>
Currently, `gcal_date_time_get_start_of_week()` seems to be
the only user of this macro function. In the next commit, the
month view will use it to traverse weeks while maintaining
the weekday.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/839>
At the moment `gcal_date_chooser_set_date()` is automatically setting
the day to 1, which is undesirable behavior for a method that is
designed to "just" set the date. By connecting to
`GcalMultiChoice::explicitly-changed`, we can simply have the day
set to 1 to accompanying callbacks.
Currently, `multi_choice_changed()` is invoked 50 times at startup.
By using `GcalMultiChoice::explicitly-changed`, `multi_choice_changed()`
is only invoked 10 times. This is still more than ideal, but it's
a significant drop.
Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1639
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/837>
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>
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>
This is a utility widget akin to GtkGizmo[1] and AdwGizmo[2].
It is designed for use in complex widgets which require additional
features such as snapshotting, measuring/allocating, and
focusing capabilities.
We want to implement an entry row widget that allows multi-line content.
The first implementation had two widgets: GcalNotesRow for the widget
itself, and GcalNotesTitle to contain and animate the title by overriding
the measure() and size_allocate() class methods. The GcalNotesTitle
widget ended up becoming a basic widget that could easily be handled
by GcalGizmo. The new implementation simply uses GcalGizmo.[3]
Another potential user of GcalGizmo is GcalDateChooser, where the
date grid contains complicated logic for handling focus to a child widget.
Since GcalGizmo is designed to give full reign over focusability, we can
also use it to simplify focus. The layout manager can quickly be swapped to
GtkBinLayout since we don't want to handle custom measure/allocation logic.[4]
[1]: <https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkgizmo.c>
[2]: <https://gitlab.gnome.org/GNOME/libadwaita/-/blob/main/src/adw-gizmo.c>
[3]: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/737>
[4]: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/760>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/790>
When an event widget is focused, there is no way to skip the entire
view with key combinations.
This patch addresses this by allowing the user to skip the entire
view when pressing Ctrl+Shift+Tab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/817>
Visually, this comes with the benefit of not having the first
and last visible event widgets take additional margins, as spacing
is only applied between event widgets.
This will also allow us to make use of gtk_widget_pick() without
having to rely on hardcoding 1 on the y axis.
The current approach has a one pixel margin at the top and bottom
of each event widget, which offsets the vertical position of
every event widget by one pixel. In order to pick the first
event widget, we'd want to call
gcal_month_cell_get_header_height() because this is where the
first event widget is placed. If we were to invoke
gtk_widget_pick() with (x, 0), where x is
half the width of the month cell, the returned value would be
NULL because gtk_widget_pick() does not account for margins,
so it would need to be (x, 1), with 1 hardcoded.
Since this patch removes that offset, we can simply use
(x, 0) without having to hardcode 1.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/813>
For unknown reasons, the `::row-activated` signal is not emitted
whenever the user presses an activation button on the keyboard
such as Enter or Space, even though the list box row has focus.
Ideally, we want the list box rows to be activatable, so that
activating them will simply emit the "event-activated" signal and
pop up the popover.
Since this doesn't work, the next best thing is to make the event
widgets themselves focusable and the list box rows unfocusable.
This will unfortunately lose the ability to navigate with arrow
keys, as well as Home/End and Page Up/Down. However, the user will
at least be able to activate them and access events in
the agenda view.
A `FIXME` label has been added because this should be fixed as soon
as possible.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/807>
`WITH_CXX_BINDINGS` is deprecated in libical 4, so it's replaced with
`LIBICAL_CXX_BINDINGS`.
`LIBICAL_JAVA_BINDINGS=False` is required for libical 4.
Since we use `ENABLE_OAUTH2_WEBKITGTK4=OFF` in evolution-data-server,
we could also use `ENABLE_OAUTH2_WEBKITGTK=OFF` alongside.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/811>
For a while, we have been setting child visibility to false, which
hid the horizontal line separators. However, I started scrolling in
the month view today and came to realize that they were disappearing
sporadically when scrolling upwards.
This happens because we use the `box-shadow` CSS property to apply the
box shadow a pixel above the month view row, which keeps it visible
in the view even when the month view row itself is no longer in
the page. Adding a pixel fixes that.
This reverts commit f4702dde1f.
"Additive inverse" basically means transforming a positive number
into a negative equivalent, or vice-versa; for example, from 5 to -5.
Instead of inverting conditions in right-to-left languages to
compare the X coordinate, a much simpler approach to this is to
normalize the X coordinate by applying additive inverse in
right-to-left languages.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/744>
When hovering over the bottom side of a month cell regardless of
the sensitivity state of the overflow button, it queries the
button's tooltip text. Using `gtk_widget_set_child_visible()`
fixes that issue.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/743>
Since we don't make use of the overlay anymore, it's best to remove
it altogether.
This also changes the behavior of the widgets a bit: It adds an
empty AdwBin widget which expands vertically, allowing us to avoid
aligning the header and overflow button.
The pattern goes from reducible (where we deduct the overflow
height to retrieve the content) to additive (where we add the
overflow height to the content height), which requires us to
adapt GcalMonthViewRow with this new behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/743>
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>
This is a preliminary step for moving the comparison and
application logic of each section into the dialog.
Essentially, the dialog will pass the duplicate event to each
section, and these sections will modify the event. If the user
presses "Save", the dialog will compare the edited event to
the original event, and apply if they are different.
This also adds the `get_event()` method which will be used
in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/711>
