* 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.
when forwarding to "saved messages",
the ui goes back to the chat and the position in the original chat
and shows a short "saved" hint.
this saves at least one tap,
and makes saving multiple messages easier
as you stay in context.
btw, this is also how telegram handles things
and makes the saving as easy to use as starring eg. in whatsapp.
forwarding messasges to other chats is not changed.
the warning about outdated apps
was pretty unreliable in the past -
because of too short timings
and also because of the "installation date"
and the fact that an "installer" was used, is not always reliable.
also, the "installer date" could be wrong -
if the installation was done when the clock was altered badly.
as we cannot rely on the things the system provides here,
we move the whole thing to the core at
https://github.com/deltachat/deltachat-core-rust/pull/1901
which has also the advantage that this is done for all uis then.
errors that should be shown to the user
come from DC_EVENT_CONFIGURE_PROGRESS(data1=0) as data2 now;
there is no need to show the captured error any longer
(which was unreliable and hard to handle from core site).
there is some capturing-code left as needed for other parts,
but it is not used for configuration anymore.
while it is more straight-forward to let the system ask the user directly -
as we do for most other permissions -
this is probably not favorable for requesting ignore-battery-optimization:
- other permissions requests are preceded by a clear user intention -
tap on the camera, record voice etc.
so it is clear to the user why a permission is needed.
this is not true at the moment after installation
(maybe the moment can be improved, btw)
- different systems have completely different text,
partly focusing on "battery drain" - it is not clear to the user
what would be the advantage of that
- some guidelines say, user interaction is needed before querying permission.
there is room for interpretation, of couse,
however, adding a rational with a "continue" button
seems to fit better to these guidelines.
B. Petersen