[Development] Deprecating QFile::encodeName/decodeName

[Oswald Buddenhagen]

On Thu, Jun 07, 2012 at 01:02:31PM +0200, ext Thiago Macieira wrote:
> On quinta-feira, 7 de junho de 2012 11.52.34, Oswald Buddenhagen wrote:
> > > I disagree.
> > 
> > you need to provide arguments which refute my "it only makes things
> > worse" stance.
> > 
> > > Maybe you'll want to revert this then:
> > > https://codereview.qt-project.org/#change,22854
> > 
> > indeed
> 
> My argument is the above change: it makes sense to me. And because I do not 
> accept the argument that the command-line should have its own encoding. On 
> Unix, it's raw 8-bit C strings.
> 
> Imagine a Qt application run from the command-line with:
> 
> 	qtapp *
> 
> In that directory there is a file name with broken encoding. The shell will not 
> recode (which is why I don't by the command-line encoding argument).
>
yeah, too bad.

> The Qt application should be expected to work and interpret it that
> argument properly.
> 
and how? have you read the part about the encoding being mount point
specific? how does the application know whether the caller did 8-bit
pass-through or actually did the right thing and recoded to the locale
encoding (which would be the case for example when you paste a correctly
decoded filename from a gui to the command line)?

this is simply a no-win situation, and by trying to work around it you
make it only worse by introducing unpredictability into the game.

the lesser evil is imo assuming correct locale encoding when actually
interpreting external input, being consistent within the qt realm when
dealing with i/o functions, and having functions for 8-bit pass-through
when dealing with external things which are just passed along
(qprocessenvironment already has this; it should be possible to do the
same for cmdline args by having laszlo's work integrate with qprocess as
well).

.