Or rather have the library or deamon providing functions for this stuff and have cli and gui clients which only use the function .so file or connect to deamon That would be even more universal, as it would give some API for other apps without installing additional stuff on the phone (unless it already works like that and one of the deamons you're talking about provides all that functionality and the gui interface is only a client, then please correct me)

Should be pretty simple to wrap into some bash scripts or whatever The only thing more complicated than one dbus call is opimd query, but I've written a handy CLI interface in Python for it long time ago: http://git.shr-project.org/git/?p=op...0e7b02;hb=HEAD

(and mdbus2 is a very nice dbus tool. You could do the same with dbus-send, but mdbus2 has simplier syntax and amazing interactive mode with autocompletion )

Let me explain the architecture of FSO/SHR system a bit:

FSO daemons (fsogsmd, fsodeviced, fsousaged, etc.) talk directly with the hardware and provide a dbus API for other apps to use. So, for instance, fsogsmd exports an API for basic stuff like "send message", "initiate a call", "release a call", definies signals for "incoming message", "incoming call" etc. and other applications can use that API to talk with the modem, no matter which modem it is (as long as it's supported by FSO).
So FSO daemons are "servers" here.


Then, there are SHR apps. Here it's a bit more complicated, as there are both servers and clients, even simultaneously.

phoneuid - it's a daemon that runs the UI stuff. It's also a server that exports its own dbus API. phoneuid actually does nothing else than displaying particular UI screen when requested to do so. You can use this API in your app to, for instance, request user to add a number to his contact book (as opposed to doing it for him via using FSO's opimd directly).

What's interesting - phoneuid doesn't have its UI implemented in it. It's modular - it can use a different library for every screen (like contacts, messages, dialer etc.) and it's configurable by the user in config file. By default it uses libphone-ui-shr (which uses E17 libs) for everything, but you could write your own library - and it doesn't matter if it would use GTK+, Qt or dunno what else instead. UI libraries use standard FSO API to perform actions, just like the mdbus2 calls above.

And the last one:

phonefsod - the binding between FSO and SHR. This is a daemon that listens on FSO signals and reacts accordingly by launching phoneuid actions. For instance, when FSO reports incoming call, phonefsod calls org.shr.phoneui.CallManagement.DisplayIncoming and phoneuid displays a "incoming call" window as implemented in libphone-ui-shr. Or, when FSO reports timeout on inactivity, phonefsod calls org.shr.phoneui.IdleScreen.Display, and phoneuid displays the lock screen.

There are also phoneui-apps (like phoneui-contacts, phoneui-dialer etc.), but those are just thin wrappers on single dbus calls and can be easily replaced with mdbus2 invocations.

I suppose we're drifting a bit away from the topic in this thread, but hopefully this helps a bit... and maybe someone will decide to give it a go and will become a SHR developer - there's A LOT of stuff to do, so it's a perfect opportunity to learn when hacking on interesting stuff!

http://wiki.maemo.org/Phone_control#Make_a_phone_call
http://wiki.maemo.org/Phone_control#Send_SMS
http://maemo.cloud-7.de/maemo5/usr/local/bin/contact2

cheers
jOERG