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

List:       kde-core-devel
Subject:    Re: KIO::UDSEntry::UDS_URL and KFileItem::url()
From:       David Faure <faure () kde ! org>
Date:       2008-02-21 9:48:54
Message-ID: 200802211048.55356.faure () kde ! org
[Download RAW message or body]

On Thursday 21 February 2008, nf2 wrote:
> Therefore, whenever you put something different into an  
> UDS_URL, the system will crash.

+= if the url is unrelated to the url of the parent directory, yes
(KDirModel has no way of associating child with parent url then).

It's not true to say that using UDS_URL always crashes KDirModel - kio_trash
uses UDS_URL just fine for instance. But that's because it simply gives items
a different "internal filename" than the user-visible filename. It's a different use \
case than yours, since the url of the directory can still be deducted from the URL \
inside UDS_URL so KDirModel handles it fine.
But.... you're right; if this is the only use of UDS_URL that KDirModel can handle \
then we should rather provide a way of simply changing the display name. \
UDS_DISPLAY_NAME sounds like a good idea indeed; it would set m_strText in KFileItem.

So from your mail I disagree with "UDS_URL should be deprecated for UDS_TARGET_URL": \
it depends on the use case. In the kio_trash use case it would be replaced by \
UDS_DISPLAY_NAME.

I haven't looked into the other use cases for it, but there are plenty in kdebase \
itself (kio_man, kio_settings, kio_remote, kio_nfs, and kio_smb)...

> One could either add an addidional KUrl argument to the following 
> signals in KDirLister (and some other methods)...
> void newItems( const KFileItemList& items );

Yes, that was my idea. Ideally a KFileItem parent, even, to describe the
tree structure correctly, but we might not always have a KFileItem parent,
that's the problem. However I'd be happy if indeed we don't need to go that way (see \
below).

> or decide, that KFileItemLists can contain items from different 
> directories, and the ::url() in every KFileItem describes, to which one 
> it belongs.

This doesn't sound like a tree model at all, so it's a no-go IMHO.
Remember that we need to be able to represent the "output" of kdirlister as a tree \
structure, this is what KDirModel represents and it's what applications expect from \
it.

> The filemanger/dialog would open the UDS_TARGET_URL instantly when you click on it.

This sounds fine -- if we're talking about opening a new url instead of the current \
one ("going somewhere", not "opening a branch in a tree"). Otherwise the tree-model \
problem hits us again there. But if we treat such items as leaves in the tree, then \
it's easy indeed. Another reason for doing that is that if you "go" to that target \
url, pressing "up" won't bring you back where you came from, so this is indeed a kind \
of shortcut to somewhere else, not a real child folder.

What's the use for UDS_LINK_TYPE (mount, dir or file)? "mount" sounds very specific \
to your use case; and we know if something is a dir or a file already with \
UDS_FILE_TYPE.

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


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