GrandCentral for Mer... connecting the components

First, I'm sorry but this isn't an N900 post :) instead I've been looking at one of the areas that's holding back Mer. It's fairly simple conceptually: just handling interaction between various parts of the system; and by this I mean things like screen dimming; what happens when you press the power key; shutting down when the battery is low; waking up for an alarm... Things that should just work.  Well, I think I have a potential solution. (Oh, and some of you may be interested... I also found out how far eclipse has come in the UML modelling space too!)

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
def on_wifi_up():
  notify "The wifi is up"
  os.system("mail me@gmail.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)

Of course there are drawbacks:

• 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!!)

So anyway, as I said, I found eclipse Modelling edition...

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.