Sorry, for one, a typo correction. I meant _system_ bus here of course: "[...] so there is no need to connect to the session bus by yourself; [...]" And yeah, that _is_ the case, but that's what libhal does for you: it connects to HAL's interface on the system bus, so you don't have to deal with this. <div>On 3/20/06, Oliver Frommel <<a href="mailto:ofrommel@linuxnewmedia.de">ofrommel@linuxnewmedia.de</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > > Not the text editor maybe, but: > > - most sound software (USB audio and midi devices) > > - software for digital cameras > > - video editing software (IEEE1394) > > > > In these cases I would connect the application to the system bus > > and register them for events of the appropriate devices of the > > Hal service. Additionally I would have to connect to the > > session bus to make the applications scriptable or exchange > > data with cooperating applications. > > > Yes but there exists libhal which is a library that abstracts out > communication with hal trough DBus for the API user, so there is no need to > connect to the session bus by yourself; instead you can make use of libhal, > and don't need to deal with DBus directly at all there. There is also > libhal-storage, which is a separate library with an even simpler interface > since storage handling is a very common use case when using HAL. That's interesting. From what I read I figured it was the other way round: that you make use of D-Bus to access HAL. Best Oliver </blockquote></div>