Bug 207877 - A18Y: do not use hardcoded values for default (color scheme incompatibility)
Summary: A18Y: do not use hardcoded values for default (color scheme incompatibility)
Status: RESOLVED INTENTIONAL
Alias: None
Product: kmail
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Unspecified
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-19 13:02 UTC by Maciej Pilichowski
Modified: 2009-09-28 14:51 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2009-09-19 13:02:56 UTC
Version:            (using KDE 4.3.0)
Installed from:    SuSE RPMs

From what I see KMail uses for several items hardcoded values (example: unread message). This means KMail is compatible only with selected KDE color schemes -- scheme change (in KDE) can lead to getting dark blue text on dark brown background. Hardly readable.

My suggestion: instead of using hardcoded values for defaults for colors not covered by KDE global scheme, "link" internally colors 
KDE color -> KMail color

Since color scheme is well polished, this means with each change whole KMail would change dynamically and correctly. For example such links could be created:
KDE active -> KMail new
KDE link (not visited) -> KMail unread

This guarantees 100% working colors in KMail.
Comment 1 Maciej Pilichowski 2009-09-19 13:59:22 UTC
It is actually a bug, because KMail does not work correctly with KDE schemes (the default ones, not customized).
Comment 2 Martin Koller 2009-09-25 20:30:03 UTC
I currently count 21 colors you can define in kmail.
The colors have a meaning which is not available in the KDE color schema.
Some of the colors in kmail are used from the schema, e.g. link, visited link,
misspelled words, etc.
Comment 3 Maciej Pilichowski 2009-09-25 21:26:39 UTC
Martin, the number is not important (*).

The question is what is the more productive and useful way:
a) copy colors from KDE scheme to make a match
b) force user to customize just "few" colors -- from KMail, Akregator, KNode, who knows from where

ad.a) I know the "important message" does not exists in KDE, but if you copy the value from negative, or positive, or normal, or anything like that color -- it is a match. If you hardcoded green, it means, user has to change the colors in KMail (and other apps with hardcoded colors) -- it is unproductive and not useful at all

Please reopen this report. Thank you.

(*) or it is, but in favor of this report (reopening). Think about 1 million colors. You still think it is better to customize that much colors to make the match, or dynamically copy the values from KDE?
Comment 4 Martin Koller 2009-09-25 21:35:53 UTC
Here is the current kmail code regarding color defaults (configuredialog.cpp):
  static const QColor defaultColor[ numColorNames ] = {
    QColor( 0x00, 0x80, 0x00 ), // quoted l1
    QColor( 0x00, 0x70, 0x00 ), // quoted l2
    QColor( 0x00, 0x60, 0x00 ), // quoted l3
    scheme.foreground( KColorScheme::LinkText ).color(), // link
    scheme.foreground( KColorScheme::VisitedText ).color(),// visited link
    scheme.foreground( KColorScheme::NegativeText ).color(), // misspelled words
    Qt::red, // new msg
    Qt::blue, // unread mgs
    QColor( 0x00, 0x7F, 0x00 ), // important msg
    scheme.foreground( KColorScheme::LinkText ).color(), // action item mgs
    QColor( 0x00, 0x80, 0xFF ), // pgp encrypted
    scheme.background( KColorScheme::PositiveBackground ).color(), // pgp ok, trusted key
    QColor( 0xFF, 0xFF, 0x40 ), // pgp ok, untrusted key
    QColor( 0xFF, 0xFF, 0x40 ), // pgp unchk
    Qt::red, // pgp bad
    QColor( 0xFF, 0x40, 0x40 ), // warning text color
    scheme.foreground( KColorScheme::NegativeText ).color(), // close to quota
    Qt::lightGray, // colorbar plain bg
    Qt::black,     // colorbar plain fg
    Qt::black,     // colorbar html  bg
    Qt::white      // colorbar html  fg
 

If you think you find a better mapping, please make a proposal (or even better: produce a patch).
Thanks.
Comment 5 Maciej Pilichowski 2009-09-28 14:51:43 UTC
Learning how to compile and make patches is on my to do list, so sorry but not now (yet).

Please take a look:

  static const QColor defaultColor[ numColorNames ] = {
    scheme.foreground( KColorScheme::NeutralText ).color(), // *quoted l1
    scheme.foreground( KColorScheme::NeutralText ).color(), // *quoted l2
    scheme.foreground( KColorScheme::NeutralText ).color(), // *quoted l3
    scheme.foreground( KColorScheme::LinkText ).color(), // link
    scheme.foreground( KColorScheme::VisitedText ).color(),// visited link
    scheme.foreground( KColorScheme::NegativeText ).color(), // misspelled
words
    scheme.foreground( KColorScheme::ActiveText ).color(), // *new msg
    scheme.foreground( KColorScheme::NeutralText ).color(), // *unread mgs
    scheme.foreground( KColorScheme::NegativeText ).color(), //* important msg
    scheme.foreground( KColorScheme::LinkText ).color(), // action item mgs
    scheme.foreground( KColorScheme::InactiveText ).color(), // *pgp encrypted
    scheme.background( KColorScheme::PositiveBackground ).color(), // pgp ok,
trusted key
    scheme.foreground( KColorScheme::NeutralText ).color(), // *pgp ok, untrusted key
    scheme.foreground( KColorScheme::NeutralText ).color(), // *pgp unchk
    scheme.foreground( KColorScheme::NegativeText ).color(), // *pgp bad
    scheme.foreground( KColorScheme::NegativeText ).color(), //* warning text color
    scheme.foreground( KColorScheme::NegativeText ).color(), // close to quota
    scheme.foreground( KColorScheme::NormaBackground ).color(), //* colorbar plain bg
    scheme.foreground( KColorScheme::NormalText ).color(),     //* colorbar plain fg
    scheme.foreground( KColorScheme::NormalBackground ).color(),     // *colorbar html  bg
    scheme.foreground( KColorScheme::NormalText ).color()      //* colorbar html  fg

changed colors are marked with "*" after //. Such set maybe is not beautiful, but safe and useful -- i.e. it always work no matter what scheme is set for entire KDE.