in a multi-device-setup,
if deviceB scans a setup-contact QR code shown on deviceA,
it is misleading to say that the QR code was withdrawn
and can be revived.
actually, the QR code was never withdrawn by the user.
this is fixed by this pr.
(at some point, we want to sync QR codes across devices,
but even then, there may be siutuations where things are not in sync)
moreover,
the wording is more explicit about what is usually done with the qr code;
this is esp. helpful, when scanning a printed QR code without much context.
the code-part of this pr is pretty simple, most work was already done in core at deltachat/deltachat-core-rust#2512
* add DC_QR_{WITHDRAW|REVIVE}_VERIFY{CONTACT|GROUP} constants
* ask to withdraw/revive qr codes
* reword redraw hints, fix typos
* reword revive statement
* Update res/values/strings.xml: Add "by others"
* Apply suggestions from comradekingu's code review
Co-authored-by: Allan Nordhøy <epost@anotheragency.no>
Co-authored-by: Hocuri <hocuri@gmx.de>
Co-authored-by: Allan Nordhøy <epost@anotheragency.no>
The non-squashed original commits are available at 243bd3a56:
* First, quick and dirty version
* Basic HTML connectivity view
* Codestyle, automatically refresh
* Make it accessible from the settings
* Improve usability
I did some user-testing with my family, these are the results:
- Added an emoji to the html page (red dot for not connected, and so on)
- Adapted error messages for SMTP:
"Not started" -> "(You did not try to send a message recently)"
"🟢 Connected" -> "🟢 Your last message was sent successfully"
- "Not connected" is misleading, because they think that this means that there is no internet connection.
But "Not connected" can have other causes, like, a not responding server or a changed-but-not-updated-in-DC password
Possible solutions:
- "Not connected" -> "Not connected with gmx.de" (or whatever comes after the '@' in configured_addr). The problem: some people have an own domain for their emails, but no own servers. "Not connected with <your domain>" and might make them think that the problem is that DC tries to connect to the server <your domain>, while the server is hosted at Strato.com.
- We can ask the system whether there currently is network and then show another error message. The problem: Sometimes the system is wrong.
* Remove error_network
* Remove server_response string
* Move `getConnectivitySummary()` to `DcHelper`
* Implement the changes we agreed on
* Remove string error_no_network
* small fixes
* Clarify disappearing message hint
I got the user feedback that it's not clear that this setting only applies for this chat/group and is not a global setting like device/server deletion
* incorporate feedback to disappearing messages hint
Co-authored-by: B. Petersen <r10s@b44t.com>
we keep using the screenlock for "Backup" and "Manage keys";
these dialog always used the wording of the "global" screenlock,
sth. as "Please Unlock Delta Chat", however, that wording was always wrong
as Delta Chat itself is not locked in these situations.
this pr sets the title to the selected action
and just says "Please enter system secret to continue."
moreover, the toasts on canceling the action are removed,
they do not make much sense here,
there was a user action just before, so that is pretty clear anyway.
* Remove screen lock feature, move the two remaining "App access" options into "Advanced"
Locking the app was removed a long time ago, so in "App access" in the
settings, the only two remaining items were "Screen security" and
"Incognito keyboard".
* Remove the now-unused strings
* remove app-access-category from main settings screen
Co-authored-by: B. Petersen <r10s@b44t.com>
* Adapt to mailing lists
* Change the question if this is a mailing list (untested)
* rm unused fn
* Adapt to getSenderName -> getOverrideSenderName (untested)
* Use dc_msg_get_sender_first_name() because sometimes the first name was not correctly shown in mailing lists
* Don't let the user modify mailing list groups
* Fix crash
* Make Unnamed newsletter translatable, make the subtitle of mailing lists "Mailing list"
* tweak and hide some controls for mailing lists
* Update src/com/b44t/messenger/DcChat.java
Co-authored-by: bjoern <r10s@b44t.com>
* adapt to new dc_msg_get_real_chat() api, remove dc_msg_get_sender_first_name()
* remove now dead code
* add mailing list name to contact-request-question
move question-creation to a helper class
to avoid duplicated code.
* fix DcMsg.getOverrideSenderName()
* adapt to new dc_decide_on_contact_request() api
* re-allow changing name+image for mailinglists, see recent discussions on PRs
* remove memberlist- and settings-tab from mailinglist profile until there is some use for them
* adapt to new DC_CHAT_TYPE_MAILINGLIST type
Co-authored-by: Hocuri <hocuri@gmx.de>
While 4 weeks always fits in a month,
5 weeks (35 days) always covers at least a month,
so it can be used in a situation where messages are required to
be stored for a month.
* add get-mime-original apis
* remove unused control
* add 'Show full message' buttons
* split reusable WebViewActivity from LocalHelpActivity
* add FullMsgActivity
* load html via AsyncTask
* adapt to changed api
* handle mailto:-links in WebView
* block loading remote images by default, add user setting always/once/never
* do not hide 'Once' button in always-mode, playing around a day with hidden 'Once' that looks more like a bug :)
* wording: as 'Always' affects all messages, it is better to speak of multiple senders
* wording: use 'Load remote images'
this makes it easier for the user to find the option
if one sees, images are missing in the document.
* wording: shorten text.
* wording: change 'may' to 'can'. 'may' sounds a bit as if someone allows this.
* Don't use AsyncTask
* check 'once' if appropriate
* use lite-colored checkbox-emoji in dark-theme
* add comment about missing error logging
Co-authored-by: Hocuri <hocuri@gmx.de>
fix maybe #1748. Maybe not, because actually I don't understand why
issue #1748 even happened because we don't use the system background for
the bubble but an own one (see conversation_item_sent.xml:50). Probably
the system is somehow trying to forcefully create a dark mode.
So, let's see whether this PR fixes the issue, if not, I'll try again.
when server-deletion is enabled,
always show a hint about the impact below the option.
the hint is a summary of the conformation-dialog
so that the user is more aware of the impact
if enabling was some time ago
or the option was even enabled by the provider-db.
this pr changes the wording,
not relativize things, underlining the worse impact.
i avoided adding "maybe" or "potentially" here,
even if that would be more accurate.
moreover, the pr adds some red color and emojicons.
B. Petersen