KIO design decision necessary: unique names in KIO listings

[Sebastian Trueg]

On 01/14/2011 11:28 PM, David Faure wrote:
> On Friday 14 January 2011, Sebastian Trueg wrote:
>> Hi guys,
>>
>> the problem is fairly simple: KIO relies on entry names to be unique.
>> That makes sense since there needs to be some way to identify the items
>> in a dir listing. This also worked nicely in pre-Nepomuk days.
>>
>> However, with the introduction of desktop search the filename is no
>> unique identifier anymore. Two query results can have the same name.
>>
>> My solution for nepomuksearch was two fold:
>> 1. Use an encoded file URL as UDS_NAME
>> 2. Use the actual filename as UDS_DISPLAY_NAME
>>
>> This works to an extend. As you can see in bug 263169[1] the properties
>> dialog (there may be other places) uses UDS_NAME to display item names.
>> The reason is that items can be renamed and in KIO terms renaming an
>> item means changing its UDS_NAME.
>>
>> The question now is:
>> Should KIO rename change its meaning to: change UDS_DISPLAY_NAME?
> 
> In the properties dialog? From a user point of view, that would make sense, 
> since the display name is what the user saw in the directory listing in the 
> first place.
> 
> But the problem is, rename (KIO::move()) takes urls, not display names.
> And for this reason KPropertiesDialog::rename uses the user-entered name as 
> "let's append that to the directory url". Won't be any good with a display 
> name.

exactly.

> So we have no way currently to rename based on the UDS_DISPLAY_NAME, sounds 
> like something that would have to be added; a new kind of job, say 
> KIO::renameFile(const KUrl& currentFileUrl, const QString& newName).
> Should be used by the propertiesdialog and by inline-renaming.

that sounds like a very good solution. Esentially this would mean
separating "rename" and "move".

> This sounds like a job for me actually; not that I'm missing jobs :)

:P

> And adding "virtual" methods in SlaveBase sounds like a lot of fun... 
> virtual_hook would be very ugly... maybe I should use a new interface and 
> dynamic_cast...

That could work, using a fallback to the "old" API. After all
nepomuksearch is the only KIO slave in need of that method at the moment.

>> Should we define a new way to uniquely identify items in a dir listing?
> 
> That's what UDS_NAME is really. Especially since it's used to make up full 
> URLs everywhere. I'm definitely not in favour of changing that, it would be 
> incompatible and a huge amount of work, and in fact pointless since I don't 
> see how that would solve the KIO::move issue.

agreed. I also think this is a bad approach. I basically only wanted to
list more than one option. :D

>> IMHO not allowing the renaming of files in a search result listing is
>> not an option since.
> 
> ... since you can't finish sentences? :-P

...since I am too lazy to finish my argument.
Seriously I would very much like to handle search results like any other
folder from the user's point of view. Imagine the user cannot rename a
file simply because they have filtered out all the images.... not very
user friendly.

Cheers,
Sebastian