[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Qt 4.8 QUrl.toLocalFile behavior change,
From:       Milian Wolff <mail () milianw ! de>
Date:       2011-10-29 12:43:20
Message-ID: 15349840.sFJVSApvPf () minime
[Download RAW message or body]

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?

> > 2) Is the -D... define to catch this problem at compile time already
> > supported  in Qt 4.7?
> 
> Yes.
> 
> Note it just makes the constructor explicit: it's meant to catch accidental
> conversions. If you spell out QUrl, it will still get used.

Thanks
-- 
Milian Wolff
mail@milianw.de
http://milianw.de
[prev in list] [next in list] [prev in thread] [next in thread]