Future of some functions in the class KCharsets

[Nicolas Goutte]

I am trying to improve KCharsets, especially to meet the KDE I18N policy and 
to adapt it to the reality of Qt4's QTextCodec.

Looking at the class I have three questions:
- the future of the entity functions (for HTML)
- the future of KCharsets::languageForEncoding
- the future of UTF-7 pseudo-support.


First the entity functions. There are four of them:
KCharsets::fromEntity (in two variants)
KCharsets::toEntity
KCharsets::resolveEntity

As the functions are not related to QTextCodec and as the KCharsets class has 
changed its main purpose since Qt2/KDE2, I intend to move them out in they 
own class. 

I propose the name KEntity for that class. (I have chosen the singular form, 
as there is already a file entities.c which is related.)


Now to the second problem: KCharsets::languageForEncoding
I propose to remove the function entirely. If an application adds other 
encodings top the list, it can do it directly with a full description 
including the encoding name and does not need a support from KCharsets.
(That would be better than having "Other encoding (FOOBAR)".)
Also an application should not be encouraged by KDE to add encodings.


To the third problem: UTF-7
KCharsets defines UTF-7 in the list of encodings but Qt does *not* support it. 
I propose to remove it from the list, especially that the further use of 
UTF-7 should not be encouraged and UTF-8 should be used instead.

Have a nice day!