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 > -------- [...] > 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. > Home > ---- > > The current "Today" application, provides the entry point for all > software. 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 :-) -- Naked
