tier1/kcodecs, deprecate KEncodingDetector, favor KEncodingProber

[nihui]

hi all

I'd like to join the fun of kde fr5 efforts.
here is my first proposal on tier1/kcodecs
currently, kcodecs has three parts

class KCharsets, match codec using alternate names
namespace KCodecs, convert misc encoding
class KEncodingDetector and KEncodingProber, encoding detection

KEncodingDetector and KEncodingProber do mostly the same thing, and I suggest deprecating/removing KEncodingDetector
Here are the reasons:

KEncodingDetector seems to come from khtml, it has some capability to deal with html/xml and http header and some khtml-like codes. KEncodingProber is more generic and clean without any khtml and xml parsing codes.
KEncodingDetector is not fully implemented, it only handles Arabic, Baltic, CentralEuropean, Cyrillic, Greek, Hebrew, Japanese, Turkish and WesternEuropean, while KEncodingProber is more powerfull with addition capability on ChineseSimplified, ChineseTraditional, Korean and Univeral detecting mode, etc.
http://lxr.kde.org/ident?i=KEncodingDetector says that KEncodingDetector is mostly used in khtml, simon import codes and kdeui/actions/kcodecaction.cpp for setting encoding menu. porting to KEncodingProber should be easy in the later two cases since they only use the encoding detection functions.
So it shall make sence to move KEncodingDetector class back into khtml, reduce class duplication in kcodecs.

I can help porting and doing this task if it is acceptable.
any comments are welcome.

regards,
nihui

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120626/b8c05226/attachment.html>