Previously meson would withhold the stdout output, and only
print it once the job was finished. This was a bit problematic
with the current way we wire cargo into meson, cause you have
no output of whats going on till then causing a degraded UX.
With this change output is printed directly to stdout and
behaves as expected.
https://mesonbuild.com/Reference-manual.html#custom_target
With this change we're using lmdb as the cache storage and it works.
In this case we're not using the AppMsg cache model to store messages,
we're storing all the room with all the msgs.
In the future will be better to split that in two, so it'll be faster to
add, delete or update a room message, because with this version any of
those operations requires to serialize the whole message array again.
Its possible to make rust structs for each widget and add those to
the UI struct instead of going through GtkBuilder to access every
widget.
This, along with the previous commit, shows an easy pattern that can
be followed to abstract the elements and refactor the codebase
gradually.
A similar pattern was also demonstated by Federico in his GUADEC
2018 talk "Patterns of refactoring C to Rust" [1]. I Highly
recommened watching it.
[1] https://www.youtube.com/watch?v=5mVMycYmoWE
This is a reimplementation of the widget that existed in the gtkbuilder
(.ui) file. The end goal is to start moving everything in its own
declaration and use actuall Rust structs instead of the GtkBuilder
to access the widgets.
For the time being the widgets are exposed to the builder object in
order to make the refactoring proccess easier and not brake the world.
The room param for the RoomHistory was calculated using the AppOp, but
we're getting this in the new method params, so we can use directly the
room variable.
With the remove of the initial sync without a since param and the store
of the prev_batch for each room, the load_more messages isn't working
correctly.
I've detected two issues that this patch fixes:
1. The first problem is that it's possible to have rooms that doesn't
have the prev_batch, I'm solving this with a new backend call that loads
more using the last messages id and in the case that a new room doesn't
have messages we can use the last sync batch.
2. The second problem is when you load more, close and open again
Fractal, if you go to load more, the prev_batch is the last one so we're
not loading the corresponding messages, we continue loading from the
last one that's not what is showed. This is because at close we're
storing the last batch in cache, but we're only storing the last 40
messages. To solve this, I'm setting the prev_batch to None at store in
the cache so the first time we'll try to get more messages using the
last message id.
The new widget for the history keeps track of the the messages in the
list, therefore it can update a message and how a message is displayed
It also adds lacy loading of a new message batch or cached messages (not
yet in use)
