Re: Phone functionality in GUI applications
On Tue, 2007-10-16 at 17:31 +0200, pHilipp Zabel wrote: On 10/16/07, Nuutti Kotivuori [EMAIL PROTECTED] wrote: Thomas Wood wrote: On Friday, Mickey mentioned to me that libmokogsmd would probably not be used in the final software stack. Instead, he would prefer a d-bus based interface to GSMD. Yesterday, Rob, Chris and I sat down around a whiteboard and came up with some thoughts on how the phone functionality in GUI applications might be managed. I wholeheartedly applaud this decision. I was about to write a long mail with just about the same idea - good thing I don't have to :-) PhoneKit *Kit naming seems to be popular nowadays :) Well, the other contenders were PhoneD and PhoneManager. We decided PhoneKit probably fitted best. Plus what you mentioned. I wonder how feasible it would be to specify this dbus API so that it could be used as a Connection Manager (Voice Channel type) for the Telepathy framework. Sounds like a good idea. Do you know what is necessary to do this? Regards, Thomas -- OpenedHand Ltd. Unit R Homesdale Business Center / 216-218 Homesdale Road / Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559 Expert Open Source For Consumer Devices - http://o-hand.com/
Re: Phone functionality in GUI applications
Thomas - This I'd like to be somewhat separate. If PhoneKit creates GUI dialogs, that ties PhoneKit to a certain GUI framework entirely. Also, Perhaps a separate process communicating via dbus to handle these - I The reason we included the call handling GUI parts in PhoneKit was that we wanted to keep the number of processes running to a minimum. We ... use another GUI library, it should be easy to do this. I would suggest using a very simply plugin system such as a shared (or even static) library would be sufficient. The most important thing is to get the correct balance between modularity and abstraction, against the requirements of speed and low resource usage. I agree the UI and non-UI parts of PhoneKit should be 'somewhat' separated. Whether that's in a separate process, shared or static plugin, I would leave up to you. Personally as long as the sources within PhoneKit cleanly separate betwen visible and non-visible functionality, statically linked in is enough for me. I don't know d-bus (on my to-do list), just curious, if we would first have certain calls statically linked in a certain process, then in a later build move those same calls to another process, would we break backwards compatibility for applications (let's say without recompiling those apps)? In other words, are the names of processes or such encoded in d-bus or is it flexible enough to survive this kind of code move? We should not make it overly hard to later have OpenMoko-based phones with toolkits other than GTK+. Wolfgang
Re: Phone functionality in GUI applications
Thomas Seiler wrote: [...] Thanks Thomas [to both of you ;)], that's pretty close to my vision of how the OpenMoko system services architecture should look like (at least considering the phone services, I want to do similar with Device I/O services and PIM services). This is extensible (new services keep appearing all the time), pluggable (we can switch underneath implementations and) and generic (we can switch applications, deploy this in models without screens, or in products using $FancyToolKitOfTheYear... :D). I hope you get the idea. I would like hear what other think about this. Maybe it would be a good idea to start documenting possible interfaces in the WIKI ? Absolutely. Feel free to go ahead and launch a page if you have a chance. Next week I'll discuss this with the people working in .tw and then join. Cheers, :M: - Michael Lauer [EMAIL PROTECTED] http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone
