A recent change made us wait for the category to be loaded before
constructing the Timeline, to know if we should preload it.
However the timeline property of Room assumes that there is always a
timeline available after the construction, which was not true anymore.
So we construct the Timeline during construction again, and use a
property to preload it when both the category and the matrix timeline
are ready.
Fix the position when removing the last item, and when truncating the
list.
Also add a check that we are removing the proper event from the map, in
case we have created the same event several times.
With the context, the string change breaks the string freeze, and it is
not necessary since it has the same meaning as the other string with the
mnemonic.
It seems that sometimes the GtkListView does nothing when we are
notified that its size has changed and we request to focus its last
child.
It might be because the size is allocated before the child is ready, so
we delay the request.
Try to be smarter about what we are doing when we get signals from the
vadjustment.
We can ignore the upper and page-size signals when we are already
auto-scrolling, since trying to scroll more will just result in even
more signals later.
Only focus the last child once, then rely on scrolling to the end to
make sure that we are at the bottom.
It is expected that we will not be able to access most of the room state
so do not try to load everything and reduce the logging level when a
permission error happens in those states.
Those are the categories that the user is most likely to visit.
Also we should not preload the timeline for categories where we do not
offer to view it.
That way we can benefit from improvements upstream.
This also simplifies the camera API in the process by using a trait
instead of a subclassable GObject.
Kévin Commaille
Maximiliano Sandoval
Artur S0
Ekaterine Papava
Rafael Fontenelle
Yuri Chornoivan
Martin
Daniel Rusek
Anders Jonsson
Brage Fuglseth
Alexandre Franke