[Kde-pim] KMail auto-lighted icon

[Ingo Klöcker]

On Wednesday 05 December 2007, Jakob Petsovits wrote:
> Hi list,
>
> here's a slight adaption of KMSystemTray that doesn't require a
> "kmail-light" icon to exist, but instead takes the existing icon and
> transforms it so that it gets a bit lighter for the blue (hardcoded!
> evil!) text to be readable.

Excellent! When I tried to do the same years ago I failed and therefore 
added the kmail-light icon instead. I'm glad that we'll finally be able 
to get rid of this hack.


> Not made transparent, as that could hurt 
> with dark backgrounds. That patch (kmail-autolight-icon.diff) looks
> quite good for both light and dark base icons, as long as the
> background is light.
>
> For all of that to work with all combinations of light and dark
> backgrounds as well as light and dark number text, one has to be more
> carefully as the amount of possible combinations is much higher. I
> had a go at it, and tried a lot of stuff out, the second attached
> patch (kmail-autotransparent-icon.diff) is the result of that.
>
> It fiddles a bit with various KIconEffect calls, but that keeps us
> from using qimageblitz as additional dependency, and still looks ok.
> I tested with various different icons ("kmail", and "kde" as
> representative dark icon), and with different color schemes. I placed
> readability of the unread mails number (in all cases) over having
> good sight at the icon, if you would prefer a more solid icon for
> less readability in some cases then remove the second (=last)
> occurrence of the line
>
> KIconEffect::semiTransparent( overlayImage );

Can you probably send a few examples to the list?


> It seems the transparency bug that was described in the extensive
> comment is gone as well, works now by just painting on the QPainter.
> (It's been a long time since 2003.)

Great. I really hated having to use such an ugly workaround for 
something that should have been as easy as it is now.


> So that's that, you might want to apply one of those patches in the
> one or the other form.
>
> When fiddling with KColorScheme, I also tried to assign the colors in
> there to the mail view colors, see the third patch for that.
> (kmail-custom-colors-kcolorscheme.diff) No idea if you like that or
> not - it's certainly cleaner and more generally applicable, but you
> still need to enable "Custom Colors" to get a color scheme that is
> roughly compatible to current KDE defaults. Also, it hasn't got that
> characteristic red/blue distinction between new and unread mails as
> it uses active and visited link text colors. Know that I'm totally
> indifferent on that issue.

I don't like the usage of NeutralBackground as color for encrypted 
messages (was blue) and untrusted signed messages (was yellow). 
Moreover, I don't really see the reason for deriving all custom colors 
from KColorScheme. It's okay to use colors from KColorScheme if there's 
a suitable role, e.g. PositiveBackground, NeutralBackground, and 
NegativeBackground for the various signature state background colors 
and NegativeText for misspelled, but it doesn't make sense to force 
KColorScheme colors on everything.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20071207/2bb8413e/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/