DCOP D-BUS HAL and new cd's
hausmann at kde.org
Sun Sep 19 15:17:39 BST 2004
On Sunday 19 September 2004 15:28, Kévin Ottens wrote:
> Le Samedi 18 Septembre 2004 19:39, Simon Hausmann a écrit :
> > Which part of hal gave you that impression?
> The simplified answer is using sloccount.
> hald : 14565 lines of C
> hald/linux : 10151 lines of C
> So, we have several solutions here:
> 1) HAL architecture doesn't help you to develop the os specific layer...
> then it's a lot of work to port it to something else
> 2) Linux is not helpful and then requires a lot of code to handle it
> correctly... then maybe for other OSes it'll be easier
3) Lines of code is a terrible metric on the quality, complexity and
portability of software :)
Seriously, to me that is comparing apples with oranges. The linux portion is
about extracting information from the kernel (into the udi hierarchy and
name/value property sets) and the rest is about dynamically publishing that
information over the system wide dbus. Two different solutions for different
I find the interface between those two much more interesting.
http://freedesktop.org/pipermail/hal/2004-June/000421.html describes a bit of
> Of course both of this statements are not sure... That's why in my humble
> opinion we'll be able to have a clear opinion on HAL when it'll be ported
> to something else than Linux.
You might find this thread interesting:
As GNOME is using it in their volume manager in the latest release 2.8 I'm
optimistic that it'll end up on more platforms soon.
On the client side you don't even necessarily need to use libhal. Instead just
using dbus should work as well, as libhal is just a convenience wrapper. And
as Harald has shown dbus can nicely be combined with a Qtesque API, without
pulling any dependencies beyond libdbus.
More information about the kde-core-devel