* fix: Use msg.getFilename() instead of the file's name in some cases
* fix: Use msg.getFilename() instead of the file's name in initializeDraft()
* fix: Use msg.getFilename() instead of the file's name in MediaItem
* fix: Use the correct file name in MediaView
* refactor: `msg` param of `getManuallyCalculatedSlideInfo()` was always null
* Improve comment
* Revert "refactor: `msg` param of `getManuallyCalculatedSlideInfo()` was always null"
We will unfortunately need getManuallyCalculatedSlideInfo() with `msg`
param
This reverts commit 60e8248db32dc22812d3f23da194bab644802045.
* fix: Fix drafting images
This fixes a bug introduced in 14f69f87e8b11a7d0568e58593946a1f1c01e75e:
When you drafted an image, pressed Back, and opened the chat again, then
the height of the drafted image was wrong and tapping the image opened a
preview for the wrong image.
I do think that theoretically it would be nicer to use getSlideForMsg
here, because we already have a DcMsg, but this didn't work because a)
the width and height wasn't gotten from the msg and instead 0 was passed
and b) the code tries to save a msgId instead of the message instead,
and loading the message from the database fails later since it's just a
draft.
I didn't want to try and fix these things, because they might be bigger
refactorings and I don't know the code.
* fix: Use the original message's filemime if there is one
...instead of trying to guess the mimetype from the uri
* Make the attachment background the same as the input bar background
Two different users recently complained that they find drafting images confusing. One of them thought that they had already sent it, the other one didn't know how to send it (both of them figured it out after ~10s, but still, it's nicer to avoid such confusion). In both cases, the problem was that the background of the attached file is the same as the chat background, not the same as the input bar, even though the attached file belongs to the input bar and not to the chat.
* Add a stroke around the to-be attachment
the email-address was removed for guaranteed-e2ee chats quite a while ago
(https://github.com/deltachat/deltachat-android/pull/2916) reason was, among others,
that these addresses are often chatmail and therefore random.
(despite expecting otherwise, that was fine for most users).
this PR removes the email-adress unconditionally:
- having the email-address sometimes shown and sometimes not is confusing,
and easily looks like a bug.
this has become worse with the added vcard-support
(before, there were rare non-guaranteed chats in chatmail) -
resulting in more random addresses being shown
- _always_ protect against over-the-shoulder attacks
- better privacy in screenshots sent around without thinking much before
(cmp. https://github.com/deltachat/deltachat-ios/pull/2329)
- wrt impersonation attacks:
the pure email address in the subtitle did never protect against impersonation,
one could always get sth. trustworthy looking there,
it is better to check the profile with additional information (eg. other chats) if in doubt
- general cleaner, uncluttered layout
- pave the way of the upcoming multi-addresses
drawback is that sometimes one more tap is needed to access the email-address -
however, as it is _always_ one tap away now,
this can also go easily to the finger memory.
it is regarded as a bug
and esp. weird in translations.
it was regarded to be a bit 'nerdy' that time to write it lowercase,
but it seems we have to get more serious now.
This PR removes prepareMsg, which put messages into the OUT_PREPARING state and was used while videos were recoded. It also removes the now-unused method isIncreation().
- It was buggy because when you forwarded a message while it was InPreparation, or when the app was killed while a message is InPreparation, the message would stay InPreparation forever.
- Android is the only UI using this InPreparation (according to @r10s, I didn't check this myself), so we can simplify some things in core, which will also make it easier to deduplicate blob files.
this PR centers the icons in the attachment selector,
the right-aligned ones looks esp. odd when no experiments are enabled.
the default now looks good,
and when all experiments are enabled, things are perfect as well.
but even if only one experiment is enabled, things are better imo
(but we anyway should optimize for default and not for experimental options)
adbenitez