Am Montag, den 16.11.2009, 16:28 +0100 schrieb Nicola Mfb: > On Mon, Nov 16, 2009 at 4:12 PM, Michael 'Mickey' Lauer > <mic...@vanille-media.de> wrote: > > Am Dienstag, den 10.11.2009, 22:15 +0100 schrieb Nicola Mfb: > >> Is there a way to detect if FSO is full started and ready? > >> Many apps call list resource to wait e.g. for GSM, I'd like to use a > >> way to be sure all FSO subsystem are ready. > > > > Using the resource availability signal is indeed the best way to query > > for certain subsystem readyness. In the future, fso-monitord will manage > > subsystem lifecycle, so we could add something like that there, if you > > find a usecase for it. > > Hi Mickey! > I noted that while coding a simple tray applet that shows the battery status. > At startup it fails to read the status, but after some minutes it get > the signal from dbus and updates correctly. > At the same time I have litephone that "waits for fso" looping on dbus. > > Actually I should check why at startup the battery status was not > available, but instead of filling every piece of the desktop > environment with such "tricks" I'd like to have a dbus signal as "FSO > is ready", and after that startup all the applets, litephone etc. etc. > > Please point me if that may not have sense :)
The problem with that is that there is no such thing as a global FSO status. FSO has a modular architecture and can be configured to contain from one up to several subsystems. The fact that the Python reference implementation comes as one single process is mereley due to optimization, FSO2 will come as one subsystem per process, so there's no entity right now that has the knowledge about which subsystems are going to be started at all. There's two options to deal with that: 1.) on resource basis, 2.) on name owner basis. 1.) If all you want to know is when certain FSO resources are up and running, then just listen for FSO resource signals. 2.) If you want to know when certain FSO objects are available for calling that are no FSO resources, then use the DBus NameOwnerChange signal to wait for the process you know will serve the objects you want to call. In the future, fso-monitord will perhaps contain something additional, but for now 1.) and 2.) are way to go. :M: _______________________________________________ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
