[Development] Deprecating QFile::encodeName/decodeName

[Thiago Macieira]

On sexta-feira, 8 de junho de 2012 10.44.37, João Abecasis 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
> 
> As I said before, while I think these functions supported a real problem,
> they or their implementation are the wrong solution. I'm happy to make them
> internal and remove them from the API completely.

I don't want to remove them. The reason I did not even mark them 
Q_DECL_DEPRECATED was that they're used everywhere. Removing them would be a 
mistake.

But they can be de-inlined.

> What I was asking for, and I thought I was clear on that, is that we
> recognize where we regressed in functionality (we did!) and plan to cover
> the gap in the future. There's no need to rush.

I do not agree on that. I don't think we regressed in functionality for two 
reasons:

1) I don't agree with your assessment of the problem

2) even if I did, the change was mostly a no-op. There's no where in the Qt 
sources we used the setter functions, so the change just hardcoded what we 
were already doing.

Unless you mean the inability to change behaviour again in the future. In that 
case, yes, it would be a limitation. That's why I am proposing to de-inline 
now.

> > 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
> 
> As pointed out by Oswald, this is the wrong solution. The interface where
> this needs to be handled is as close as possible to the OS-specific
> filesystem layer. Currently, the best place for this is QFileSystemEntry
> that keeps a real native path, besides a QString interpretation.

I disagree with the first sentence and I agree with the second and third. Yes, 
the OS-specific file system layer needs to handle this. I just think it's not 
the only place.

I think we need to handle this *everywhere* where a file name is converted from 
UTF-16 to 8-bit.

Actually, no, I don't think this should be handled at all. But if we must do 
it anyway, that's where I'd do it.

> Names obtained from the file system need to be decoded and all QStrings need
> to be encoded before being passed to filesystem functions.

Agreed.

> This can be done transparently. There's no point in forcing the user to
> consider this any further.

Agreed. Since the user shouldn't need to consider this, we need to decode and 
encode anywhere where the user is supplying us 8-bit filenames or expecting 
that from us.

> I actually think a satisfactory solution would be to add limited support for
> "file://" local path URLs, where percent encoding would be fully supported
> as per URL rules. This would only support absolute paths, but would already
> enable everything in my wish list. For paths generated inside Qt, URL-style
> paths would only be used where the path couldn't otherwise be decoded to
> QString.

Hmm... that's actually not a bad idea.

By doing this, we'd be making it impossible to have a filename whose name 
starts with "file:///". That's a problem we need to document if we do it (note 
that such a file cannot exist on windows in the first place). However, such files 
already *do* pose problems, since many applications will try to decode a URL 
if they find one, falling back to a path otherwise. See the discussion on 
QUrl's constructor and the example of KUrl's and KUrl::fromPathOrUrl.

> > However, I cannot agree with bringing the setter functions back. I do
> > agree
> > with removing them completely, though.
> 
> Go for it, already!

You're the one who wants this. I'm perfectly happy leaving them as it is :-)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120608/ced8b109/attachment.sig>