KIO::UDSEntry::UDS_URL and KFileItem::url()
nf2 at scheinwelt.at
Thu Feb 21 01:08:28 GMT 2008
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...
More information about the kde-core-devel