Am Freitag, 17. September 2010, 12:27:48 schrieb 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. I wouldn't call phoneui-apps a layer itself. It is just to have an universal thing to start for example the contacts app regardless of what implementation will get executed in the end.
> > 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 No, not quite correct :-) You would *not* implement a DBus interface. phoneuid and only phoneuid has the GUI DBus interface. What you would implement instead is the interface to libphone-ui. For example for the contacts app you would have to implement the following: void phoneui_backend_contacts_show(); void phoneui_backend_contacts_deinit(); void phoneui_backend_contacts_contact_show(const char *path); void phoneui_backend_contacts_contact_new(GHashTable *values); void phoneui_backend_contacts_contact_edit(const char *path); > > 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. Getting contacts (or other stuff from opimd) is another thing libphone-ui abstracts from (or for) you. You just have to call: void phoneui_utils_contacts_get(int *count, void (*callback)(gpointer , gpointer), gpointer data); and your callback will be feeded with the contacts. > > 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. Hmm, what do you mean by core phone apps? The libphone-ui-shr? It is one possible implementation for a phoneui backend. Splitting it into different repos would make no sense in my opinion. There is lots of common stuff like gui helpers do show dialogs and such. Although for example the messages app is using the contacts list to show a list of contacts to select the recipient directly in the messages window. > > Like I say I'm still thinking and figuring this stuff out. Thanks again > for your response it has certainly helped me much. ;-) Just continue to ask :-) -- Klaus 'mrmoku' Kurzmann _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
