Am Dienstag, 14. September 2010, 15:34:42 schrieb Arigead: > Hello all, > I've been looking at the code a bit for the phone apps and I'm a bit > confused by the architecture. Now I should say that I'm not familiar > with the design decisions that produced the current solution nor am I an > expert in any shape or form. > > Having said all that it seems to me that the apps are quite complicated. > The high level apps use DBus calls into libphone-ui-shr, which goes on > to a lower level. I know that all the phone apps must be integrated with > each other but that's what DBus gives them. If the contacts for example > was defined in a wiki page, giving the DBus calls it can make to pick up > the contacts stored in the phone from opim, and the DBus signals and > calls that other apps are expecting the contacts App to honour, Then 10 > people here could develop 10 different contacts apps which all integrate > into the system. > > Like I say I'm not an expert but I was hoping to write one of these apps > to my own particular taste. Problem is that the current apps seem so > tightly coupled to the underlying system. If I did write a contacts app > the existing contacts app will still be in the system as all the apps > are in one bitbake recipe. > > The beauty of this OpenSource stuff is that people can write their own > idea of the ideal. I'm currently running two phones on two accounts. One > is an android and the other is my FreeRunner SHR-U. I don't use the > default Android SMS Messages app as I prefer a third party app for SMS > Messages on the Android. It don't seem as straight forward as maybe it > could be to do the same on the SHR. Maybe I should say FSO? Maybe I'm on > the wrong list but I'm sure there is a degree of overlap here. > > Having said all that I'm a newbie and clueless. A bear of little brain, > so to speak. Please feel free to educate me.
Let me try to explain the design and the reasoning behind it - at least as far as I understand it :-) The phone GUI is built out of the following components. a) phoneuid b) libphone-ui c) libphone-ui-shr d) phoneui-apps phoneuid is the daemon running and offering a dbus-interface as specified in the shr-specs repository (http://git.shr-project.org/git/?p=shr- specs.git;a=summary). It implements the org.shr.phoneui part of the specification. It links with libphone-ui and calls into it's functions when one uses one of it's dbus methods. libphone-ui is an abstraction layer. It is used to make phoneuid toolkit agnostic. We need this to be able to have for example a contacts app that is implemented with elementary and a phonelog app implemented with qt. Or even using the same toolkit but being two different implementations of one component (like contacts, messages, dialer, phonelog...) - that's what you want to do :-) libphone-ui dynamically loads the configured backends when phoneuid is started (see /etc/libphone-ui.conf). It starts an extra mainloop for every different backend (at least in theory). libphone-ui-shr is the actual GUI - one backend, which is dynamically loaded by libphone-ui. Whenever phoneuid calls into libphone-ui, that call is relayed to the configured backend for the relevant component. phoneui-apps are actually very uninteresting and just wrappers for a dbus-call into phoneuid to show one of the GUI parts. For example shr-dialer does nothing else than calling org.shr.phoneui.Dialer.Display. So, to write your own contacts GUI all you have to do is to write a libphone- ui-agriread implementing appropriate interface - again in theory :/ Unfortunatelly the multi-mainloop-part in libphone-ui is not yet implemented. So far we had no need to implement that, as there is only one backend. Maybe it's time to revisit that part :-) I hope that clarifies stuff a bit - if you have further questions, just ask. -- Klaus 'mrmoku' Kurzmann _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
