The time direction property tells which orientation one
needs to scroll to change the time of the view. In these
directions (up/down v left/right) the new prev/next
buttons will be pointing.
The two buttons will be added in a subsequent commit,
and will gain view-dependent tooltips.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/542>
This makes it so the user can easily skip the entire month view
by pressing tab within the month view. This means, events can only
be accessed with arrow keys in the month view.
When tabbing into the month view, the keyboard focus would go
to the first week row in the widget hierarchy, rather than the
visible row. Setting the `GtkWidget:can-focus` property to
FALSE on every non-visible row only allows keyboard focus
within the visible rows.
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>
Now that we keep precise control over GcalEvent instances, and
can use simple pointer comparisons everywhere, GcalMonthView
implemented its update function as a simple remove + add pair.
The problem is that we're not passing the old event instance,
so removals never actually happen, since the new instance is
not yet available to subscribers.
Pass old event in additio to the new one, and use it where it
makes sense.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1073
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.
When scrolling with a scroll wheel, animate towards a target
row. If multiple scrolls happen before the animation completes,
change the target row of the animation.
The Month view is a complicated beast when it comes to allocating
events, but it's unnecessarily complicated since it tries to take
margins of events into accounts. With GTK4, that's not necessary
anymore, as GTK4 will independently and correctly apply margins
in widgets by itself, we don't have to do manually anymore.
Clean that up.
