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>
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>
But mark them as not child visible. This should make keyboard
navigation work again, as the focused rows don't change actual
visible state, and thus are keyboard navigatable and don't lose
focus.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/769>
The tick callback can be fired *after* the GtkWidget.map() vfunc is
called, in which case the recalculate_layout_blocks() will run with
an already recalculated layout, which is invalid.
Only call recalculate_layout_blocks() when the blocks are invalidated.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/768>
Create a new GcalEventWidgetPool shared between all month view rows.
The event widgets are distributed to rows as needed.
When rows are done with the event widget, the give them back to the
pool so that other rows can reuse them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/758>
This is a major rework of the Agenda view. It splits the view into
GcalAgendaViewDay, which represent a single day with events; and
GcalAgendaViewDayRow, which is the actual widget with a title label,
and a listbox with event widgets.
The Agenda view itself merely manages a list of GcalAgendaViewDays,
and updates them with the events model, and active dates.
This allows us to get rid of the custom listbox row, and the confusing
checks for event widgets, and all the bugs the came with it. It also
allows for removing the internal GcalRangeTree, and delegate all
event management to list models.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/742>
And, while at it, rewrite the layout algorithm to operate on blocks of
overlapping events, and segmented columns. Like the month view row,
layouts blocks are invalidated at any point in time, but recalculated
immediately before a relayout happens.
The reason for doing such a massive rewrite while in the middle of the
port to GListModel is because it's easier to handle GListModel data
with this approach, than with the previous approach of storing it all
in a GcalRangeTree.
Closes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1153
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/742>
GLists are an artifact of times immemorial and we should
avoid using them as much as possible. In this commit, for
example, there were a couple of accidentally quadratic
pieces of code.
Port (mostly of) the week view header to GPtrArray.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/742>
This is future-proofing the uncertain decision of removing
GtkWidget's `margin-*` properties in the future, which is what
we're currently using to retrieve the height of certain widgets.
Whenever the intention is to get the entire size of a particular
widget, including properties that contribute to layout such as
margins, the `get_width()`/`get_height()` methods don't include
these properties during calculations. However, getting the size
of the parent widget will include them in its entirety.
As such, the safest path is to use AdwBin as the parent to the
respective widgets, and using it to retrieve the height.
See: <https://gitlab.gnome.org/GNOME/gtk/-/issues/6556#note_2056432>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/739>
This fixes an issue where pressing Shift + Up/Down while focused on the
overflow button will result in a bail out when asserting the focused
widget has a month cell ancestor:
```
GcalMonthView:ERROR:../src/gui/views/gcal-month-view.c:1002:on_key_controller_key_pressed_cb: assertion failed: (GCAL_IS_MONTH_CELL (month_cell))
Bail out! GcalMonthView:ERROR:../src/gui/views/gcal-month-view.c:1002:on_key_controller_key_pressed_cb: assertion failed: (GCAL_IS_MONTH_CELL (month_cell))
```
When navigating between month cells with a keyboard, focus is set
on respective month cells, so checking whether the ancestor
is a month cell or not is not only unnecessary, it also causes
bugs like the assertion above.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/720>
While "7" may be obvious in the context of calendaring that
it represents the number of week days, it often gives me the
impression of it being a magic number when I'm hyperfocused on certain
parts of the codebase for several consecutive hours. Turning the
number into a macro helps me scan functions much more easily.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/674>
Kaiky Cintra