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.
Like I say I'm still thinking and figuring this stuff out. Thanks again
for your response it has certainly helped me much. ;-)
_______________________________________________
Shr-devel mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-devel
