KEncodingProber vs "unexisting" codecs

[Albert Astals Cid]

El Diumenge, 24 de maig de 2015, a les 16:57:38, Aleix Pol va escriure:
> 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.

Well basically the only purpose of the class is giving you a codec name to use 
on QTextCodec, so it's not that weird.

> 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).

The problem with that solution is that it does not fix all the code we already 
have with the suggested "typical use" from crashing, that's why i'd prefer to 
fix that instead of adding ::codec.

If we end up agreeing on implementing a ::codec, I think it should not return 
QTextCodec::codecForName(encoding()) and if null return 
QTextCodec::codecForName(default), it should return the existing-most-matching 
codec for the feeded data.

FWIW this is motivated by https://bugs.kde.org/show_bug.cgi?id=346129

Cheers,
  Albert

> 
> Aleix
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel