Currently this is handled by
powerlaunch; it is really not a bad bit of code and does most of its job well.
Sadly it really sucks at being configurable!
Here's a snippet:
global_key_press_power = timer_set _key_power_long $powerkey_longdelay; timer_set _key_power_medium $powerkey_mediumdelay; set powerkey_short 1; call _key_press_power_short
global_key_release_power = timer_cancel _key_power_long; timer_cancel _key_power_medium; if $powerkey_short _key_release_power_short key_release_power_long
I don't know what it does and the only way I'd be happy changing it would be after extensive research. Frankly it scares me!
Here's what I was thinking we'd do for a 'configuration' syntax in Mer:
# describe some action
notify "The wifi is up"
os.system("mail email@example.com -S 'wifi is up'")
connect(wifi, "Connection.up", on_wifi_up)
connect(camera, "Camera.active", takePhotoAfter10Secs)
connect(camera, "Camera.turn", media.play, "/home/lbt/sounds/camera_click.wav")
connect(powerButton, "Button.longPress", powermenu.show_menu)
This uses a python signal library (like Qt or libsigc++) and provides a set of component objects that emit nice signals like "Connection.up".
The benefits of this approach:
- simple syntax is nice and readable
- interpreted so can easily be edited
- python understood by many so can be easily extended
- re-uses some powerlaunch code (eg powered)
- it's not a config file - it's code (but considering we want to configure functional behaviour then any config syntax needs to be a language... so use a decent one)
- python is quite large (but it's now in memory and .so are available)
- it's another re-write :( (it only took a few days and I'm using powerlaunch as a prototype for config rules - if I can understand them!!)
This says (well, I hope it says):
- There is a system and a user dispatcher
- They're based on a common Dispatcher
- Which contains components (such as Headphone, Menu etc) that can
- send signals (eg when the camera on the N800 is turned)
- take requests (dim the screen)
- provide state information (a headphone is connected)
- be accesed on D-Bus
- The Dispatcher creates Connections which
- listen() for Components to emit signals (also listening on D-Bus)
- run Scriptlets which might
- run arbitary code
- make requests to components
- emit signals that (other) Connections can listen() for
- Scriptlets are part of the Dispatcher
Oh, and the good news is that it's up and running... I'll put the code on gitorious RSN.