Thiago Macieira wrote: >> On the other hand we already have Qt-only paths in resource files and >> QDir::searchPaths(). We could easily use a well-known prefix for the >> special paths: url-encoded:/usr/joao/R%E9sum%E9.txt, which only supports >> absolute paths, but would already enable all items in my wish list. >>> As you can see, I didn't come up with this today. I've known these >>> alternatives for years. I don't think they're worth our time. > > Search paths and the filesystem engines are misfeatures. One is gone, the > other > not yet. They are potential security issues too.
They're potentially security issues, but they're not gone in any way. True, you can no longer use public API to introduce custom file engines. I don't expect resource files to disappear any time soon, though, and those go with a ":/" prefix. > 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. 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. > 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. Names obtained from the file system need to be decoded and all QStrings need to be encoded before being passed to filesystem functions. This can be done transparently. There's no point in forcing the user to consider this any further. > Later, we can decide whether to add escaping to those functions. Yes, let's not rush into escaping. 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. > However, I cannot agree with bringing the setter functions back. I do agree > with removing them completely, though. Go for it, already! João _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
