[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 84702] feature: fallback functionality,
From:       Till Adam <adam () kde ! org>
Date:       2004-10-21 21:47:41
Message-ID: 20041021214741.17991.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
        
http://bugs.kde.org/show_bug.cgi?id=84702        




------- Additional Comments From adam kde org  2004-10-21 23:47 -------
On Thursday 21 October 2004 23:16, S.Burmeister wrote:
> How do you define best we can do?

Best way to solve it we could come up with so far.

> The better of two solutions, at least from my point of view, is the one
> that solves more issues. As you can see in my case and in most others the
> current functionality does not solve more problems than a two level fall
> back functionality.

It was not clear to me that you were suggesting a two level fallback.

> Encoding set to Auto -> if charset header exists: use charset header -> if
> user set "fall back charset" exists, use it -> if not fall back to charset
> set by the system.

Currently we use the concept of an override codec, rather than a fallback 
codec. So unless the setting is auto, which means "use what the mail 
specifies", we override what the mail says with what the user explicitely 
selects. I wasn't around when that decision was made, so I can't tell you the 
exact reasoning for it. Maybe it makes more sense to change that to a 
fallback rather than an override.

> This definitely solves more issues than the current way and is hence
> better. Although I am not too familiar with C++ I think that another
> if-statement, checking whether the user has set a "fall back charset"
> should not be too hard to implement.
>
> Can you point me to the the place in the code where kmail checks which
> charset to use for the email?

The code in question is in kdepim/kmail/kmreaderwin.cpp. The codec is 
requested in several places, but the relevant bit for your case is probably 
around line 1670 and following.
[prev in list] [next in list] [prev in thread] [next in thread]