Michael 'Mickey' Lauer wrote:
Hi guys,
as you may have already noticed, Openmoko Inc. has been accepted
as a mentoring organization for the Google Summer of Code 2008.
Please note that the list of ideas found on the wiki page is by no means
comprehensive, it's rather a bunch of things we
Hello.
On Mon, 2008-03-24 at 19:02, Niluge KiWi wrote:
I'm interested in the accelerometers features [1]: Recognising gestures
is a really important part of the interface between the user and the
phone.
Seems this ideas gets the interest of a lot people. Nice. :)
But as we only can choice
On Tue, Mar 25, 2008 at 4:36 PM, Stefan Schmidt [EMAIL PROTECTED] wrote:
Hello.
On Mon, 2008-03-24 at 19:02, Niluge KiWi wrote:
I'm interested in the accelerometers features [1]: Recognising gestures
is a really important part of the interface between the user and the
phone.
To: community@lists.openmoko.org
Subject: Re: GSoC 2008
Hello.
On Mon, 2008-03-24 at 19:02, Niluge KiWi wrote:
I'm interested in the accelerometers features [1]: Recognising
gestures
is a really important part of the interface between the user and the
phone.
Seems this ideas gets
Niluge KiWi wrote:
With the two accelerometers in the FreeRunner, I think we can recognise
lots of gestures, not only simple ones like a click (which is already
recognised by the accelerometers used in the FreeRunner). The main
difficulty is probably to extract the useful data from the gestures
On Mon, 24 Mar 2008 19:02:34 +0100
Niluge KiWi [EMAIL PROTECTED] wrote:
Hi,
I'm a student in the french engineer school ENSIMAG, and I would like
to work for OpenMoko during the Google Summer of Code.
I'm interested in the accelerometers features [1]: Recognising
gestures is a really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Somebody in the thread at some point said:
Niluge KiWi wrote:
With the two accelerometers in the FreeRunner, I think we can recognise
lots of gestures, not only simple ones like a click (which is already
recognised by the accelerometers used in
Am Di 25. März 2008 schrieb Andy Green:
[...]
It means that a perfect solution is predicated around
- 16 bit integer arithmetic -- ha no float is too easy
- per-sample short processing rather than large batching
- multiply is expensive (but hey shifting is cheap :-) )
Divide?
Hey, for
Somebody in the thread at some point said:
The raw accelerometer data is predicated around byte data for X Y Z per
sample per motion sensor.
Ultimately the gesture recognition action is about eating 200 3-byte
packets of data a second and issuing only one or two bytes per second
about any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Somebody in the thread at some point said:
Somebody in the thread at some point said:
The raw accelerometer data is predicated around byte data for X Y Z per
sample per motion sensor.
Ultimately the gesture recognition action is about eating 200
Seems that hardware is quite likely to become available before summer.
(This is only my opinion and I'm not related to Openmoko otherwise
than being listed in community and kernel mailing lists).
___
Openmoko community mailing list
Hello.
On Sun, 2008-03-23 at 06:24, ewanm89 wrote:
I'm heavily interested in apply to get the ad-hoc communication going
for GSoC 2008.
Great. We had a try last year, but it failed. Nice to see it going
again.
I just wondered what is the situation on getting the
hardware?
What exactly do
On Sun, 23 Mar 2008 17:39:29 -0300
Stefan Schmidt [EMAIL PROTECTED] wrote:
What exactly do you mean here? If Freerunner will be available at the
time, or if Openmoko provide students the hardware?
Well obviously the hardware costs money that I don't expect to just
come from nowhere, I was more
ewanm89 wrote:
On Sun, 23 Mar 2008 17:39:29 -0300
Stefan Schmidt [EMAIL PROTECTED] wrote:
What exactly do you mean here? If Freerunner will be available at the
time, or if Openmoko provide students the hardware?
Well obviously the hardware costs money that I don't expect to just
come from
As I am not an owner of a Neo myself, I do not if this has already been
done.
What about making it possible to listen music, and as a call comes in(and
you answer it), make the music pause. I know this is a small thing, though I
don't know how easy it is to implement, but I think it would be quite
I was thinking to a port of AirStrike (http://icculus.org/airstrike/) but
there is the need of SDL-image port
I am waiting for FreeRunner :)
___
OpenMoko community mailing list
community@lists.openmoko.org
Sqlite port would be nice thing to have. (With C/C++/Python bindings, of course)
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
already there, thanks to openembedded:
http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/ipk/armv4t/sqlite3_3.5.6-r0_armv4t.ipk
On Tue, 2008-03-11 at 22:52 +0200, Ilja O. wrote:
Sqlite port would be nice thing to have. (With C/C++/Python bindings, of
course)
Hello.
In my opinion, there are some highly usable project proposals in wish
list, that could be done by student (like me, heh-heh-heh...) during
summer.
First things first: platform should provide more than one GUI binding
solutions.
In my opinion binding framework porting priority is
For middleware, it looks like all that's really needed is an OM
version of Cocoa's NSNotificationCenter. IMHO I think it's a great
place to start -- just a filtered event channel with a C-callable API
for publishing/listening for events. I'd prefer a design that's
simple reliable for small data
Lally Singh wrote:
For middleware, it looks like all that's really needed is an OM
version of Cocoa's NSNotificationCenter. IMHO I think it's a great
place to start -- just a filtered event channel with a C-callable API
for publishing/listening for events. I'd prefer a design that's
simple
Cool, can we use it directly or need a port?
On Sun, Mar 9, 2008 at 4:03 PM, Joachim Steiger [EMAIL PROTECTED] wrote:
Lally Singh wrote:
For middleware, it looks like all that's really needed is an OM
version of Cocoa's NSNotificationCenter. IMHO I think it's a great
place to start --
22 matches
Mail list logo
