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
_______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
