having 'add profile' at the end of the list is more natural,
and more consisten with desktop/iOS -
as well as internally, eg. proxy also has 'add' at its end.
also, this paves the way to have a consistent layout when it comes
to profile-switching from forward/share dialogs,
where one probably does not want to have a 'add' button
(so, the first lines are not different :)
the profile list is usually not super-large,
and even if - when ppl have managed to add 10+ profiles,
they'll know how to do this, even with scrolling :)
also, adding is a rare function, in contrast to switching,
so even then it makes sense as there is room for one more item without scrolling.
in contrast,
for 'create chat' we show 'add' at the beginning,
as these lists can contain several hundrets of entries _and_
add is often used.
do not show 'Add Profile' in bold.
this looks less cluttered
and makes the "bold" of the selected account more outstanding:
before, there were two types of "boldness",
the add profile button (using bold only)
and the selected profile (using bold and a background),
this results in a bit cluttered, unsteady look,
esp. when there are few accounts and more bold than normal is shown.
also, this makes "bold" more outstanding,
as this attribute is given to one line only.
there is no need for the "add profile" to be that outstanding
(in contrast to eg. the "add chat" dialog)
it is a minor, sure :)
With https://github.com/deltachat/deltachat-core-rust/pull/6027, when
exporting a backup, the counter stays at 0% while running housekeeping
and vacuuming the database, which takes 10 seconds on my device.
Showing "One moment... 0%" for 10 seconds (or longer on slower devices /
with bigger accounts) might make users think that it's not working and
abort the process. So, instead, simply show "One moment..." until the
progress reaches 1%.
Values 100, 350, 400, 450, 950 are not used in the core,
so this resulted in showing incorrect progress
such as "Preparing account" when actually
database transfer was already in progress.
Desktop already does not expect any special values
and simply shows the progress bar.
saying post-notifications-granted=false on API that do not need this grant
is misleading as it looks as some error or if the user has rejected sth.
just stumbled upon that and was irritated when trying out things wrt
https://github.com/deltachat/deltachat-android/issues/3281 on android7
'Dismiss' is a bit unclear - even though introduced at #2083 to make things clearer,
i do not think this has happened :) -
i also needed to dive into the source code to see what exactly 'Dismiss' is doing.
meanwhile, we're anyway using 'Mark Read' to remove unread counter from chats,
and this is basically the same. good to be consistent.
finally, this is also the term WhatsApp/Telegram are using.
closes https://support.delta.chat/t/what-does-dismiss-button-on-notifications-do/3261/3
nb: we also change the english 'short' term from 'Read' to 'Mark Read' -
this is sill shorter than many translations
and removes the ambiguousness 'Mark Read' vs 'Open for Reading" -
esp. in the notification without much context, this is better,
but also on iOS, where the term was introduced for, it is good to be explict.
when replying from within a notification,
the corresponding chat should be marked as being noticed as well.
otherwise, it looks wrong that one has replied to a chat,
but still the chat is shown as being "unread".
the 'reply' from a notification should leave the chat
in the same state as 'dismiss' resp. 'mark read' - plus the added message.
B. Petersen