Proposal for a new KIO API: KMount/KMountModel
Aaron J. Seigo
aseigo at kde.org
Fri Feb 29 22:07:36 GMT 2008
On Friday 29 February 2008, nf2 wrote:
> 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
i understand the problem, but i'm not sure abstracting-the-abstraction-layer
is the best answer here as it means yet another layer of software.
it would be great if one of the following were to happen:
* the layers under Solid spoke this stuff (e.g. modify the HAL layer to report
on such "virtual" mounts)
* barring that, the Solid backends for platforms that support things such as
FUSE were made aware of them.
the downside of the second approach is that it does start to pervert Solid
from being a purely literal hardware system in this one case, but it is where
i would expect to find this stuff and will give us exactly one place to point
people to, instead of saying "well, if you want user space software mounts
too, then you need to use this other API as well as Solid, otherwise you can
just use Solid ..." that sounds really messy.
now, if these user space mount systems are just too ugly to access from Solid,
maybe that's a source of the problem as well.
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel