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
n 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 open
t 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 anticip
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
smd 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
&
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
ad, 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
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
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&#x
ow 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 handl
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
22 matches
Mail list logo
