Friday, 4 September 2009

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 -S 'wifi is up'")

connect(wifi, "Connection.up", on_wifi_up)

connect(camera, "", takePhotoAfter10Secs)
connect(camera, "Camera.turn",, "/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.

1 comment: