Bug 371826

Summary: Kmail new mail systray icon invisible unless hovered
Product: [Applications] kmail2 Reporter: Martin van Es <bugs>
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED DUPLICATE    
Severity: normal CC: aboris, asturm, daniel, ebravo, eliadevito, lrajchel1981, martin.schnitkemper, nortexoid, notmart, oleksandr, romainguinot, tterranigma, wbauer1, winter
Priority: NOR    
Version: 5.2.3   
Target Milestone: ---   
Platform: Other   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=374653
Latest Commit: Version Fixed In:
Attachments: Video showing new mail icon hover behaviour
Unread messages represented with a dot on an icon

Description Martin van Es 2016-10-29 15:07:21 UTC
Created attachment 101877 [details]
Video showing new mail icon hover behaviour

My Kmail new mail icon is activated on new mail, but allways invisible unless I hover over the icon, as can be seen in the attachment.
Plasma: 5.7.5, Breeze icon theme, dark panel.
Comment 1 Christoph Feck 2016-12-20 18:42:23 UTC
*** Bug 373915 has been marked as a duplicate of this bug. ***
Comment 2 Daniel Eklöf 2016-12-24 10:15:06 UTC
Seeing the same thing. Also dark theme, in case that matters. kmail2 5.4.0 (16.12.0)
Comment 3 Marco Martin 2017-01-09 16:42:46 UTC
does the same machine also has wrong colors for other kstatusnotifier based icons?
one example is konversation.
if konversatio has a white icon while kmail a black one, then is the icon svg to be broken
in
https://cgit.kde.org/kmail.git/tree/src/kmsystemtray.cpp#n71

i see that an icon called "kmail" is looked for.

the systray takes it from the plasma theme, and that is a correct svg, and colors correctly, at least in master

what version of plasma-framework is used?
Comment 4 Daniel Eklöf 2017-01-09 17:48:32 UTC
Konversation works (icon is visible in systray).

Plasma-framework version is 5.29.0.

Breeze-icons (which contains /usr/share/icons/breeze/apps/48/kmail.svg, which I assume is the icon being loaded?) version is 5.29.0.

And, to clarify; my overall "look and feel" theme is Breeze. However, I've changed  the "Desktop Theme" to Breeze Dark.

Changing the icon theme to Breeze Dark makes no difference.

If I change the Desktop Theme to Breeze (regular, non Dark), I can see the kmail icon again. Switch back to Breeze Dark and it disappears again.
Comment 5 Daniel Eklöf 2017-01-09 18:03:57 UTC
I just realized the icon I'm now isn't the regular kmail icon, but the "new unread" (mail-unread-new.svg?)

Opening this one (regular, non-dark Breeze icon theme) makes it pretty obvious why it isn't visible; it's dark.

Now, here's what I find weird:

a) The dark version of it is considerably brighter, and *should* be visible. But isn't. Unless there's a bug in the cache handling of it.

b) as already mentioned, we do see it when it's hovered. Regardless of whether the normal Breeze or the Dark icon theme is used.

I have no idea how it's supposed to work, or who's responsible for providing the hovered vs. non-hovered icon. But it seems something is wrong with how the non-hovered icon is rendered.
Comment 6 Romain GUINOT 2017-02-28 09:36:44 UTC
I also confirm this bug. 

Fedora 25. Kmail 5.4.2. plasma 5.8.5. 

kdepim-runtime-16.12.2-1.fc25.x86_64
kdepimlibs-4.14.10-17.fc25.x86_64
kf5-libkdepim-16.12.2-1.fc25.x86_64
kdepim-common-16.12.2-3.fc25.x86_64
kdepim-runtime-libs-16.12.2-1.fc25.x86_64
kdepimlibs-kxmlrpcclient-4.14.10-17.fc25.x86_64
kdepim-apps-libs-16.12.2-1.fc25.x86_64
kdepimlibs-akonadi-4.14.10-17.fc25.x86_64

related as well to 365138. The icon is completely invisible on a dark panel and barely visible when you hover over it. see attached screenshots on 365138.
Comment 7 Łukasz 2017-03-15 00:59:15 UTC
I confirm this bug with F24 and KMail 5.4.2.

Another thing is that the message count has been replaced with a simple dot over an envelope, which also makes things less readable than in the past when the icon was clearly visible and so was the unread message count.
Comment 8 Michael D 2017-03-18 09:43:32 UTC
I suppose this is a duplicate of bug 354820
Comment 9 Martin van Es 2017-04-22 09:16:05 UTC
After upgrading to KDE PIM 16.12.3 from Zesty backports (KMail 5.4.3) the behaviour has become worse. I used to have a work around by displaying number of new unread mail over the invisible new mail icon, but this feature has now been removed from PIM 16.12.3!?

I don't see the simple dot described in comment #7 btw.
Comment 10 Łukasz 2017-04-22 21:56:30 UTC
Created attachment 105153 [details]
Unread messages represented with a dot on an icon

I still see the same behaviour with KMail 5.4.3 with kde-pim 16.12.3.

I add an attaachement showing the dot from comment 7. Above the KMail icon sits a Choqok icon with unread message count shown by a number, just as KMail did it before.
Comment 11 Oleksandr Natalenko 2017-05-20 08:31:27 UTC
Confirming this with KMail 5.5.1, Arch Linux and Breeze Dark theme.
Comment 12 Nikolaos Kakouros 2017-05-24 16:34:54 UTC
I also have this on kmail 5.5.1 on arch. I think the icon is also the same used for the instant messaging thing. Also, using cuttlefish and searching for "unread" I could find a white icon that could be visible on dark panels.
Comment 13 Martin van Es 2017-09-05 08:20:33 UTC
I made a work-around by editing /usr/share/icons/breeze/actions/22/mail-mark-unread-new.svg in inkscape and setting fillcolor of the svg to light-grey'ish. Then removed ~/.cache/icon-cache.kcache, restarted plasmashell (killall plasmashell; plasmashell&) and restarted kontact.

While investigating the problem, I noticed that when replacing mail-mark-unread-new.svg with media-playback-pause.svg (which shows completely fine in systray) kmsystemtray.cpp renders media-playback-pause.svg also invisible. So my conclusion is that it's not a problem with the icon svg, but the way kmsystemtray.cpp tells Qt to render it on unread mails. I lack the Qt knowledge to further investage this.
Comment 14 Wolfgang Bauer 2017-09-08 13:48:32 UTC
I would say this is a duplicate of bug#365297 ...
Comment 15 Allen Winter 2017-09-08 17:08:41 UTC

*** This bug has been marked as a duplicate of bug 365297 ***