| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Direct chat corrections are accepted by bare JID, but the latest
correction lookup still constrained the query by the original full
resource; a correction sent from another resource therefore produced no
matching correction row, returned -1, and wrote that sentinel into the
message content item's foreign id.
Align the lookup with the acceptance rule: retain occupant id matching
for MUC corrections, retain resource matching for non chat cases where
it is still meaningful, and avoid resource filtering for direct chat
corrections.
|
|
|
|
- Incoming signatures are stored in the database and processed when needed
(to send PGP encrypted messages or to display them in the contact details)
- Outgoing signatures are stored in the database and cached until the key is
changed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It previously triggered the leak checker, even though eventually the widget
would be disposed when the corresponding message skeletion got disposed.
|
|
It's only available in Adwaita 1.8+
|
|
The callbacks aren't used by libomemo-c. The callbacks passed appear to
be buggy because the return value of `gcry_md_read` is passed to `free`,
but it is supposed to be automatically freed on `gcry_md_reset`.
Additionally, `gcry_md_reset` is called before the return value of
`gcry_md_read` is used, which is also against the documentation:
https://www.gnupg.org/documentation/manuals/gcrypt-devel/Working-with-hash-algorithms.html
> `gcry_md_read` returns the message digest after finalizing the
> calculation. […] The returned message digest is allocated within the
> message context and therefore valid until the handle is released or
> reseted (using `gcry_md_close` or `gcry_md_reset`. […]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Actually this was already supposed to work but at some point it
broke, probably in f44cbe02c17df1f02ad49c63cd784fec0ea02d85 when
AddListRow became a child of another widget during the GTK4 port.
|
|
|
|
Sending a disco#info <iq> on being banned from a room is wasteful, and
when _creating_ a room dino asks too soon, receives an error, and gives
up on syncing the room metadata giving subtle, hair-tearing inconsistencies
because flag.has_room_features() returns false for everything.
It's barely noticeable, because if you're banned from a room you
can't query it anyway (though in that case it's still a wasted <iq>),
and if you're creating the room all its fields are empty by default.
I noticed this because I'm experimenting with https://modules.prosody.im/mod_muc_defaults;
dino incorrectly shows moderation off when it should be on in newly
created rooms.
|
|
|
|
fixes #1390
closes #1399
|
|
fixes #1822
|
|
|
|
|
|
|
|
Fixes #1243
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
interface
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Odd heights, while generally handled by Gstreamer, can cause issues in
various places - most importantly hardware video en-/decoders and
GL/VK drivers - as in most cases 2x0 or 2x2 subsampled intermediate
pixel formats are used (such as I420, YUYV, NV12 etc.).
Thus ensure we always end up with an even height.
|
|
Most used widths can be devided by 4*3 as well as 16*9, resulting in
heights being multiples of two. There are two exceptions, though:
360 (/16*9=202.5) and 400 (/16*9=225).
Odd heights, while generally handled by Gstreamer, can cause issues in
various places - most importantly hardware video en-/decoders and
GL/VK drivers - as in most cases 2x0 or 2x2 subsampled intermediate
pixel formats are used (such as I420, YUYV, NV12 etc.).
Thus tweak the widths in question so they can be cleanly devided 16*9
and 4*3 with even results, as these are the most common ratios for
cameras.
|
