Thiago Macieira wrote: > On sexta-feira, 8 de junho de 2012 10.44.37, João Abecasis wrote: >> 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.
We're getting somewhere! :-) > 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. A file whose name starts with "file:///" could still be fully understood by prefixing it with "./". This is not very different from what a user needs to do to ensure a file name is not confused with a command line option (when passing it in the command line, that is). Security issues can me minimized by requiring absolute paths where this is a concern. >>> 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 :-) I thought this was feedback you already got in the review of your patch :-p Cheers, João _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
