If the backend is busy, e.g. downloading attachments, this would block
the entire backend thread as it cannot handle multiple commands at the
same time (it will directly await on executing the first command, and
only afterwards handle the second one). Fixing this problem is very
difficult as the presage::Manager cannot be sent between threads. One
therefore needs to use tokio::task::LocalSet for the fix, which runs the
futures on the current tokio thread. This still leads to problems though
as many functions in the manager require mutable (and therefore
exclusive) access to the manager. There is no good way to fix it except
for wrapping the manager in a RwLock (I have chosen to use one from
tokio, as using the one in std would likely lead to clippy issues with
hold locks accross await points). This is only a partial fix though, if
some method requires mutable access to the manager, this still blocks
every other method from executing. But it should at least fix the most
serious contenders, like downloading attachments. I don't know a better
fix at this time.
Potentially related to #271.
Previously, we restarted the manager loop whenever the device wakes up
from suspend. This required additional permissions. Instead, we can
restart the manager loop whenever the network changes to the "available"
state.
Fixes#248 and #263. I'm not completely sure what the cause of this issue is, but
presage sometimes overwrites a contact with an empty contact except for
the phone number which is set. This in particular unsets the profile key,
which we use to fetch profile information. For some reason, presage also
stores the profile key in a separate table. We can get our profile key
from there in case it is unset from a contact.
This updates the underlying store used by presage from sled to sqlite.
This change is not backwards compatible, as there currently exists no
migration between the two stores.
While the main reason behind the change from sled to sqlite was, at least
in my eyes, the features which could be implemented using a real
database, the upstream store will still not allow for such features as
there is still binary data stored inside the database, instead of
structured data like I wanted to have. I raised the concern upstream, but
it was mentioned that such a change could be done in the future.
Porting Flare to this new store required a few fixes from my side, which
I contributed upstream in the following PR: https://github.com/whisperfish/presage/pull/321.
The change also required some bigger changes from the Flare side, as
sqlx (the crate presage uses to interface with sqlite) requires a tokio
runtime, and could therefore lead to crashes if the store was used from
the glib thread. That is why I wrapped all (at least I hope I did not
miss any) calls to the store and internal manager in a tspawn. Some of
those would maybe not be required, but better be on the save side in case
the functions of presage change to access the store where they previously
did not.
I also introduced a new error in case creation of the folder holding
the database failed. There is also still one potential to panic in case
this path is not UTF-8, but I don't care about that right now.
Furthermore, presage changed the order of messages being returned from
incrementing timestamps to decrementing timestamps, I therefore had to
throw away iterator reversal I did in Flare. Other than those changes,
the rest of this commit pretty much only replaces references from the
sled store to the sqlite store.
This fixes two issues regarding mentions. The first one is that mentions
are actually not highlighted anymore in the text. This probably broke
with the introduction of the special label for messages which allows to
have the timestamp the message was sent at in-line with the actual
message. The bug was caused by overwriting the message attributes when
setting the label, instead of merging the attributes caused by mentions
and the attribute for blank space reserved for the message timestamp. To
fix the issue, the label now saves the message attributes being set and
adds those attributes to the attributes of the underlying label when it
is updated.
The second bug was that message attributes in quotes were using the
attributes of the quoting message instead of the quote itself. The fix is
just a simple change in the blueprint file, taking the attributes for the
label from the quoted message instead of the quoting message.
This can be confusing as one could in that case interpret the message
being sent from a different sender in a group chat. The fix was just
removing a single line of code, which probably got included by accident.
Implement receiving stickers, which can just be handled as attachments.
Some notes:
- Animated stickers do not seem to work for me.
But I am not sure whether GIFs work in general for Flare right now,
I remember that they did not work sometimes.
- A sticker pack I had did not set a content type for its files.
I just hard-coded image/webp (which was the file type) for such files.
This is extremely ugly, one may want to detect what the content type
is in such cases. Some sticker packs also mention a completely
different mime type to what they actually are, but this does not need
to be handled as gtk::Picture handles that fine.
- Loading webp into a pixbuf does not work by default on the nix build.
I needed to add an environmental variable to the flake to make it work.
The --locked flag ensures that the lockfile is used and cargo does not
attempt to change the lockfile due to different dependency resolution.
It is recommended when deterministic builds are desired. Release builds
should be deterministic.
Untested, but should work. This is due to reqwest 0.12.0 changing the
error message compared to 0.11.0, the source of the error is now not
included in the Display implementation anymore, but has to be received
manually.
This also includes an update of the depednencies and removing the
`err-derive` dependency in favor of manually implementing the one error
this is used in.
Had some breaking changes:
- `libadwaita::Dialog::present` now takes an `Option`,
- `glib::clon!` has a new syntax
The porting guide is detailed [here](https://gtk-rs.org/blog/2024/07/17/new-release.html).
Julian Schmidhuber