this is just a very simple approach to move forward.
to mark overridden names, a "~" is prefixed.
the idea with using a dedicated color for these names:
as we do not really know
if the address is a generic sender address or belongs to the user,
it makes sense to keep the color used for the name and do not use a
dedicated grey or so.
i think, it is not even worth to detect that better:
it is pretty nice to have senders in mailinglist marked nicely,
all the time.
currently, the "~" is only added to the bubbles - it is not there
in the chatlist-summary (that would needed to be done in core)
and also not in forwarded by, notifications, clipboard etc. i'd say currently,
this is not needed, however, with the current approach it would be doable
(if we mark possible impersonation by colors or icons that may be
much more complicated)
adaption on other uis would also be pretty simple with this approach,
and imho, this `~Max Mustermann` looks pretty nicely
and even intuitive in a way.
drawback of the approach is that user may user `~`
as the first character of their names, we could target that by
adapting dc_msg_get_displayname() in the core, if we want to keep this approach,
however, maybe it is also not worth, the "~" is more a flaw than a feature,
also that would result to "~~Name" in the bubbles.
i do not see how that can be used to trick users when beeing added.
names as "foo 🔒" might be more dangerous here, when it comes to trick users.
* 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>
add a static boolean doReinitializeDraft that is set to true in onPause() if this activity was started using startActivityForResult(). in onResume(), do if(doReinitializeDraft) { initializeDraft(); }.
Some people reported that drafts were disappearing, and I found a way to
reproduce it (my interpretation in brackets):
- Open Saved Messages chat, could be any other chat too
- Go to another app and share to DC
- In DC select Saved Messages
- (as sharing is done using startActivityForResult(), a second
ConversationActivity is created without affecting the existing one)
- Leave DC. (The second ConversationActivity will correctly save its
draft to the db)
- Open DC again from the "Recent apps". (The first ConversationActivity
will be loaded. It will not know that there is a newer draft and still
show the old draft, or nothing if there was none. When it's closed, it
will overwrite the draft)
I came to this conclusion by logging all writes to the draft in the db.
Also, when I set `REQUEST_RELAY` to -1 (`startActivityForResult(intent,
-1) will behave the same as `startActivity(intent)`) (but that's not a
solution, sometimes we need startActivityForResult(), see e.g.
https://github.com/deltachat/deltachat-android/pull/1412)
What's still a little weird: I tried replacing all calls to
`startActivityForResult(-intent for ConversationActivity-)` with
startActivity(), and the issue didn't go away. Apparently it's only
enough if all calls are replaced, which is the same as setting
`REQUEST_RELAY` to -1. Maybe it's enough if one activity in the call
chain is called using startActivityForResult().
The call to `initializeDraft()` makes the activity start & resume 2-3ms
slower, which is probably acceptable.
While going back and forth with activities & sharing, I also encountered
some more bugs (without trying to reproduce them), but they are not too
annoying (as opposed to losing your draft) and I'm hesitant to changing
the activity-switching logic too much as it is so easy to just break
things again.
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.
bjoern