Linked by Thom Holwerda on Wed 19th Jan 2011 22:04 UTC
Xfce When we reported on the release of Xfce 4.8, we ignored a statement inside the release announcement about the lack of new features coming to the BSD world. The statement was a bit disconnected from the rest of the press release, but Xfce developer Jannis Pohlmann has published a blog post giving a few more details about the issue.
Thread beginning with comment 459206
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: dbus
by TheKhan on Thu 20th Jan 2011 14:17 UTC in reply to "dbus"
TheKhan
Member since:
2011-01-20

Not really, thunar-volman uses the udev library for device management and notification etc.. So someone in BSD camp will need to implement the same backend for *BSD, probably using devfs. That is what happened with HAL as well.

A common abstraction layer, such as HAL helps a lot in terms of interoperability, because most applications end up using it in terms of device related operations. So it is a single coding effort to implement a BSD backend in HAL, which was done. Now with udev and libudev, coding will be needed for every other component that uses it directly.

The KDE folks are doing it in the best way imho, implementing their own hardware abstraction. Then every other KDE app uses that, and you only needed to implement a BSD or any other backend for the abstraction layer.

Reply Parent Score: 2

RE[2]: dbus
by Soulbender on Thu 20th Jan 2011 19:37 in reply to "RE: dbus"
Soulbender Member since:
2005-08-18

That is what happened with HAL as well.


But the HAL api was only accessed by desktop apps thru dbus. All you needed to do to "port|" HAL to a new platform was to somehow implement the same dbus interfaces (by no means a simple task though. I know, I tried). Why wouldnt udev be done the same way?

Reply Parent Score: 2

RE[3]: dbus
by Carewolf on Thu 20th Jan 2011 22:08 in reply to "RE[2]: dbus"
Carewolf Member since:
2005-09-08

Well, the real problem is that udev doesn't actually do any of the things that HAL was primarly used for. For that you need a rather wide range of other new special-purpose services like upower, udisks, unameit, etc.

A KDE developer working on porting solid from HAL to udev complained about this, and how there was a still a few things done by HAL which didn't even have new interfaces. In the new "udev" backend, they had to implement direct parsing of linux /proc files to support features that previously came through HAL. Stuff like that makes "udev" implementation much less portable.

If I may rant it bit, it seems GNOME developers in their eternal wisdom and continued strugle to make everything clean and pretty, forgot to implement anything useful from HAL into udev before they decided to deprecate HAL.

Reply Parent Score: 7