Proposal for a new KIO API: KMount/KMountModel

nf2 nf2 at scheinwelt.at
Fri Feb 29 18:43:20 GMT 2008


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()).


Here is an API sketch:

class KMount
{
    QString uid();
    QString type();  // for filtering: "removable-media", "local", 
"fuse", "remote-vfs"...
    KUrl root();    // mount-point
    Solid::Device solidDevice();  

    bool isMounted();
    bool canUnmount();
    bool canEject();

    KMountResult mount();
    KMountResult unMount();
    KMountResult eject();

    QString icon();

}

class KMountModel
{
    List<KMount> listMounts();
    KMount getMount(QString uid);

signals:
    void mountAdded(KMount);
    void mountRemoved(KMount);
    void mountChanged(KMount);
    void mounted(KMount);
    void unMounted(KMount);

}


API Extensions:

enum StandardFieldTypes
{
    UDS_IS_MOUNT
    UDS_MOUNT_UID
}

class KFileItem
{
    ...
    bool isMount();
    KMount getMount();
    ...
}


I'm not happy with the term "Mount" yet. As this can also represent 
volumes which are not mounted, perhaps "Mountable" would be more 
appropriate...

Norbert







More information about the kde-core-devel mailing list