[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KUrl(QString) fix
From: Ralf Habacker <ralf.habacker () freenet ! de>
Date: 2006-12-20 17:30:48
Message-ID: 45897348.5000808 () freenet ! de
[Download RAW message or body]
David Faure schrieb:
> 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".
> mSo getting /C:/bar as path seems normal to me, we just need to be able to handle \
> that....
I understand and this means there is no bug in the Qt code
> Or do you mean that e.g. QFile("/C:/bar") fails?
yes.
> 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...
>
Thanks for this pointer.
Now it is clear to me where the real problem is. On unix KUrl::path()
(or QUrl::path()) returns the same path as toLocalFile(). Because of
that there are many places in the kde code where the returned path from
KUrl::path() is used as local file path, which it as you said per
definition *not* a local file path, it is instead the path of the url.
On windows path() and isLocalFile() returns different values. See case 4
and 6 below
case url: path()
toLocalFile()
1: file:/netaccesstest /netaccesstest
/netaccesstest
2: file://netaccesstest
//netaccesstest
3: file:///netaccesstest /netaccesstest
/netaccesstest
4: file:/C:/netaccesstest /C:/netaccesstest
C:/netaccesstest
5: file://C:/netaccesstest /netaccesstest
//c/netaccesstest
6: file:///C:/netaccesstest /C:/netaccesstest
C:/netaccesstest
As result it looks to me that in kde code toLocalFile() should be used
in every place where the local path of an url is used, not path()
Ralf
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic