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

[nf2]

I wonder if KIO::UDSEntry::UDS_URL should be deprecated for something 
new like KIO::UDSEntry::UDS_TARGET_URL. That's because originally, i 
think ,it hasen't been meant to be the URL of the currently listed item 
in a certain directory, but more like the target URL of a shortcut 
pointing somewhere else.

In KDirLister the KFileItem::url() has a different meaning: It always 
represents the currently listed directory, plus the filename *in* this 
directory. Therefore, whenever you put something different into an 
UDS_URL, the system will crash.

One could either add an addidional KUrl argument to the following 
signals in KDirLister (and some other methods)...

void newItems( const KFileItemList& items );
void itemsFilteredByMime( const KFileItemList& items );
void deleteItem( const KFileItem &_fileItem );

...or decide, that KFileItemLists can contain items from different 
directories, and the ::url() in every KFileItem describes, to which one 
it belongs. I don't know which solution would be right. Either 
KFileItem::url() has a meaning, or it's redundant.

I would propose the following extensions to the UDS system:

deprecate UDS_URL, and add the following new UDS field types:

UDS_TARGET_URL  :  the target URL of a shortcut or listed mount/drive
UDS_DISPLAYNAME : the text to display in the file-manager instead of the 
real filename (UDS_NAME).
UDS_LINK_TYPE (mount, dir or file)

That way it would be easier to map drives, mounts and desktop shortcuts 
into the file-system (to list them in remote:// for instance). Also, 
redirection() wouldn't be needed in that particular case anymore (which 
is always complicated, because you have to find out if the URL to list 
is a link, pointing somewhere else). The filemanger/dialog would open 
the UDS_TARGET_URL instantly when you click on it.

I'm still new to those things, so forgive me if my thoughts are garbage...

Regards,
Norbert