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