[Development] Deprecating QFile::encodeName/decodeName

[Oswald Buddenhagen]

On Thu, Jun 07, 2012 at 12:33:04AM +0200, ext Thiago Macieira wrote:
> On quarta-feira, 6 de junho de 2012 21.21.28, Oswald Buddenhagen wrote:
> > >  3) make QProcess use QFile::encodeName for its arguments (no-op right
> > >now) 4) make QCoreApplication parse its arguments using QFile::decodeName
> > >(no-op>
> > > right now)
> > >
> > >  5) idem for Laszlo's command-line parser class
> > > 
> > 
> > no. see first paragraph. doing this would only increase the mess.
> 
> How do you figure making no-op changes increase the mess?
> 
it's not a no-op as soon as we actually implement some escaping
mechanism.
as joao pointed out, it is all about applying the decoding and escaping
at the right layer - which is _exactly_ when using posix file i/o
functions, and nowhere else. as soon as you start doing it with cmdline
args and the environment you are in workaround land, and that only
increases the mess (because you don't know what encoding the other side
uses - the only reasonable assumption is that it wants locale encoding
(because that would be the right thing to do)).

On Thu, Jun 07, 2012 at 09:18:16AM +0200, Knoll Lars (Nokia-MP/Oslo) wrote:
> On 6/6/12 9:21 PM, "ext Oswald Buddenhagen" <oswald.buddenhagen at nokia.com> wrote:
> >On Wed, Jun 06, 2012 at 05:36:30PM +0200, ext Thiago Macieira wrote:
> >> Anyway, what I recommend for now:
> >> 
> >>  1) immediately, de-inline QFile::decodeName and QFile::encodeName
> >>  2) un-deprecate them and update the text in changes-5.0.0
> >>
> >well, why not.
> 
> Ok, but only for the specific use case of converting arbitrary 8bit
> (including invalid sequences in the locale) to a QString and back. No way
> to set any decoder functions.
> 
ack

> What do we do with this on Windows? I am almost tempted to not even offer
> the methods there, as everything's utf16 anyway, so the problem doesn't
> exist.
> 
yes, on windows these functions make inherently no sense. i would have
expected them to be #ifdef'd in the first place.

> On Windows we need a different solution. There we
> actually get the arguments in utf16 on windows (in WinMain()). Currently
> we still use toLocale8Bit() in there, and that can/will probably break
> badly as local8Bit() on windows is usually not utf-8.
> 
> So qtmain_win.cpp needs some fixing anyway.
> 
yes, i recently discussed this with thiago, too.
my idea was to dictate utf8 encoding for main(), so lossless conversion
can be guaranteed.
the concern is that changing the encoding expectations of main() *will*
break existing code, silently.

an alternative which would be backwards compatible would be defining a
new x-platform 16-bit entry point, say, qtmain() (use of it could be
enabled with a qmake CONFIG flag).

.