Re: Phone functionality in GUI applications
Hello Thomas, On Thu, 18 Oct 2007 03:34:36 +0200 Thomas Seiler <[EMAIL PROTECTED]> wrote: > (drawing board only ;-) > > I would like to see a more generic "Context Service", that takes > the various inputs of > > - last known GPS longitude / latitude and speed > - GSM Area Code and Cell ID and rate at which these codes change > - ESSID of avaibale WLANS > - Bluetooth MAC Addresses of nearby Workstations and other Handies have a look at GeoClue: http://www.freedesktop.org/wiki/Software/GeoClue This already provides some of the functionality you mention and new backends are fairly easy to implement. Regards, Daniel Willmann signature.asc Description: PGP signature
Re: Phone functionality in GUI applications
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rodolphe Ortalo schreef:
> Le jeudi 18 octobre 2007 à 02:19 +0200, Thomas Seiler a écrit :
>> Am 17.10.2007 um 13:58 schrieb Joachim Steiger:
> [...skipped...]
>>> [...] first it has to be a
>>> working phone.
>> Ok, then lets discuss what is all needed for a minimalistic interface
>> to get the phone working:
>>
>> - GSM: trigger network registration, get registration infos, signal
>> registration info and signal strength updates
>> - SIM: get state, signal PIN entry required, enter pin
>> - VoiceCall: call number, end call, accept incomming, reject
>> incomming, signal for dialing, waiting, talking, busy and ringing
>>
>> Anything else ?
>
> Personnally, I would (try to) add a GPS entry here as it's one of the
> main hardware innovation of modern "phones".
>
> - GPS: location available/not available, trigger acquisition, get last
> known location, (...?)
Both gpsd and gypsy already have a dbus interface for that, no need to reinvent
the wheel
thare.
>
> Apart from this (purely personal) subject, the following aspects are
> probably expected too in a working phone:
>
> - "Energy" state/requirements: power-line available, on battery, on low
> battery, low-energy target (for user-requested long duration)...
> - (Data) Network availability (zero-cost/cheap/expensive)
Isn't that the territory of HAL+OHM?
> Lalo recommended looking at the existing Telepathy APIs. Any more
> precise pointers available? (Especially for the last point.)
IIRC maemo has a dbus connection interface ("connect to gprs", "connect to
wifi", etc).
>
> Rodolphe
>
>
>
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFHFxMsMkyGM64RGpERAiVXAJ0WvbTGOLPrJcrSXV8YfUuCLkBeIQCeP5Ks
EA2cMeqxOLhhN9jy12QOspo=
=Es5A
-END PGP SIGNATURE-
Re: Phone functionality in GUI applications
Le jeudi 18 octobre 2007 à 02:19 +0200, Thomas Seiler a écrit : > Am 17.10.2007 um 13:58 schrieb Joachim Steiger: [...skipped...] > > [...] first it has to be a > > working phone. > > Ok, then lets discuss what is all needed for a minimalistic interface > to get the phone working: > > - GSM: trigger network registration, get registration infos, signal > registration info and signal strength updates > - SIM: get state, signal PIN entry required, enter pin > - VoiceCall: call number, end call, accept incomming, reject > incomming, signal for dialing, waiting, talking, busy and ringing > > Anything else ? Personnally, I would (try to) add a GPS entry here as it's one of the main hardware innovation of modern "phones". - GPS: location available/not available, trigger acquisition, get last known location, (...?) Apart from this (purely personal) subject, the following aspects are probably expected too in a working phone: - "Energy" state/requirements: power-line available, on battery, on low battery, low-energy target (for user-requested long duration)... - (Data) Network availability (zero-cost/cheap/expensive) Lalo recommended looking at the existing Telepathy APIs. Any more precise pointers available? (Especially for the last point.) Rodolphe
Re: Phone functionality in GUI applications
Please don't reinvent any wheels. Use the Telepathy APIs for everything where it's applicable, and only invent new interfaces where it isn't. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/
Re: Phone functionality in GUI applications
Am 16.10.2007 um 21:32 schrieb Rodolphe Ortalo: What about adding GPS to the overall picture? Maybe that it's too early, but if there are some interactions with the phone aspects, it would be better to try to anticipate them. (Of course, only on the *drawing* board.) (drawing board only ;-) I would like to see a more generic "Context Service", that takes the various inputs of - last known GPS longitude / latitude and speed - GSM Area Code and Cell ID and rate at which these codes change - ESSID of avaibale WLANS - Bluetooth MAC Addresses of nearby Workstations and other Handies and creates a context out if it, i.e. - AtHome / AtWork/ AtUserConfiguredLocationX / Y / Z... - Driving / Walking / Stationary - Meeting with Boss / Near Workstation, etc... at a later stage, these contexts could be linked to automatic actions: Meeting with Boss => Mute Ringer Driving => Speakerphone Mode, AutoAccept after 3 Rings, etc... etc... Thomas
Re: Phone functionality in GUI applications
Am 17.10.2007 um 13:58 schrieb Joachim Steiger: please do not overengineer this from the beginning, i think interfaces should be added when being implemented. Yes, sorry for this. I have exaggerated there. I wanted to show that we are dealing with many interdependent state machines, and my point is that a DBUS-interface for openmoko should be fine grained and orthogonal rather than monolithic. The rationale behind the fine grained idea is that it allows applications to test for availability of specific functionality (i.e. GPS) using DBUS Introspection. So we wont need a capability query layer. The rationale behind orthogonality is that its easier to get going, test and extend. We can start with a single state machine (i.e. SIM) and add others as we move forward without changing what was done to drastically. also note that gnome already has a way of handling network interfaces when it comes to ip connectivity (see http://www.gnome.org/projects/NetworkManager/) Thanks for pointing that out. I somehow completely missed this. i think we should make use of that/extend that functionality before reinventing the wheel once again (remember, there are wifi with hidden essid, wpa/wep/wpa2 and similar crap which needs to fit in there) I like the idea to reuse and extend what is already there. The GPRS IP Connectivity is a bit special, though. I can see that applications that would benefit to know if network access is "expensive" or "cheap" at the moment and change their behavior. One other thing to keep in mind is the EAP-SIM Standard (RFC4186) Its a method to authenticate yourself on a WPA Network with a SIM Card, many hotspots in main stations and the like do support it. i really do NOT wanna discourage anybody, but this just popped into my mind while reading this. Thanks for the reality check ;-) [...] first it has to be a working phone. Ok, then lets discuss what is all needed for a minimalistic interface to get the phone working: - GSM: trigger network registration, get registration infos, signal registration info and signal strength updates - SIM: get state, signal PIN entry required, enter pin - VoiceCall: call number, end call, accept incomming, reject incomming, signal for dialing, waiting, talking, busy and ringing Anything else ? Regards, Thomas
Re: Phone functionality in GUI applications
Thomas Seiler wrote: [...] > Similar Objects could be implemented for: > > org.openmoko.GSMNetwork: > org.openmoko.Ringer: > org.openmoko.VoiceAudioRouting: > org.openmoko.VoiceCall: > org.openmoko.FaxCall (send and receive Faxes, integrate with CUPS ?) > org.openmoko.DataCall (CSD Data Call to other Neo or normal modem) > org.openmoko.Wlan (WLAN Present ? Power On / OFF, select ESSID) > org.openmoko.GPRS (To set APN, set status) > org.openmoko.USBNET (To sync?) > org.openmoko.IPNetwork (General Information of kind of Connection > org.openmoko.SIP that will be a lot of fun... > org.openmoko.GPS (last known longitude, latitude, power on / off) > org.openmoko.Location (more elaborate, higher level (i.e. Home, Work) please do not overengineer this from the beginning, i think interfaces should be added when being implemented. also note that gnome already has a way of handling network interfaces when it comes to ip connectivity (see http://www.gnome.org/projects/NetworkManager/) i think we should make use of that/extend that functionality before reinventing the wheel once again (remember, there are wifi with hidden essid, wpa/wep/wpa2 and similar crap which needs to fit in there) what i do not wanna see is a 'connectivity-abstraction' which is as simplified and crippled as on current wince/symbian devices which does not have the possibility to connect to hidden essid, have automatic roaming into wifi you already connected to once, remembers wep/wpa keys etc. so i would leave that whole stuff out for now. first it has to be a working phone. i really do NOT wanna discourage anybody, but this just popped into my mind while reading this. kind regards -- roh
Re: Phone functionality in GUI applications
Thomas Wood wrote: > On Wed, 2007-10-17 at 01:48 +0200, Michael 'Mickey' Lauer wrote: >> 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). > Ok. Are your ideas documented anywhere? Only on paper. I didn't find a couple of undistracted days to put any of that in the wiki as a discussion base. I'm pretty sure I can do that while I'm in .tw next week. >> 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). > So your idea is basically an "OpenMoko Abstraction Layer" to allow the > service and user implementations to be switchable? In principle, yes. Making dbus interfaces the line. Initially, this what was I wanted to do with libmoko*, however you have convinced me that doing this in the library/framework may not be the best way to do it. > What are your time scales for this? Within the next 12 months. > Do you expect it to be shipping when GTA02 goes on sale? No. > If PIM services are part of it, then will it not > require a major rewriting of the existing core applications? Not as long as they work fine. I added PIM services to this list of things because I want to rethink whether eds is really high level enough to allow arbitrary applications querying and attaching personal data in a simple way. It needs more experimentation, but then again, the phone and device I/O services should be priorized now. - Michael Lauer <[EMAIL PROTECTED]> http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone
Re: Phone functionality in GUI applications
On Wed, 2007-10-17 at 01:48 +0200, Michael 'Mickey' Lauer wrote: > 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). Ok. Are your ideas documented anywhere? > > 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). So your idea is basically an "OpenMoko Abstraction Layer" to allow the service and user implementations to be switchable? What are your time scales for this? Do you expect it to be shipping when GTA02 goes on sale? If PIM services are part of it, then will it not require a major rewriting of the existing core applications? 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 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
Re: Phone functionality in GUI applications
Hi > 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. Great ! > 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. Great ! Good News... I have already spend quite some time thinking about how such an interface might look like. In my opinion, the best solution is to have a separate DBus-Service for each independent State machine of the openmoko problem space, and to implement all these DBus-Services in a single daemon. Lets call this daemon "openmokod" or just "mokod". It would provide the openmoko platform abstraction. This daemon might for example implement a DBUS-Service / Object to access the SIM Card. org.openmoko.SIM: * Goals: - Abstract the fact that you need to access the SIM via gsmd / libgsmd, - multiplex SIM Access between different applications (phone book, SMS, setting, pin dialogs) - maybe cache some things (phone book ?) in memory - send a signal that can be hooked in GUI whenever there is a need to enter a PIN / PUK. * Possible States: NO_SIM_PRESENT, SIM_OPEN, SIM_LOCKED, NEED_PIN, NEED_PUK, NEED_PIN2, NEED_PUK2, * Possible Methodes: enterPIN, enterPUK, enterPIN2, enterPUK2, changePIN/PUK, close_sim, accessPhonebook, accessSMS, etc... * Possible Signals: OnNeedPIN, OnNeedPUK, etc... Advantages of this orthogonal approach: The PIN Problem is dealt with, whatever reason there is for PIN entry (i.e. reseting the SIM expense counters from a SIM menu) when the GUI reacts to the right signal it will show whenever there is a need to enter some PIN / PUK. Similar Objects could be implemented for: org.openmoko.GSMNetwork: * Goal: Abstract all Meta Information about the GSM Network, provide an interface to choose the network to connect to. * States: NO_SIGNAL, EMERGENCY-ONLY, REGISTERED_HOME, REGISTERED_VISITOR * Methodes: getNetworks, setPreferredNetwork, register, unregister, getDeviationStatus * Signals: OnSelectNetwork, OnRSSIDChange (to update signal strength bar), OnAreaCodeChange() Here we can place some hooks for least cost network selection when on visitor networks (abroad) or we can have listeners for the OnAreaCodeChange if they want to do fancy things like strarting the GPS to update location. org.openmoko.Ringer: * Goal: Abstract the possible Mixer Issues, and the loud / meeting profile thing * States: Profile_X, Profile_Y etc... * Methods: Ring(callerID) to be called by gsmd , etc... * Signals: AboutToRing, OnRing... org.openmoko.VoiceAudioRouting: * Goal: Abstract the Mixer and Audio Routing during a Voice Call * States: Audio Routing: STANDBY, HANDSET, HEADSET, SPEAKERPHONE, BLUETOOTH Mic Mute: MIC_ON, MIC_MUTED org.openmoko.VoiceCall: * Goal: Abstract the fact that you need to talk to gmsd for a VoiceCall Manage Conference Calls, put calls on hold, Mnage different Lines etc... * States: ON-HOOK, DIALING, WAITING, TALKING, RINGING (incomming call) This one is a quite complex one. We will need to include hooks for Least Cost Routing, or Send Signals to the Jurnal, etc... org.openmoko.FaxCall (send and receive Faxes, integrate with CUPS ?) org.openmoko.DataCall (CSD Data Call to other Neo or normal modem) org.openmoko.Wlan (WLAN Present ? Power On / OFF, select ESSID) org.openmoko.GPRS (To set APN, set status) org.openmoko.USBNET (To sync?) org.openmoko.IPNetwork (General Information of kind of Connection (WLAN/GPRS or how cheap/expensive it is ) org.openmoko.SIP that will be a lot of fun... org.openmoko.GPS (last known longitude, latitude, power on / off) org.openmoko.Location (more elaborate, higher level (i.e. Home, Work) based on GPS, WLAN ESSID, Area Code of Cell ID or Bluetooth Adresses (PCs), whatever there is) These signals might be used to switch profiles, etc... 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 ? Cheers, Thomas -- Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction.
Re: Phone functionality in GUI applications
Le mardi 16 octobre 2007 à 12:57 +0100, Thomas Wood a écrit : > Hi, > > 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. What about adding GPS to the overall picture? Maybe that it's too early, but if there are some interactions with the phone aspects, it would be better to try to anticipate them. (Of course, only on the *drawing* board.) > [...remaining stripped...] > Apart from that, I find the overall design pretty good (including the remarks wrt UI separation via software libs or plugins). Regards, Rodolphe
Re: Phone functionality in GUI applications
Wolfgang Spraul wrote: > 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? Nothing should break. With dbus, you register to provide a well known name and other processes look for connections which have the well known name. As long as the names are different, the calling process will not know whether they are provided by the same process or different processes. In this case however, the question was about showing dialogs - and no dbus communication would be there to take place if PhoneKit does it itself. Unless ofcourse this is implemented with PhoneKit talking to itself over dbus, which would be a bit odd. -- Naked
Re: Phone functionality in GUI applications
Thomas Wood wrote: > 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 > started out thinking purely in terms of OpenMoko's requirements and we > assumed GTK+ would be the "official" GUI toolkit. However, if there is > demand for PhoneKit outside of OpenMoko, or even if OpenMoko decide to > 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. How about integrating this with the home (today) application? I think it fits there better since that application already has an X connection, is always on and already takes some system management responsibilities (such as task switching etc.). Also, if somebody wants to replace home with something else, it is very conceivable that the call handling will have to be somewhat different as well. > The most important thing is to get the correct balance between > modularity and abstraction, against the requirements of speed and > low resource usage. Definitely! -- Naked
Re: Phone functionality in GUI applications
On 10/16/07, Thomas Wood <[EMAIL PROTECTED]> wrote: > > 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. Agreed, that was just an observation. > > 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? I've only read the telepathy spec, I don't have any background in Telepathy. But when I saw "The Telepathy project aims to provide a unified framework for all forms of real time conversations, including [...] voice calls [...]" on telepathy.freedesktop.org, I wondered why this should be limited to sip+VoIP. As far as I understand, the PhoneKit part would just have to supply implementations of the ConnectionManager, Connection and Channel interfaces. AFAIU there'd need to be a new protocol (gsm, cellular, or something like that) and a new simple channel type for voicecalls where the sound isn't transported by the host CPU like with the StreamedMedia channel type. For the ConnectionManager interface, network operator selection could be a bit awkward, as the current RequestConnection method only specifies account name / password / server fqdn, maybe a non-standard operator parameter would have to be used. Also, they intend the ConnectionManager to be a D-Bus service. I guess we wouldn't need that on the phone, where PhoneKit should be running all the time anyway. Most optional interfaces of the Connection (Avatars, Presence, etc.) of the spec don't apply here. Maybe some of them (Forwarding, Privacy) could be adapted to the corresponding GSM functionality, though. PhoneKit would have to keep a VoiceCall Channel object for a running call. Again, maybe some of the optional interfaces (DTMF, Group, Transfer) could be used to add dtmf tone generation, call forwarding or conference call functionality later. SMS sending/receiving could be wrapped by the Channel.Type.Text interface. I expect that an additional interface is necessary if the sms storage selection and things like that are to be exported, too. cheers Philipp
Re: Phone functionality in GUI applications
On Wed, 2007-10-17 at 00:43 +0800, Wolfgang Spraul wrote: [...] > 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? D-bus at it's most basic is an IPC mechanism. Think CORBA, but without the bloat. The API that a d-bus interface exposes is completely independent of source language and binaries. > > We should not make it overly hard to later have OpenMoko-based phones > with toolkits other than GTK+. Having PhoneKit toolkit agnostic and allowing plugins to implement the GUI sounds like an excellent idea. There's no particular reason we didn't suggest this in the first place, except that we where attacking the problem from the current application angle. 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
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
On Tue, 2007-10-16 at 18:09 +0300, Nuutti Kotivuori wrote: > Thomas Wood wrote: [...] > > > 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. This was something that was brought up on IRC as well after I sent the e-mail, but I would prefer to keep discussions on the list. 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 started out thinking purely in terms of OpenMoko's requirements and we assumed GTK+ would be the "official" GUI toolkit. However, if there is demand for PhoneKit outside of OpenMoko, or even if OpenMoko decide to 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. > > > 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 what is in store for profiles and settings management (apart from using gconf I would imagine). PhoneKit would obviously have to interact with this at some stage but it could conceivably be handled by a plugin as well. 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
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 :) 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. cheers Philipp
Re: Phone functionality in GUI applications
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
Phone functionality in GUI applications
Hi, 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. The following is the notes and thoughts from our meeting. I haven't included all the decision details, so please do ask if anything seems odd. A diagram of our proposal is available at the following URL: <http://folks.o-hand.com/thomas/openmoko-phonekit-proposal.pdf> Current Arrangement === GUI applications use the MokoGsmdConnection gobject provided by libmokogsmd to access the phone functionality. MokoGsmdConnection is a very thin object wrapper to libgsmd. It is very incomplete and operates as one instance per process. It has no awareness of any other applications accessing gsmd, nor does it manage any events from gsmd itself apart from passing them on to the application. Proposed Arrangement PhoneKit A new phone functionality d-bus service for GUI applications. Exposes a high level d-bus api to phone commands and events. Very similar to current d-bus functionality exposed by Dialer (for example, Dial function and incoming-call event). Updates the journal on gsmd initiated events such as incoming sms or voice mail. Produces system model GUI dialogs for call handling (incoming, outgoing, in call) and manages pin entry on network registration. MokoJournal --- Manages communication history such as call logs and SMS messages. SMS messages are stored in the journal. Listens to the journal for events such as new sms. Uses e-d-s (Evolution Data Server) calendar journal component to store and retrieve data Home The current "Today" application, provides the entry point for all software. Uses MokoJournal to retrieve SMS and call information Uses PhoneKit to retrieve current operator name Dialer -- Very simple application that just displays call history from MokoJournal and presents user with a keypad. Uses PhoneKit to initiate phone calls Uses MokoJournal to retrieve call logs Contacts Displays the address book Uses e-d-s to retrieve contact information Uses MokoJournal to retrieve call history per contact Uses PhoneKit to initiate phone calls Panel Applets - Uses PhoneKit to retrieve network information such as operator name, signal strength, voicemail indication and GPRS status. Comments and suggestions welcome on any of the above. 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/
