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

List:       kde-devel
Subject:    Re: name() method of KFileItem
From:       Michael Brade <Michael.Brade () informatik ! uni-muenchen ! de>
Date:       2001-09-12 20:50:32
[Download RAW message or body]

On Wednesday 12 September 2001 22:41, Julian Rockey wrote:
> > > The UDSAtoms generated by
> > > ListJob (in the file io slave) contain the path relative the the
> > > ListJob start directory as the UDS_NAME.
> >
> > How is your result possible then? KIO::ListJob does no recursive listing
> > AFAIK. It only lists all the items in the start directory, no more and no
> > less. So all the items should be filenames without path automagically.
> > Hmm, I don't understand....
>
> Actually KIO::ListJob has a recursive option which I'm using.
>
> [from documentation]
> ListJob (const KURL& url, bool showProgressInfo, bool recursive = false,
> QString prefix = QString::null)
>
> And there's a static method that creates one in KIO:
> ListJob * listRecursive ( const KURL& url, bool showProgressInfo = true )
BIG whoops... I should have taken a look at the code before replying :-}

> So I think this is the key to the problem. ListJob only returns UDSEntry
> object which contain only the leaf name (or in this case, relative path
> from the URL being listed). So if it didn't return relative paths in the
> UDSEntry objects the slot would have no way of knowing in which directory
> the files were present for a recursive listing.
Yes, I guess that's the reason for returning the relative path.

> > Yes, I think it's definitely correct. If UDS_NAME contains a path then
> > it's a bug that should not be worked around in KFileItem.
Well, I'm not sure about my statement anymore for obvious reasons, in fact I 
think it's wrong.

> I've worked around in the in application, but we (=KDE project &
> developers) need to decide whether UDS_NAME is allowed to contain a path or
> not. If not then do we need a UDS_PATH atom? Or should ListJob's entries
> signal return a KFileItemList?
I don't know for sure but the way as it is handled right now seems to be ok 
to me. Why is it a problem if UDS_NAME contains a relative path?

> If it is determined that UDS_NAME is allowed to contain a path name, then
> KFileItem (and perhaps other classes) need to be changed to accomodate
> this.

> Any opinions?
>
> Should this go to kde-core-devel? Worth raising a bug? (sorry I'm still
> fairly new to KDE and not totally familiar with appropriate procedures..)
Yes, I've forwarded this to core-devel since some KIO developers are not 
reading kde-devel, even if it's just to get an "it's ok, there's no bug" ;-)

Ciao,
  Michael

-- 

       Some operating systems are called `user friendly',
             Linux however is `expert friendly'.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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