hal++ announcement (resending due to bounce)

["Milosz Derezynski" <internalerror gmail com>]

Hey everyone,

I'd like to announce libhal++, a C++ wrapper for
libhal, and libhal-storage. It does not require glibmm nor gtkmm
(although there are tests in the dist which can make use of the glib
mainloop), yet it uses sigc++ to manage the signaling.

The API is very similar to gtkmm, glibmm and cairomm (using
our all-beloved refpointers, etc.. :) and should be intuitively to
understand for people who both know either of those (glibmm/gtkmm, etc)
and libhal/libhal-storage itself, doxy docs are available too (see at
the bottom of this message.)

KEY BENEFITS:

1) It's C++ (heh), so you don't need to
manually care about managing the C instances involved when dealing with
libhal yourself (well that one is obvious but i thought i'd still
mention it...)

2) I've created an abstraction of a Hal::Device. 

In
the C API, there is no such thing as a LibHalDevice*. Instead you have
to use a LibHalContext* instance to query informations about devices
and receive signals upon device state changes.

The most obvious/direct approach would have been to write a
"Hal::Manager" object, that would dispatch information about device
states as signals, etc.

Yet, i found it compelling to rather
create an abstraction of a Hal::Device because it's very well doable
and makes fully sense and it's much simpler to keep a Hal::Device
instance around than having to deal awkwardly with a "Hal::Manager"
(receive a signal about a device state change, then ask the
Hal::Manager for further information about the device as needed, etc).

With Hal::Device, it's (much more C++-ish) possible to
receive/connect to signals relating to the particular device, as well
as to access the device's PS (device property set)  from the Device
instance itself, instead from the LibHalContext* as in the C API (or a
hypothetical "Hal::Manager"). 

This way, one can instantiate a Device instance from e.g. a
device node like /dev/hda1, to watch for changes to it (e.g. mounted or
unmounted, etc), rather than receiving information about such a device
from a Hal::Manager, or the Hal::Context.

For all intents and purposes the API user can treat a
Hal::Device as for what it is: the representation of a device as
presented by libhal.

3) The C API has 2 base libraries: libhal,
and libhal-storage. libhal-storage is quite separate from libhal, and
is basically a convenience wrapper over devices.

I wrapped both LibHalVolume* and LibHalDevice* from
libhal-storage, but, unlike the C API, i derived them both from
Hal::Device, which isn't directly the case in the C API, yet it is
doable because the UDI (the Hal Unique Device Identifier) is
common/identical whether you use the context for device information
(see above), or directly one of the convenience C "classes"
LibHalVolume and LibHalDrive. This way, the signals related to a device
(which a libhal-storage "volume" or "drive" essentially still _IS_, yet
the API is not as coherent), are also available for a Hal::Volume and
Hal::Drive.


MORE OR LESS IMPORTANT NOTES, heh:

1) Wrappers for C instances:

libhal
(the C lib), and especially LibHalContext lack internal refcounting
entirely (unlike e.g. the cairo C API). Also, while a LibHalVolume and
LibHalDrive internally hold a LibHalContext, there is no way to access
it using the C API. Given this both, all i could do was to create a
wrapper for LibHalContext, similar to Glib::wrap(), with the option to
take ownership or not. LibHalVolume and LibHalDrive don't have wrappers
because it's not sanely resolvable how to make use of the context
specified for wrapping them wrt ref counting of the Hal::Context (there
is no libhal_volume_get_libhal

_context() method, which would be required to sanely wrap a LibHalVolume and same applies for LibHalDrive.)

Furthermore, Hal::Device clearly has no direct wrapper as there is no C counterpart to wrap. Yet, it's not a problem, as a Hal::Device can be instantiated simply by specifying a Hal::Context and the Unique Device Identifier, which is basically as good as if one would wrap a hypothetically existing C instance which would result just in the same kind of instantiation of a HAL::Device.


USE CASES:

The library can be used to monitor devices such as CD-ROM/DVD-ROM drives for newly inserted media, or to watch e.g. "volumes" (libhal lingo for everything that's mountable is a "volume") in e.g. a media player from which music has been added to inform the user about the availability of the files on it, or the availablity of the device (think portable devices/harddisks, etc.)

Various other things are possible, like monitoring the system's state, monitoring device condition changes (network connections, etc).

For a practical use case of libhal (not ported to libhal++ yet), you can refer to my own project BMP:

http://websvn.beep-media-player.org/filedetails.php?repname=bmpx&path=%2Ftrunk%2Fsrc%2Fhal.cc
http://websvn.beep-media-player.org/filedetails.php?repname=bmpx&path=%2Ftrunk%2Fsrc%2Fhal.hh

http://websvn.beep-media-player.org/filedetails.php?repname=bmpx&path=%2Ftrunk%2Fsrc%2Flibrary.cc
http://websvn.beep-media-player.org/filedetails.php?repname=bmpx&path=%2Ftrunk%2Fsrc%2Flibrary.hh

http://websvn.beep-media-player.org/filedetails.php?repname=bmpx&path=%2Ftrunk%2Fsrc%2Fui-part-cdda.hh
http://websvn.beep-media-player.org/filedetails.php?repname=bmpx&path=%2Ftrunk%2Fsrc%2Fui-part-cdda.cc

Furthermore, the libhal++ svn and tarball/dist contain quite a few examples on what the API can be used for, and the API is also partially (work in progress) doxygen-documented.

The libhal++ website (including links to the SVN repository, WebSVN links, links to the Doxy documentation) is located here:

http://projects.beep-media-player.org/index.php/Main/Hal

Cheers :)
Milosz