KUrl(QString) fix

[David Faure]

On Wednesday 20 December 2006 17:38, Ralf Habacker wrote:
> David Faure schrieb:
> > On Wednesday 20 December 2006 17:02, Leonardo Stern wrote:
> >   
> >> Greetings,
> >>
> >> KUrl kurl("file:///foo/bar")
> >> path() == "/foo/bar"  (not "foo/bar).
> >>     
> > The breakage was on windows only, right?
> > Someone should really run kurltest (from kdecore/tests) on windows (it passes fine on unix).
> >   
> I had run kurltest and saw that one of the problems is laying deeper in 
> QUrl. The appended test case show it
> 
> F:\daten\test\qurltest>debug\test
> case 1: file:/netaccesstest_README -> /netaccesstest_README
> case 2: file://netaccesstest_README ->
> case 3: file:///netaccesstest_README -> /netaccesstest_README
> case 4: file:/C:/netaccesstest_README -> /C:/netaccesstest_README
> case 5: file://C:/netaccesstest_README -> /netaccesstest_README
> case 6: file:///C:/netaccesstest_README -> /C:/netaccesstest_README
> 
> 1 and 3. looks as excepted and 2. is ignored because of badly formed url. 
Yes (well it would be a hostname, in case 2)

> In case 4. and 6. there the path is prefixed by a non expected '/' 
Is it really? file:///foo means the path is /foo, that's how urls work, per the RFCs.
It doesn't matter that foo is "C:/bar".
So getting /C:/bar as path seems normal to me, we just need to be able to handle that....
Or do you mean that e.g. QFile("/C:/bar") fails? Since '/' as first char on Windows can't
possibly mean anything, Qt could just remove it imho... I guess that's the part that's missing.

At the QUrl level it's all fine imho, unless TT can be convinced to standardize on file:///C:/ kind of stuff
and adjust path() accordingly to match how local paths work on windows - all very un-rfc-like...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).