Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)

[David Faure]

On Saturday 29 October 2011 14:43:20 Milian Wolff wrote:
> On Saturday 29 October 2011 09:25:03 Thiago Macieira wrote:
> > On Saturday, 29 de October de 2011 04:38:00 Milian Wolff wrote:
> > > 1) When does it manifest? Apparently when using QUrl("...")
> > > directly, if I'm not mistaken. But what if we use KUrl?
> > 
> > You're correct: this problem manifests when you use QUrl's constructor
> > directly, assuming it will understand a local file path for what it is
> > and not parse it is a URL. KUrl's constructor calls fromPathOrUrl, so
> > it will try to guess according to some heuristics.
> > 
> > The reason why this behaviour exists in QUrl and why I think KUrl is
> > flawed is that there's a category of URLs that are incomplete, the
> > relative URLs, also known as URL refs. That's what you see in the
> > "href" or "src" attributes in HTML: those are real URL components, but
> > they are partial. They need to be resolved against a base URL, usually
> > the document's.
> > 
> > There's no way to tell apart a local file path from a URL ref and the
> > examples I gave show how it would be interpreted differently.
> 
> Right, but you should agree that relative remote adresses can only occur in
> a browser context. At least in KDevelop + Kate I don't see any way for a
> user to provide a relative url, so I hope that the existing codebase will
> work just fine with Qt 4.8. Anyone tried it already maybe?

Exactly, most of the KDE code does not use relative paths/urls, which is why 
not much code is affected by this change, and also why KUrl(QString) is maybe 
a bit inconsistent / not well thought out when it comes to relative paths.
I admit I didn't think much of that use case, I was merely trying to provide 
"full path or URL" detection, which I believe is the most needed use case, and 
does NOT have the bugs Thiago mentionned ("/tmp/Who let the dogs out?.mp3"
and "/tmp/Mambo #5.mp3" work just fine). KUrl uses QUrl, but the API is 
different, and this doesn't trigger these issues.

The handling of relative URLs would need more thought and unit-testing (so 
that such breakages don't go unnoticed), but personally I don't like using 
KUrl(QString) for these, and apparently Thiago neither.

As to what to do now, to restore behavior compatibility, I'm not sure. I don't 
even see how the knotify use case worked, because indeed KUrl was parsing as a 
url something that was in fact a relative path. KUrl isn't meant to store a 
relative location, and KUrlRequester always returns an absolute url when using 
the file dialog, one would have to type something blindly to get a relative 
filename in there, no? Anyway KUrlRequester should be fixed if it returns 
relative paths, I don't think it should let apps resolve that to a full path 
when it can do so itself.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).