Tommi Virtanen wrote:
On Wed, Oct 10, 2007 at 08:57:22AM +0200, Openmoko wrote:
So far I've only implemented the very basics, e.g. to write a c three
pushed on one butten is required. I've also plans for implementing a
dictionary, e.g. T-9 or an alternative: the most common words appear
Giles Jones wrote:
On 15 Sep 2007, at 22:53, J F wrote:
What I would like to see is ALL programs having a way of getting at
their
data from a scripting language. I don't know if it makes sense to
have some
guidelines for developers to make it easier for this information to
be got
at.
John Locke wrote:
Jim McDonald wrote:
Possibly more interesting would be for the calendar app to look ahead
at your position-to-be and provide you with details (or even alerts)
of what (for example) the weather is likely to be when you get to
where you are going. Knowing
Jeff Andros wrote:
Last night, while I was looking at the monsoon blowing just outside
the heat-island... in my open-top jeep... I had an application idea:
GPS based weather feeds.
on a schedule/when you move into a new area, the phone will go out to
a server and retrieve the weather
Harald Welte wrote:
[...]
Which part exactly are you missing? That there are no docs now? Well,
there is no GTA02 hardware being shipped now either! And if the
community rather wants us to finish the documentation first, and then
write the driver: Please let us know. Do you really prefer
hank williams wrote:
Oops. As usual I hit reply to and it went to casey personally
Its broken.
Just so that the 'silent majority' don't lose out on this one, I would
like to point out that there are approximately 1,500 people subscribed
to this list. Can we assume that unless we hear from
Rod Whitby wrote:
Visti Andresen wrote:
Sébastien Lorquet [EMAIL PROTECTED] wrote:
(This is a suite to laforge's message on gsmd-devel)
I'm a little disappointed about laforge's message :( Targetting geeks only
will never help to make OpenMoko known.
They are planning to
Sean Moss-Pultz wrote:
I don't see our statements as conflicting. Harald is our lead system
level architect. His job is to focus on his task at hand and deliver a
stable, high performance system. He's trying to give the geeks what
they want first.
Which is great, the concern was around
Kero van Gelder wrote:
[...]
I'll think about the extension concept a bit more. The fact that you
chose
a scenario to modify a phone number is interesting. How about calling
a person from a Contact? and then choosing VoIP or GSM by those
extensions?
(specifically, I do not think gsmd is the
Kero van Gelder wrote:
Something I thought of, the application (or whatever) that might want to
register an extension need not be started yet. After all, DBus is capable
of starting applications (and I'm sure Contacts, Agenda and a few more
will be in the nearby future).
Yep I'm planning
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
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
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
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
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
[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
[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
gsmd, it
makes more sense for them to be external modules that can be chained
together in a clean fashion without requiring direct access to something
as sensitive as gsmd. At least, that's my take on it.
--Dan
Cheers,
Jim.
On 7/18/07, *Jim McDonald* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED
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.
Tim Newsom wrote:
The best part is that if you don't want it, you don't use it. And
those that do want it, can use it and its all completley transparent
to the applications.
But not at all transparent to the end user. Again assuming that there
is some sort of key caching going on, what is
Tim Newsom wrote:
[Encryption options]
Yep I understand that there are lots of possibilities and options, I
just think that if something ships by default it should provide end
users with a very simple dialog that is basically an on/off switch for
'protection of personal data' (or something
Jonathon Suggs wrote:
One of the biggest mantra's I hear coming from the FOSS camp is choice
and so keeping with the whole practice what you preach ideal, I think
the level of encryption should be a user configurable preference.
I'd caveat that with comment that one of the biggest bugbears
Joe Pfeiffer wrote:
[Encrypting data]
We certainly want a global scheme -- but I think we do want a
per-data-item granularity. I've certainly got things on my phone
whose protection I don't care about (shopping lists) and other things
that have legal implications (notes on how various
Clare Johnstone wrote:
On 3/20/07, Jim McDonald [EMAIL PROTECTED] wrote:
continually asking the user to decide which data is to be encrypted and
which not.
There is the concept of folders which could be used :)
clare
True, but that's just another choice to be made when storing the data
Joel Newkirk wrote:
Tobias Gruetzmacher wrote:
What I'm proposing is a user-friendly encryption scheme of the data the
user stores in his phone, so any illegitimate user will not be able to
get personal data about the owner of the phone.
I'd like a good gestural
Marcel Holtmann wrote:
[...]
Okay so there has been a fair amount of discussion here but I think
we've veered off track a bit. To try to re-phrase my thoughts:
- Current DBus object paths are application-centric (this is by
choice of the application)
- Without a well-known set of paths
Marcel Holtmann wrote:
[...]
the question is still why. We have EDS. So no reason to invent another
interface for the same purpose. Don't try to over-complicate things.
So this is an argument against abstraction, which I understand but
disagree with. It comes back to the two choices that
29 matches
Mail list logo
