HAL, and laptop Fn and hardware keys

[Danny Kukawka]

On Wednesday 21 September 2005 16:44, David Zeuthen wrote:
> On Wed, 2005-09-21 at 12:47 +0200, Danny Kukawka wrote:
> > > Well, it would probably be accepted better in other distros, and in the
> > > existing infrastructure. For me, adding another ButtonPressed event in
> > > GNOME Power Manager is a two second job (as it already uses libhal), as
> > > it would be in any userspace application.
> >
> > I don't know how easy it is to add a event to GNOME Power Manager but if
> > you already use D-BUS (and I think you do) it should be very easy to
> > catch the D-BUS event from IAL for keys.
>
> Why on earth would I want Yet Another Daemon.. from Yet Another
> Project... running for something as trivial as keys, when we got HAL and
> it fits perfectly in with the model we use for other devices? Care to
> explain why it's a bad idea to port this to HAL?

This would be a argument to implement also this in HAL: network daemons, 
cupsd, syslog, automount and .... ;)

One reason: possible races with other programmes. And what is the problem with 
other projects? Doesn't you use other projects than HAL? ;)

> I feel that doing this in a separate project leads to the "explosion of
> complexity", "too many small userspace bits", "too many different
> upstream project", "too many API's to track" kind of problems. 

I see the same problem if everything thats somehow possible is integrated in 
HAL. 

[...]

>         KISS Principle /kis' prin'si-pl/ /n./
>
>         "Keep It Simple, Stupid". A maxim often invoked when discussing
>         design to fend off creeping featurism and control development
>         complexity. Possibly related to the marketroid maxim on sales
>         presentations, "Keep It Short and Simple".

This is not what I sad or mean, btw: yes I see a problem with "creeping 
featurism".

> What you are proposing, two separate projects, is simply not KISS.

I don't think so. I proposed to have special tools for special requirements. 
Why add key handling to HAL? Why not handle all key related things in a 
specialised daemon which do nothing other than handle only keys? You can add 
there all you need and it's much more easier to develop a new module for IAL 
than for HAL. Whould you have for each new keyboard a new addon for HAL?

IMO this does not fit into the concept of HAL. I think key events are not a 
task for hardware abstaction.

Btw. if this comes in HAL (I think it should not) there should be a configure 
option to compile out the key-event-handling. 

CU,

Danny