Re: Help with creating daemon for n900
 

Thanks tons. I'll definitely. Well it worth the stay till this long '5am'. Off I go now and will certainly return with new questions :D

Re: Help with creating daemon for n900
 

As I said, I'm back with ;) The thing is I didn't get why there are so many marshal* things needed.

Re: Help with creating daemon for n900
 

As you will have noticed, D-Bus signals are handled like "normal, GObject-type" signals in DBus-GLib (think of dbus_g_proxy_connect_signal () as the D-Bus version of g_signal_connect ()).
g_signal_new requires a marshaller to be able to send whatever it receives (in this case, the two gchars* from MCE) to the callback function (see http://gnomejournal.org/article/36/w...d-gtk28-part-2 for an example on how it's used there).

So, according to http://maemo.org/api_refs/5.0/5.0-fi...5a46afdad43a94 , we receive two gchars*.
So our callback function signature is to look like "static void call_state_changed_cb (DBusGProxy *object G_GNUC_UNUSED, const gchar *call_state, const gchar *emergency_call_state G_GNUC_UNUSED, gpointer user_data G_GNUC_UNUSED)".

(G_GNUC_UNUSED is only there because I'm [generally] pedantic/anal about GCC warnings...)

But if we look at http://maemo.org/api_refs/5.0/5.0-fi...-Closures.html , we see GLib only comes with a marshaller (g_cclosure_marshal_VOID__STRING) that would only handle "static void call_state_changed_cb (DBusGProxy *object G_GNUC_UNUSED, const gchar *call_state, gpointer user_data G_GNUC_UNUSED)" (i.e. a DBus signal that only sends back one gchar*).

That is not what we want and, in any case, it wouldn't work - the callback function would never be called.

So we use glib-genmarshal to create a marshaller that understands VOID__STRING_STRING, matching the signature of the first callback function and we then use dbus_g_object_register_marshaller () to register it with DBus-GLib.

Re: Help with creating daemon for n900
 

Thanks for your time to explain. I'll have to go through it more coz I'm not quite familier with dbus let alone dbus-glib. However, I came across another problem coz as I'm using libhal to listen to hardware property changes and it uses dbus I couldn't think of how I could link dbus-glib and hal so I just made the whole thing which gets the current call state into one method with all the dbus-glib thing and flushes this connection after it gets what it wants while the main loop which uses plain dbus is there. So, I was wondering if there's better way to do it.

Anyway, I've got it to work and quickly created a .deb file and does what it is suppose to do. I guess I'll start a new thread for it and let this one continue coz I have more to implement ;)

Re: Help with creating daemon for n900
 

If you run dbus-monitor, you'll notice that events are broadcast by HAL on the System bus, anyway, so you can just connect to those signals as you would any other.

But if you wish to use libhal; I haven't looked too deep into libhal because of the libdbus requirement, but I believe it requires a DBusConnection rather than a DBusGConnection. You can get a DBusConnection from your DBusGConnection by calling dbus_g_connection_get_connection (). The DBusConnection will automatically be integrated into the mainloop because dbus_connection_setup_with_g_main was called when you did dbus_g_dbus_get.

However, you will have to look into the libhal API reference to see how you check for events and the like - I can't help there, sorry.

P.S. If you're just checking to see if the keyboard is slid open, you can get the value of the GConf key /system/osso/af/slide-open. GConfClient is rather easy to use and you can get notifications of the key being changed.