SlaveBase::rename issues

[Jeff Mitchell]

Jeff Mitchell wrote:
> (CCing kde-core-devel as it may be of interest to those out there...)
>
> I'm hitting behavior that I find very undesired in SlaveBase::rename 
> while working on a portable media player (pmp:///) kioslave.
>
> Portable devices are identified by (a transformed version of) their 
> Solid udi.  These are quite ugly and non-readable, as they are based 
> off of (on Linux at least) hal names.  So at a top level, when someone 
> wants to see available devices (i.e. enters pmp:/ in Dolphin/Konqui), 
> I display a friendly name -- one provided by the library if possible, 
> otherwise gleaned from Solid calls, with the Solid udi as a las resort.
>
> To do this the entries listDir returns in pmp:/// have KIO::NAME and 
> KIO::URL properties.  So the NAME property is what's shown, and 
> double-clicking on it takes it to the device-specific URL as expected.
>
> The problem pops up when I attempt to allow a rename on these devices, 
> so that users can set friendly names that will be stored on the device 
> (many libraries support this function).  The pseudocode goes like this:
>
> PMPProtocol::rename( src, dest, overwrite)
>  //if certain conditions are met such that I know that
>  //they are trying to do a top-level rename...
>  deviceFor(src)->setFriendlyName( nameFrom( dst ))
>  emit finished()
>  return
>
> Not emitting finished causes things to go awry, and emitting finished 
> causes the displayed name to be modified.
>
> Unfortunately, this doesn't just modify the NAME field but the URL 
> field as well.  So when the user then tries to access the device, the 
> URL is invalid.
>
> I would contend that if a UDSEntry has both a defined NAME field and a 
> defined URL field that, since the user will be attempting to modify 
> the displayed name, only the NAME field should be modified.  Modifying 
> the URL is totally meaningless in this case.
>
> I can see a few ways to work around this:
> 1) Fix things so that in the case that a display name is set, a 
> modification to that name only affects the display name.
> 2) Have some way to force a re-listDir() on that directory at the end 
> of the rename function (is there a way to do this already that I don't 
> know about?)
> 3) Have some way to choose which fields in a UDSEntry are updated by a 
> rename (is there a way to do this already that I don't know about?)
>
> Thanks,
> Jeff
After thinking about this some more it seems like having a way to  
indicate that the current directory listing is dirty and should be 
re-listed would be beneficial for other situations as well, such as if 
an action on the part of the slave or the user should cause new entries 
to be shown in a directory but the slave isn't currently listing.  So 
from my point of view both 1) and 2) above would be really great.  Is 
there already a way to do either, and if not, is it really too late to 
try to get this into 4.0?

Thanks,
Jeff