File::encodeName() and Utf8 as the default encoding under Qt5

[Lubomir I. Ivanov]

On 29 October 2014 18:27, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Wed, Oct 29, 2014 at 06:18:14PM +0200, Lubomir I. Ivanov wrote:
>> On 29 October 2014 18:02, Thiago Macieira <thiago at macieira.org> wrote:
>> > On Wednesday 29 October 2014 17:32:58 Lubomir I. Ivanov wrote:
>> >> now, i know how to fix the issue by simply not use File::encodeName()
>> >> at all on Win32 and use QString::toUtf8() instead but is there a
>> >> cleaner way with no #ifdefs?
>> >>
>> >> not sure if QTextCodec::setCodecForLocale() should be set to Utf8 on
>> >> Win32...
>> >
>> > Hmm... I'm not sure what will happen if you setCodecForLocale on Windows, I've
>> > never tried.
>> >
>>
>> just tried setting it to UTF-8 and the filenames work again
>> (QFile::encodeName()).
>> but i really have no idea of the more global consequences of this. if
>> it breaks other important areas perhaps the attached patch should not
>> be applied.
>
> Well, you and Thiago are the experts I look at when it comes to these
> things... what do we have to test to make sure this doesn't break things?
>
> We have a ton of Windows users on this mailing list, so as long as we know
> what to test this should be easy, I can make a new test binary in a
> heartbeat... :-)
>

i've browsed the Qt5 source for a while and it looks like that the
change affects QString::toLocal8Bit(), so i've tried some of the areas
where toLocal8Bit() is used in the app (Win32):

- cmd arguments: no problem (with special chars in filenames to open even)
- webservices: can't test it - says "INTERNAL_SERVER_ERROR"

i must admit that the whole concept locale codecs evades me a little...
unless Thiago is against this one and there are other Qt areas where
codecForLocale() is important, the patch works (tm).

lubomir
--