* add 'New Group or Subject' to contact profiles and allow group creation from there
* preselect contacts on group-creation from profile
* remove dead code
* also for existing group-creation, do not finish calling activity needlessly (this is pretty unexpected behavior)
* on editing groups, just use isProtected() from the chat to edit
* make new 'join group' strings translatable
* remove now superfluous group-join-progress-dialog
* remove thread-back-to-main roundtrip, joinSecurejoin() should return fast enough, not much different from any other chat creation
it was removed to have some less menu entries,
however, on recent discussions,
it turns out clearer and clearte that this will break some workflows
(writing text first, then adding attachment).
i just had a look at other "large" messengers -
all of them support "write text, then add attachment" -
as well as our iOS and Desktop apps.
also, this order seems to be pretty normal when it comes to "E-Mail".
all in all,
i think, we should not sacrify this workflow just to save one menu entry.
at some point,
maybe we want to have the "Attach" button always visible left of the input bar
as most other messengers do (as well as iOS and Desktop),
however, this is a larger thing and also has its drawbacks on smaller screens.
so, just leave things as is seems not to be the worse idea here.
the "View Profile" menu entry, however stays, removed,
so, there is some cleanup.
editing name/avatar is only possible when one can send to a chat;
for the menu entry, this is already checked (the menu entry is hidden then),
but it was forgotten on avatar tapping.
remove the "progress" dialog that shows up for a fraction of a second.
as all accounts are already in memory since the switch to dc_accounts_t,
there is nothing that can take so much time to satisfy a "wait" dialog.
the switching is now at least visually nicer -
however, due to less task switching and less code,
it should also be a bit faster.
Fix shared image being set as draft repeatedly (Fix#2040)
The problem was that
if (isDirectSharing(this)) {
openConversation(getDirectSharingChatId(this), -1);
}
was called in refreshTitle(). But refreshTitle() is also called everytime the connectivity changes, so everytime the connectivity changes a new instance of ConversationActivity was opened.
The last three commits are actually independent (but I think uncontroversial) improvements, if you want I can also make a separate PR for this.
bjoern