"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.
Calculate event blocks upfront, in a way that is agnostic to
pixel sizes, and keep them alive as long the event is around.
Calculate which event blocks are visible at layout time, and
only set the child visibility of the event widgets, instead
of truly showing or hiding them. This makes size_allocate not
queue relayouts.
There are many opportunities for optimizations that we can
eventually land, but this seems to work decently so far.
RTL support is still missing.
