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
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
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, so
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
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
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
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
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
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.
By
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
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
an
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
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? Just an
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 are busy
(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
[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 of
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 own
[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
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
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
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]
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
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
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
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 the base
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.
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
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
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,
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.
30 matches
Mail list logo
