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>
"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>
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>
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>
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>
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.
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 measurement in opposit direction of the one in which
the elements are lined up needs not to add up all the
sizes but just get the maximal size.
This bug leads to too high minimal and natural widths
(and heights) of the month view.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
Add a click gesture to detect when we have to start monitoring
cursor motion. Also add a motion event controller to react to
cursor motion, and enable and disable the this motion controller
on button press and release, respectively.
Selection is implemented as a pair of GDateTimes stored in the
month view struct. Whenever a selection begins, the start date
is set; the end date is only set when moving the cursor. It is
valid to have a start of the selection, and no end (meaning, a
1 day selection); it is, however, forbidden to have an end but
not a start.
Future improvements can be added later, such as scrolling when
moving the cursor close to the edges of the month view. We're
gonna have to live without that for now though.
Implement the GcalView.clear_marks vfunc now that we have a
selection to operate on.
ARAKHNID