Phone functionality in GUI applications

Wolfgang Spraul wolfgang at openmoko.com
Tue Oct 16 18:43:14 CEST 2007


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





More information about the framework-devel mailing list