The current notes text view has had a 2px offset for
an unknown amount of time, due to us magic-numbering
margins and/or padding. This approach works a little
bit differently, in that it uses the `.editable-area`
style class and sets the overlay's CSS name to "box"
to use a predictable size of margins from AdwEntryRow.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/738>
The current way of adding activation shortcuts is cumbersome,
as it is a for-loop pasted in the middle of class initializers.
The utility function addresses this problem by simply allowing us
to declaratively add these shortcuts with minimal effort.
Furthermore, the implementation is also simpler, thanks to the
`gtk_widget_class_add_binding_signal()` wrapper function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/747>
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>
`hide()` stopped working since we ported to AdwDialog. We certainly
don't want to override the `close()` virtual method from AdwDialog,
as page transitions begin while the dialog is closing. Instead,
we can override `unmap()`, which will do it at the very end.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/712>
When opening the event editor dialog as a new event, `set_new_event_mode()`
immediately tries to focus the last focused widget, which won't work
because it is unfocusable. `focus_last_focused_widget()` then clears
clears the pointer regardless of whether the widget has successfully
grabbed focus or not. So, we want to only clear focus if the widget
has successfully grabbed focus.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1566
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/730>
The event popover contains a lot of text in different sizes, which
pushes us to magic-number the maximum amount of characters
(i.e. `max-width-chars`) and hope that all is well.
This approach addresses that by simply clamping the parent widget
to the desired size, allowing us to remove all instances
of `max-width-chars`.
Do note that `Adw.Clamp:tightening-threshold` is set to 400 by default,
which technically doesn't need to bind to `Adw.Clamp:maximum-size` at
the moment, but I decided to do it anyway in case we want to change
`Adw.Clamp:maximum-size` in the future and can't figure out why
the margins are off.
Co-authored-by: Jamie Gravendeel <me@jamie.garden>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/728>
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>
Without this patch, focus immediately goes to the "Previous Month"
button at startup, for some unknown reason.
So, as a workaround, skip focus if the root cannot retrieve the
current focused widget.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/564>
This will be needed for setting focus to the last focused widget
after closing the popover.
Alternatively, we could have used the "unmap" signal, but this causes
a significant delay before setting focus to the last focused widget,
as it needs to complete the animation before it emits the
"unmap" signal.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/598>
Ideally, we should be comparing if the Y coordinate of both the
candidate and focused widgets are identical, but given font
sizing issues with special characters such as emojis
(see https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1519),
it is safer to check if these widgets intersect vertically, as
otherwise a single pixel offset may cause keyboard focus to
completely skip event widgets.
Currently, the event popover will always set its position to the
center of the event widget. This becomes an undesirable behavior
with long(er) event widgets, as clicking the edges will require
the user to physically move their pointer all the way to the
popover, which may be challenging depending on the distance.
This addresses this problematic behavior by positioning the popover
right above the pointer only when the event is a multi-day event,
and when the event widget is not inside a GtkListBox widget.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/677>
The SEPARATOR_OFFSET constant is for the box shadow property
defined in month cells' CSS. Since the box-shadow property does
not contribute to layout, so these offsets need to be set manually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/676>
Currently, month cells are using `round()` to allocate the width,
whereas event widgets are using implicit double → int conversion,
which causes event widgets to be offset by a pixel, and thus
touches month cells' borders.
This new approach guarantees the exact width of the event widgets
by invoking `round()`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/676>
The current animation duration paired with the ease-out-quad function
eases out imperceptibly fast (almost instantaneously), which makes the
overall animation feel laggy.
This patch addresses the aforementioned issue by increasing the
duration to 500ms. This then makes the ease-out-quad function ease
out relatively slowly, which is addressed by changing the function
to ease-out-quart - a function that eases out much quicker.
As a result, the animation should feel much more fluid and natural,
without giving the impression that it's 3 times slower.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1125
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/670>
This emits the `changed` signal, allowing us to filter out a wider
variety of calendars. It also allows us to remove the loops
that needed to re-run every time the user changed the default
calendar or closed the popover.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/362>
Since the calendar row widget is becoming an expandable widget,
several APIs were added to the widget:
- `gcal_calendar_row_get_calendar`
- `gcal_calendar_row_add_suffix`
- `gcal_calendar_row_get_first_suffix_child`
- `gcal_calendar_row_add_header_class`
- `gcal_calendar_row_remove_header_class`
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/362>
Currently, the quick add popover implements its own row
widget for each calendar, which duplicates tons of unnecessary
code. This commit streamlines the calendar-combo-row-item row
widget to make it reusable elsewhere.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/362>
Hari Rana