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

Kevin Kofler kevin.kofler at chello.at
Sun Oct 30 17:45:32 GMT 2011

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.

No, it doesn't.

There's actually a difference between KUrl(str):
and KUrl::fromPathToUrl(str):
and it affects relative paths. KUrl(str) will treat a relative path as a 
URL, KUrl::fromPathToUrl(str) will treat it as a path! Both treat absolute 
paths as paths and URLs with scheme as URLs.

So it looks like all code passing relative paths to KUrl should be using 
fromPathToUrl instead. The problem is that fromPathToUrl is marked 
deprecated! The rationale is:
   * \deprecated
   * Since KDE4 you can pass both urls and paths to the KUrl constructors.
   * Use KUrl(text) instead.
but as I explained above, those are not at all the same thing! And I don't 
think the KUrl constructor should be changed, since there are contexts such 
as web browsers where you want relative paths to be URLs. So fromPathToUrl 
needs to be undeprecated (the code costs almost nothing in terms of space) 
and all functions constructing a KUrl from something which may be a local 
relative path should be changed to use fromPathOrUrl.

An alternative solution would be to change the KUrl constructor to work like 
fromPathToUrl and to introduce a static fromUrl function (to pair with 
fromPath), which would be used in e.g. web browsers. But IMHO this is 
source-incompatible and not suitable for 4.x. It might be the right thing to 
do for KF5 though.

        Kevin Kofler

More information about the kde-core-devel mailing list