This project is daemon which listens to dbus signals and runs applications accordingly.
The signals, application to run and some rules that will be evaluated against incoming dbus signals can be easily changed in the configuration file.
This application is mainly intended to work with the openmoko framework so end users will be able to run application upon events without too much effort, though that isn't a limitation.
For example, one can set the aux button to launch the dialer and the other can set a sound when screen is dimmed with as little as no effort.

(The default config file is set to run the profile-changer when the aux button is pressed for more than a second)

IMPORTANT NOTICE: The project page in projects.openmoko.org is finally up. Hope you all will participate. From now on, that's the place to post bugs/suggestions. Hopefuly, I will start using it completely soon (when the problems are fixed)

siglaunchd connects to dbus signals set in the config file and compares the signal's parameters to the expected parameters in the config file, every dbus signal in the config file has a "app to launch" that's launched when the signal is matched.

This daemon reads the configuration file looking for records of the type:
"app"=interface;busname;path;signal;rule1,rule2...
While:

app is the app to run (and parameters) enclosed with "

interface, busname, path and signal are the signals descriptors.

rules are separated by a ',' and look like arg[index][opt-sub_index](=|<|>|~)value. arg[] is a configuration file pattern and shouldn't be changed.

The value field can't contain ',' (reserved char) unless the whole value is enclosed in "" (i.e "test, test!"). Enclosing with " doesn't assure matching as strings, as explained later.
The [opt-sub_index] is used to determine the index/key to compare in arg[index] if it's an array/dictionary.

For instance, comparing the second argument's 1st cell will look as follows: arg[1][0] = test

When the argument is neither expected to be an array or a dictionary you should just drop the second [] i.e: arg[2] = test3

Evaluation types:

= is for string/number comparison

> and < are for number/string comparison

~ is used for standard python regex evaluation.

For example if I a rule to check if the first parameter got from the dbus
signal equals to "test" the rule will be: arg[0]=test

Launch string:

The launch string must be enclosed with " and in the string \ is used for escaping, i.e: \" is a regular " \\ is a regular \ and any character a results in \a is a.

You can use $# (# is an integer bigger than 0) to use the value got from matching to the dbus rule. $1 corresponds to the first argument matched against, $2 to the second. values are permitted from 1 to n where n is the number of comparisons in a specific rule.

will enter the value of arg[2] (the first argument compared) to the file /home/root/click.txt

You can actually add as many lines you want to the config and associate as many
applications needed to a single signal with different/same rules (in different lines).

Another example:
the "Event" signal form the "org.freesmartphone.Device.Input" interface in the framework sends looks like this:
Event ( ssi )
where the arguments are:
the first s = name of input device
the second s = the action took place
i = duration of the event.
We can then tell the daemon to "echo hi" (not very useful) every time an Event signal of any kind arrives like this:

Btw, all the rules are logicaly connected with an AND operation, so they all must match!
If you want an OR logical connection you must add a brand new line differing in what you want it to differ.
IMPORTANT NOTICE: All parameters not evaluated are accepted by default. So when writing bad config lines, i.e comparing with an argument that does not exist, will be accepted as if it was matched.

