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 :-)
> Produces system model GUI dialogs for call handling (incoming, outgoing,
> in call) and manages pin entry on network registration.
This I'd like to be somewhat separate. If PhoneKit creates GUI
dialogs, that ties PhoneKit to a certain GUI framework entirely. Also,
people might want different functionality in these system modal
dialogs - and it would be a bother if these changes would need to be
made in to PhoneKit.
Perhaps a separate process communicating via dbus to handle these - I
see these related more to the actual UI framework (main menu,
profiles, task switching, etc.) than the phone functionality itself.
> The current "Today" application, provides the entry point for all
This looks fine as such, but...
One thing which has bothered me in OpenMoko from the start is that the
responsibilities of 'today', eg. show last calls, sms's, calendar
entries, and a 'task manager' have been bundled. And I'm unsure where
the other required OpenMoko specific functionality resides - main
menu, profiles and such.
I'm not sure if it's possible or reasonable to somehow get a clearer
distinction between these two - but I'd love it if it were possible.
And in general, I'd like to see everything built so that any component
can easily be substituted with an alternative implementation without
having to reimplement loads of secondary functionality - but I think
you know this better than me anyway :-)