resent to the mailing list...
---------- Forwarded message ---------- From: Lubomir I. Ivanov <neolit...@gmail.com> Date: 17 December 2013 15:11 Subject: Re: [PATCH] Files: fix a path encoding issue on Windows To: "Lubomir I. Ivanov" <neolit...@gmail.com> Cc: Thiago Macieira <thi...@macieira.org> On 17 December 2013 15:05, Lubomir I. Ivanov <neolit...@gmail.com> wrote: > From: "Lubomir I. Ivanov" <neolit...@gmail.com> > > The Qt frontend currently uses a C backend e.g. file.c, > but Windows does things it's own way and we cannot quite > relly on methods such as open() to work for paths with > special characters. > > A solution for that is to always pass UTF-8 encoded filenames > (that may eventually reach file.c:readfile()) and then > if on Windows converted such to UTF-16 for use with > the Windows's specific function _wopen(). > > This possibly avoids re-writing file.c to use Qt/QFile. > from the UTF-8 thread: On 17 December 2013 03:25, Thiago Macieira <thi...@macieira.org> wrote: > Oh, we should also avoid 8-bit filenames as much as possible, Windows locales > are not Unicode-complete. Testcase: create C:\Temp\éΓЯ€\ and move one of the > data files there. Then try to open it. > > That would mean rewriting much of file.c to use QFile. At the very least the > read_file function, with filenames passed as an opaque type through C code. > does the above patch solve our win32 issue, thiago? and isn't fileNamePtr = fileNames.at(i).toUtf8(); the preferred way to do handle this compared to toLocal8Bit()? also, i know it adds #ifdef WIN32 in file.c which potentially can be abstracted for clarity in windows.c, linux.c, etc...if requested. lubomir -- _______________________________________________ subsurface mailing list subsurface@hohndel.org http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface