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

List:       kde-windows
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
> 
_______________________________________________
Kde-windows mailing list
Kde-windows@kde.org
https://mail.kde.org/mailman/listinfo/kde-windows


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