KEncodingProber vs "unexisting" codecs

[Aleix Pol]

On Sun, May 24, 2015 at 7:18 AM, Albert Astals Cid <aacid at kde.org> wrote:
> One of the codecs that KEncodingProber can return is x-euc-tw
>
> But neither the Qt4 nor the Qt5 installed in my distribution understand that
> codec, so doing the suggested
>
>   QTextCodec::codecForName(prober.encoding())->toUnicode(data);
>
> Will crash.
>
> Not good.
>
> Two ways to fix this that i can think of:
>  * Go through all the probers and remove the ones that "don't exist" in Qt
>  * On runtime when creating the prober check if Qt understands it before
> testing if the data matches it
>
> The first is defenitely faster on execution time but is also less versatile
> and i don't know enough about QTextCoded internals to be sure all the codecs
> that are available in my ditro are available on distro X and viceversa, so
> maybe option 2 is better.
>
> Opinions and comments before i start implementing?
>
> Cheers,
>   Albert
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Hi,
Wouldn't that make the code slightly worse? I mean, if we can detect
the codec properly, removing that feature because Qt doesn't support
it seems odd.

Maybe we could create a wrapper function in KEncodingProber that
returns the codec? Something like: KEncodingProber.codec(). Then you
can check if it returns nullptr over there and use whatever feels
standard (and even notify somewhere that it wasn't found).

Aleix