All dbus types are supported (byte was never tested and struct/objectpath aren't supported yet), and when comparing to booleans, 0 is false 1 is true, true and false are read as the strings "true" and "false" accordingly.

All rules are compared according to the type of the parameter of the dbus signal so a rule that compares to the number 88 will compare as the double 88 when compared with double, as an unsigned int 16 bit when compared to one and as a string when compared to one.

Although the power button is set to be the suspend on fso/shr and when held for more than 10 seconds it will shut down the device, in the area between, I set it to launch the flashlight app, because I don't like messing with stuff when I need my flashlight on!
(you can easily change it to run anything else, so this is also a good example for using the power button)

This config line matches the caller's number and acts according to a specific caller, it is possible to regex match the number, so you can match for calls from a certain city/country/phone-prefix and act accordingly.

For instance all the calls from private numbers will automatically close/recorded, the options are unlimited.

just replace the echo message with the script (popup?) you want to run.

NOTE: it seems that there's no IncomingMessage signal (also specified in the fso specs) so
org.freesmartphone.GSM.SIM.IncomingStoredMessage should be used instead and the first parameter there is the id of the sms which can be used as a parameter to a script that gets out the content.

This project is daemon which listens to dbus signals and runs applications accordingly.
The signals, application to run and some rules that will be evaluated against incoming dbus signals can be easily changed in the configuration file.
This application is mainly intended to work with the openmoko framework so end users will be able to run application upon events without too much effort, though that isn't a limitation.
For example, one can set the aux button to launch the dialer and the other can set a sound when screen is dimmed with as little as no effort.

(The default config file is set to run the profile-changer when the aux button is pressed for more than a second)

IMPORTANT NOTICE: The project page in projects.openmoko.org is finally up. Hope you all will participate. From now on, that's the place to post bugs/suggestions. Hopefuly, I will start using it completely soon (when the problems are fixed)

Package

How To Use

siglaunchd connects to dbus signals set in the config file and compares the signal's parameters to the expected parameters in the config file, every dbus signal in the config file has a "app to launch" that's launched when the signal is matched.

This daemon reads the configuration file looking for records of the type:
"app"=interface;busname;path;signal;rule1,rule2...
While:

app is the app to run (and parameters) enclosed with "

interface, busname, path and signal are the signals descriptors.

rules are separated by a ',' and look like arg[index][opt-sub_index](=|<|>|~)value. arg[] is a configuration file pattern and shouldn't be changed.

The value field can't contain ',' (reserved char) unless the whole value is enclosed in "" (i.e "test, test!"). Enclosing with " doesn't assure matching as strings, as explained later.
The [opt-sub_index] is used to determine the index/key to compare in arg[index] if it's an array/dictionary.

For instance, comparing the second argument's 1st cell will look as follows: arg[1][0] = test

When the argument is neither expected to be an array or a dictionary you should just drop the second [] i.e: arg[2] = test3

Evaluation types:

= is for string/number comparison

> and < are for number/string comparison

~ is used for standard python regex evaluation.

For example if I a rule to check if the first parameter got from the dbus
signal equals to "test" the rule will be: arg[0]=test

Launch string:

The launch string must be enclosed with " and in the string \ is used for escaping, i.e: \" is a regular " \\ is a regular \ and any character a results in \a is a.

You can use $# (# is an integer bigger than 0) to use the value got from matching to the dbus rule. $1 corresponds to the first argument matched against, $2 to the second. values are permitted from 1 to n where n is the number of comparisons in a specific rule.

will enter the value of arg[2] (the first argument compared) to the file /home/root/click.txt

You can actually add as many lines you want to the config and associate as many
applications needed to a single signal with different/same rules (in different lines).

Another example:
the "Event" signal form the "org.freesmartphone.Device.Input" interface in the framework sends looks like this:
Event ( ssi )
where the arguments are:
the first s = name of input device
the second s = the action took place
i = duration of the event.
We can then tell the daemon to "echo hi" (not very useful) every time an Event signal of any kind arrives like this:

Btw, all the rules are logicaly connected with an AND operation, so they all must match!
If you want an OR logical connection you must add a brand new line differing in what you want it to differ.
IMPORTANT NOTICE: All parameters not evaluated are accepted by default. So when writing bad config lines, i.e comparing with an argument that does not exist, will be accepted as if it was matched.

All dbus types are supported (byte was never tested and struct/objectpath aren't supported yet), and when comparing to booleans, 0 is false 1 is true, true and false are read as the strings "true" and "false" accordingly.

All rules are compared according to the type of the parameter of the dbus signal so a rule that compares to the number 88 will compare as the double 88 when compared with double, as an unsigned int 16 bit when compared to one and as a string when compared to one.

Power button - Launch Flashlight

Although the power button is set to be the suspend on fso/shr and when held for more than 10 seconds it will shut down the device, in the area between, I set it to launch the flashlight app, because I don't like messing with stuff when I need my flashlight on!
(you can easily change it to run anything else, so this is also a good example for using the power button)

Incoming Caller Matching

This config line matches the caller's number and acts according to a specific caller, it is possible to regex match the number, so you can match for calls from a certain city/country/phone-prefix and act accordingly.

For instance all the calls from private numbers will automatically close/recorded, the options are unlimited.

just replace the echo message with the script (popup?) you want to run.

NOTE: it seems that there's no IncomingMessage signal (also specified in the fso specs) so
org.freesmartphone.GSM.SIM.IncomingStoredMessage should be used instead and the first parameter there is the id of the sms which can be used as a parameter to a script that gets out the content.