>> Adding dbus support is *not* the hard part, that's getting calls
>> working at all (and of course all the nifty things you'd want to
>> plug in, but those are outside of the scope of the base infrastructure).
>>
> I agree that adding D-Bus support is not in itself difficult, but trying to
>
Jim McDonald <[EMAIL PROTECTED]> wrote :
hat everyone can see where this is heading.
>
> I understand and agree that making/receiving calls is the most important
> thing right now for the core team but I and no doubt most of the rest of
> the people outside of the core team can't help much there
Henryk Plötz wrote:
Don't worry too much about that right now. I don't know what the
current plan for this problem is but, given that OpenMoko already uses
dbus, I'm quite sure that it will include dbus. Going from "I have an
application that, when a call comes in, pops up a dialog and asks the
Moin,
Am Fri, 20 Jul 2007 09:20:44 +0100 schrieb Jim McDonald:
> Yep that's pretty much what I'm talking about here. But to do this
> we will need the low-level code to send us the methods/signals so
> that we can take the appropriate actions, which is the bit that I'm
> worried is not being con
Hi,
Here is my two cents worth. I also hope what i am saying here is not too
basic and is comprehensible. I program in Forth so my knowledge of C
vocabulary is not fabulous.
On Sat, 2007-07-21 at 12:28 -0400, Clayton Jones wrote:
> I like the ideas presented here, but i have some experience des
Hi everybody,
Coming late into this discussion, but if i could put my 2 cents worth
(or whatever that is in euros these days..)...
I like the ideas presented here, but i have some experience designing
& building real time & embedded systems so some points to think about:
1) The Event Router shou
Hans L wrote:
> Hey folks,
>
> Great discussion going on here. I've been putting a lot of thought
> into the issue too, so I figured I'd add my two cents.
[...]
Yep this is very similar to what I'm thinking of. Given that we're all
pretty close to what we think we need it's probably time to put
Hey folks,
Great discussion going on here. I've been putting a lot of thought into the
issue too, so I figured I'd add my two cents. Originally I tried to imagine
how all these events and notifications would go together, and I came up with
this wishlist item: http://wiki.openmoko.org/wiki/W
Giles Jones wrote:
I don't think the project will last long if there's too much snobbery about who does what.
In this case it isn't snobbery so much as ensuring that there is a
simple way to put the right functionality in the right place.
Overloading gsmd with lots of (potentially confli
Jim McDonald <[EMAIL PROTECTED]> wrote :
> which is the bit that I'm worried is
> not being considered and so this type of functionality will just not be
> possible without being a 'core' developer.
>
I don't think the project will last long if there's too much snobbery about who
does what.
Jeff Andros wrote:
ok, but here's the thing with having full plugin framework: what if
two plugins take mutually exclusive actions (I.E. one plugin has a
whitelist, it tries to answer the phone because it's the girlfriend,
but the other plugin attempts to send the call to voicemail because
yo
Henry Law wrote:
What about using a system similar to iptables? Each module only
provide function to "match" against some call info. Some "target actions"
are defined by the notification system. And rules is setup by user
so that when a call event come in, the notification system can
check the
Jim McDonald wrote:
Giles Jones wrote:
Jim McDonald <[EMAIL PROTECTED]> wrote :
This is why you send the event to the notification system and then wait for the response. The notification system would read the users rules and act appropriately.
For an incoming call if you had a rule which
On 7/19/07, Jim McDonald <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> OK, first time you mentioned Firefox, I thought you meant browser and/or
GUI stuff. But you focus on extensions/plugins :)
>
Sorry yep was thinking of the design philosophy rather than the
specifics. If I look at my
[EMAIL PROTECTED] wrote:
> OK, first time you mentioned Firefox, I thought you meant browser and/or GUI
> stuff. But you focus on extensions/plugins :)
>
Sorry yep was thinking of the design philosophy rather than the
specifics. If I look at my own install I have four of five extensions
(out o
> (Also bear in mind that incoming calls are a very simple example as
> there is not much that I can think of doing with them off-hand.
Just heard a news-item on the radio: a service where you don't get commercial
calls during dinner, implemented at the side that calls you. Messy (companies
do
Giles Jones wrote:
> Jim McDonald <[EMAIL PROTECTED]> wrote :
>
> This is why you send the event to the notification system and then wait for
> the response. The notification system would read the users rules and act
> appropriately.
>
> For an incoming call if you had a rule which says you ar
Jim McDonald <[EMAIL PROTECTED]> wrote :
> Well yes, that's really what I'm talking about. But there are also
> other things that some people may want to do with an incoming 'phone
> call that we won't think about. Perhaps send an SMS to another 'phone
> to say that a call was received? Jus
Giles Jones wrote:
> Jim McDonald <[EMAIL PROTECTED]> wrote :
>
>
>> Yep that's roughly what I'm talking about but we need the base code to
>> be set up such that it will make those calls and pay attention to the
>> results, which is the main thrust of my argument.
>>
>
> All the code sho
Jim McDonald <[EMAIL PROTECTED]> wrote :
> Yep that's roughly what I'm talking about but we need the base code to
> be set up such that it will make those calls and pay attention to the
> results, which is the main thrust of my argument.
All the code should need to do is talk to notification pr
>> 1) How would you put that
>>in an engine? Where does all the relevant info come from?
>> 2) Then build aan interface to allow an end-user to create such rules.
>> 3) And finally do something trivial with dbus,
>>commandline (or even XML...) to play the appropriate ringtone. and show
>>
Doug Jones wrote:
Take a look at EToys.
[...]
That's certainly a style of GUI that could be applied to the hooks if
required, although at current I'm more concerned about the ability for
the hooks to exist than the specifics of how they would be configured.
Cheers,
Jim.
_
Anton Afanasyev wrote:
I am not entirely sure if I'm thinking straight, but here's my take on
customizing functionality of the OpenMoko:
say, when a call comes in, the appropriate module detects that, gets
the caller ID if possible, maybe other info (such as the contact info
associated with it, i
Giles Jones wrote:
On 18 Jul 2007, at 23:57, Joe Pfeiffer wrote:
Note that dbus is already a part of openmoko.
Ah, always thought DBUS was some sort of HAL. But on close inspection
it's a bit like DCOP which is very powerful.
All that's needed is a nice interface to configure the actions
I am not entirely sure if I'm thinking straight, but here's my take on
customizing functionality of the OpenMoko:
say, when a call comes in, the appropriate module detects that, gets
the caller ID if possible, maybe other info (such as the contact info
associated with it, if any), and then theres
Jim McDonald wrote:
[This may have been better to post to the development list but as people
are talking about it here I'll start here]
Hi,
A number of people have been talking about the cool things that they
would like their 'phone to do but after spending some time looking at
the informa
On 7/18/07, Kero van Gelder <[EMAIL PROTECTED]> wrote:
Now, depending on circumstances, your Social Other, a parent or child who
needs
to see a doctor, your bank/mortgage or person that arranges something big
for
you may need to drag you out of your meeting. Some or most meetings.
Probably
not
On 18 Jul 2007, at 23:57, Joe Pfeiffer wrote:
Note that dbus is already a part of openmoko.
Ah, always thought DBUS was some sort of HAL. But on close inspection
it's a bit like DCOP which is very powerful.
All that's needed is a nice interface to configure the actions then.
___
>>If the monolithic approach is out then some sort of modular approach is
>> required. The most obvious example out there today is Firefox, which
>> comes in a relatively simple base configuration but provides any number of
>> hooks to allow people to write their own extensions on top of th
Giles Jones writes:
>
>If it's just notifications then you can have a notification daemon
>which any application can register it's events with. The preferences
>for this would allow something like Play Sound, Display Message,
>Flash backlight, Vibrate, Power off, Run script, Run command or do
On 18 Jul 2007, at 23:21, Jim McDonald wrote:
To clarify, I'm thinking not of getting in the way of the basics of
things like gsmd, which should handle the fact that there is an
incoming call and also pick up the caller ID if present, but what
openmoko does as a result of this information
On 18 Jul 2007, at 23:03, Jim McDonald wrote:
If the monolithic approach is out then some sort of modular
approach is required. The most obvious example out there today is
Firefox, which comes in a relatively simple base configuration but
provides any number of hooks to allow people
sure we couldn't do it directly like that. But couldn't we fake it by have
the phone answer the call immediately after it detects it, playing the sound
file over the radio (instead of sending microphone input), and act like it's
still ringing?
On 7/18/07, Daniel Robinson <[EMAIL PROTECTED]> wrot
Daniel Robinson wrote:
> I don't know how much of the at signaling is available at the data
> terminal. What is the signaling for sending caller ID to a cellular
> phone? For example, on POTS, the digits are signaled with a Bell 103
> modem between the first and second ring.
>
> Someone said som
I don't know how much of the at signaling is available at the data
terminal. What is the signaling for sending caller ID to a cellular phone?
For example, on POTS, the digits are signaled with a Bell 103 modem between
the first and second ring.
Someone said something about having the ringback to
[This may have been better to post to the development list but as people
are talking about it here I'll start here]
Hi,
A number of people have been talking about the cool things that they
would like their 'phone to do but after spending some time looking at
the information available so far I d
36 matches
Mail list logo
