Proposal for a new KIO API: KMount/KMountModel

[Kelly Miller]

nf2 wrote:
> The purpose of this would be a central API for managing mounts and 
> volumes in KIO.
>
> At the moment for instance KFilePlacesModel relies directly on the 
> hardware layer (Solid). That makes it hard to deal with things like 
> FUSE or VFS mounts.
>
> Also, it's difficult to display mounts/volumes in arbitrary locations 
> in the file-management hierarchy: You can set up ServiceMenues and 
> custom mimetypes to add the unmount action to such items (that's what 
> i'm currently doing in my remote:// implementation), but you still get 
> "delete" or "copy" entries in the context menu which don't make much 
> sense for mounts/volumes. This makes me believe that mounts are 
> special KFileItems, which have to be recognized appropriately (i.e 
> with KFileItem::isMount()).
Is it just me, or does it seem like this particular section of desktop 
handling is starting to converge again?  I mean, your suggestion, if I 
understand it correctly, mirrors part of the plan for the new Gnome/GTK+ 
filesystem, gvfs.  I don't want to sound like I'm criticizing anybody, 
or telling people what to do, or stuff like that, but I can't figure out 
a good reason why they would start reinventing the wheel, and then you 
guys'd start reinventing the wheel, and then... what?

This sits on one of the oldest complaints from the UNIX-style desktop; 
that each desktop has its own way of handling mounting, and if a program 
doesn't know one or the other, it's basically screwed unless the kernel 
in question has something to handle it as well, which can be used...