Am Freitag, 17. September 2010, 12:41:25 schrieb Justus Winter: > 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. Well, I wouldn't call that a 'drity trick' ;) It does even more. It caches windows. You can notice that when for example starting the contacts app for the first time... It takes a while to feed it with the contacts. The second start will be instantenous... It keeps the contacts window with all contacts loaded and just shows it :-)
> > (or at least that's the way I think it works...) > > Cheers, > Justus -- Klaus 'mrmoku' Kurzmann _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
