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
