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
-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 neede
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: tr
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 improbab
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 ;
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 po
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 ot
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 s
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 simil
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 servi
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 funct
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
> whiteboar
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 witho
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
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
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 co
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
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
>
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
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
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 fu
21 matches
Mail list logo
