DCOP D-BUS HAL and new cd's
lodewyck at clipper.ens.fr
Fri Sep 17 09:00:27 BST 2004
So, Let's start with hardware discussions...
I propose the following framework as a starting point for our discussions. It
is inspired from discussion I had with Kévin, from the work I have done on
kvm, and from the current devices implementation. Kévin has already started
an implementation of a new devices kded on his own, so he will surely be able
to correct this view.
The main idea is that we need a replacement for the current devices
kioslave/kded that can handle more types of media (not only mountable media),
with the possibility to connect to external tools (think of the HAL) if
So we need :
- A kded daemon (a mountwatcher replacement). Following our "mission
statement" edicted by Kévin, this daemon shall not depend on external tools,
or on any OS (it should work from Linux to Win32/qt). So do not expect a
/etc/fstab file, or do not rely on HAL calls.
This daemon is responsible for listing devices, and provides a DCOP interface
to emit device properties upon demand. It should also provide an interface
(not sure of what type : API or DCOP -- I favour API) so that "external
modules" (see below) can tell it which devices are available, and can notify
it upon device insertion/removal...
Optionnaly, this daemon could implement autoplaying policy (think of
automounting, CD/DVD playing...), triggered if an external module can provide
insertion notification (code for this already exists in kvm).
- A "(K)Device" class that stores properties about a device. For example, it
should countain a QString identifier (given by external modules), if it is
mountable, information about mountpoint, an URL, a mimetype... This class
should be accessible from external modules.
- A kioslave (much like devices:/) that create kfile entries corresponding to
the daemon device list. Before requesting devices mounting, it should ensure
the device is mountable. If not, it should rely on the URL provided by the
- External modules : these modules should implement OS/tools specific device
detection. For example :
* A "fstab/mtab" module, that gathers fstab watching as currently done by the
* A HAL modules
* A win32 module ?
Modules should ne able to override each other. e.g, if HAL is running, the HAL
module should override the fstab modules since the user/ditributer decided to
- Additional mimetypes, e.g. video_dvd, audio_cd, mixed_cd, gphoto2_camera...
and additional "Desktop Actions", e.g. play for video_dvd and audio_cd...
More information about the kde-core-devel