KIO::UDSEntry::UDS_URL and KFileItem::url()

[David Faure]

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 at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).