Hey Arigead :) > Klaus 'mrmoku' Kurzmann wrote: > > Am Dienstag, 14. September 2010, 15:34:42 schrieb Arigead: > > > > 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. > > > > First and foremost thanks for taking the time to respond. > > After that where to start? Obviously if anybody was asked to design a > system we'd all do it differently. I can sort of see how the SHR > implementation is working, thanks to your very good response, but it > does appear to be very complicated. > > d) phoneui-apps > c) libphone-ui-shr > b) libphone-ui > a) phoneuid > > The four 'layers' you mention, I'd say phoneui-apps is the highest > layer and it makes a simple DBus method call to the lowest layer, > phoneuid, which then comes up a layer to libphone-ui to see what's > registered as the current contacts app and then calls it in the > libphone-ui-shr layer. I'm struggling with that complexity. > > Like I say I'm new to this but if I was writing a Contacts app I would > have thought that I would have a few requirements mainly implementing > the specs you mentioned in the shr-specs repository. So for contacts > app for example I'd have to implement: > > org.shr.phoneui.Contacts > * DisplayList > * DisplayContact > * CreateContact > * EditContact > > Now I could write the application using any toolkit, like you > mentioned above. I'm registered to handle that DBus method so if any > app in the system wants to store a new contact they make the DBus > call. My app will get it and process it. In the same way if I'm > displaying a contact and wish to actually send the contact an SMS > message I'd make a call to org.shr.phoneui.Messages.CreateMessage I > don't know and don't really care who actually handles that call. If > nobody implements it then I've got a problem. SO long as somebody > implements it if I call the method the system should pop the app that > handles it without any action on my part. The app might be qt or > elementary or whatever I just make a DBus call and "walk away" > > I'd have to pull the Contacts out of opimd using DBus calls and store > new contacts or changes into opimd but as long as I did if I the user > changed their mind and decided that they'd prefer a different contacts > app then all would still work. > > Obviously I'm missing a certain amount of the picture but if I removed > all the layers you mentioned above from a build and simply implemented > an app and registered it with the correct DBus interface it would all > still work. I had thought that was the point of the DBus well know > interfaces. > > I'll think about this more and maybe see the light. > > At present all the core phone apps are in one repo and in one bitbake > recipe. It'd be nice, from my point of view, if these could be > separated into different repos and recipes so that each app was more > stand alone. You should be able to write a contact application the way you described it.
The shr phone application uses a dirty trick to reduce ''application startup'' times, libphone-ui *is* the application and is loaded when the x session starts. phoneui-apps consists of several small apps that communicate with libphone-ui via dbus to make the latter show the dialer or the contact app. (or at least that's the way I think it works...) Cheers, Justus
signature.asc
Description: PGP signature
_______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
