But wait, that’s the same reason why I like to completely get rid of having to tell others that they have to keep looking out for new emails (contacts requests) in deltachat.
I think deltachat’s email-listening should do that, with almost no chats opened due to classic emails.
It’s different for myself, I’d like to be able to also check emails in deltachat, so I would enable the “show contact requests”.
It can be very annoying. I personally can’t bear any unread notification, so this badge and number combination would disturb me. On the other hand, I don’t wanna miss any important mail. The answer could be something more subtle, maybe a red dot next to the menu button? (a tiny little one)
it is not a notification, it is just a silent badge in an icon, also it is more useful to have a number than a dot, because if you have contact requests and receive a new one you will not know it, so you will miss it again
well i understand @Massick totally. an increasing number always yells out “there is something to do!” … “there is even more to do!” …
I disagree, that is only if you are in the chat list and have nothing more interesting to do, but in a chat you don’t even see this badge,
also it could be “9+” if the number is going too big, it don’t need to be “1000”
my main interest in using a number is to be aware of new contacts requests, using two-state signal like that red dot, will be a bit useless and users could still lost contact requests, I think the “9+” thingie could be a good point in the middle, not too stressful and still a bit more useful than a dot
also this will add an extra step to access contact requests, the good thing is that we could keep the QR button
That’s your opinion, and you’re wrong. It could be session locked, i.e. only appears if there’s a new request in the current session
no extra step, it’s the current way, the dot only tells you theres’s something for you to see (Chrome changes his menu icon when there’s some notification, i.e an upgrade).
Hi, thanks for your feedback. I just updated a default setting in Use-cases, chat rules and configuration options, accordingly
Of course DC should not require or put any workload on its users, like “there is a need to do (check for)…”.
With Classic email listening: "start-chat" metrics for classic email client messages (max. length & newlines), the “new email” counter should only be necessary for those that want to also monitor their classic email inbox manually (and directly) from within deltachat. The default chat user will simply just receive messages in new chats, and get a “start chat?” prompt only for a very small number of unclear emails. The “new emails” icon and badge can thus stay disabled by default.
I’m not against the unread notification itself (I need it myself) but the need of a new icon. It can be handled differently to what @adbenitez ask for.
Exactly, the badge is for people that want to be “annoyed” with a badge that has an “annoying” number inside, that actually want to know that “there is something to do!”
by default DC doesn’t show classic email, so there are no such problem, the icon can even be hidden, and if user has email interaction set to all it is because he/she actually want to be aware of emails, so we are talking about a fictional issue of chronic number phobia that don’t even exists, badges with numbers are much more useful than a dot, are used a lot and if you consider this stressful then remove them from the Delta Chat launcher icon because people could have a panic attack 
but before we start a pointless discussion between a boring dot and a sexy number 
I have to say that there are a real necessity for contact requests awareness when email interaction is set to all, so I don’t want to waste more time in this, whatever improve the current situation, I am ok with it 
no pointless discussion (in that case, what’s the point of this forum?), you still stuck in that badge idea.
@adbenitez only because all the hours you spent on gimp we don’t have to fall in love of your paintings, more so, dot are sexier than numbers, ask anyone
don’t be a dork, did you read:
what I meant with “pointless discussion” is that both solutions are “good enough” and that we just need a way to be aware of contact requests not keeping endlessly in theory.
the only one that seems stuck is you, I already say that I am ok with your dot or with whatever will make contacts request more visible, but instead you keep trying to go for a real pointless discussion,
about gimp, it was not that hard to do, and that was just something to start with, I don’t really care if it is a badge, a dot or a friendly pink pony popping up on the screen, just something that “Make Contact Requests more visible”
now stop being a dork 
now that you need to always have the last word, I’ll wait here for your next hater comment
Hi guys
I agree to " there are a real necessity for contact requests awareness when email interaction is set to all".
how to show that isn’t that important. a rising number or another simple indicator should be ok.
most important is that it comes!
Is someone working on that issue?
Once true email-to-chat interaction is a supported default based on simple start-chat metrics for email messages and a More useful "reachable by" chat interaction setting - #4 by monperrus is there, the hard necessity to show emails to catch contact requests should actually be softened a lot, because chat qualifying emails will then be simply received automatically.
Nevertheless, showing emails is still a very necessary feature to be able to check one’s email inbox, and so much required to be able to reply or answer to a classic email with a quick (interim) chat.
We need this too to see errors in smtp delivery! (one use case).
I think we need email displaying for various reasons. Just not for manually looking for “contact requests” or email delivery failures.
The failures need to be detected automatically, and may only need to be displayed to the user in a special error message with the raw text, if they can not be parsed and assigned to a recently sent message that does not yet have a delivery receipt.
Most if not all? failure receipts
From: MAILER-DAEMON@
From:To:Subject:Date:Which should already be sufficient to detect the affected, recently sent message.
But some failure receipts even contain
X-Failed-Recipients: header.Message-ID in the text body