Re: Custom case designs...

[adrian cockcroft]

I've been designing cases for the homebrew mobile club, posting the design
files on the wiki and producing them on a 3D printer.

http://www.hbmobile.org/wiki/index.php?title=Portrait_oriented_case

I can get these individually made for $40 or so each at
http://www.techshop.ws
a custom case for the FIC 1973 hardware would be smaller and cost less (its
$10/cubic inch).

The CAD software I used didn't really handle embossing text into the case
very easily, and I think its better to use a laser cutter/etcher to write
vector and raster patterns into the surface afterwards. The laser is 1200
dpi, and the 3D printer is more like 100dpi resolution. You can write
anything you want onto just about anything solid that doesn't release toxic
fumes with a 45W CO2 laser. (e.g. you can't write on foam and PVC releases
Chlorine :-) It will etch metal, but can't cut through it.

If FIC release mechanical design spec's for the internal dimensions it would
be easier to wrap a case around it.

Adrian

On 7/3/07, Hans van der Merwe <[EMAIL PROTECTED]> wrote:



On Tue, 2007-07-03 at 16:52 +0200, ramsesoriginal wrote:
> First they wil lthink that it's a rip-off of the iPod customisation.
> Then they will think that it's not useful, not functional, only
> thrown-away money.
> Then they will see how cool it looks at their buddy's neo, and will
> buy one for themselves ;)
>
> On 7/3/07, Tim Newsom <[EMAIL PROTECTED]> wrote:
> I have been thinking a little more about this and I struck
> upon an
> idea... What if you could buy a custom case with a custom
> message on
> it.
>
> I am not talking about painted messages but letters and shapes
> cast into
> the plastic shell.
> Raised, sunk, custom fonts etc.
>
> Naturally we can't just replicate the exact neo1973 shell
> without
> permission, but maybe something like it and removing the FIC
> logo
> (unless we get permission to use it) or the like.
>
> This is more of a vanity thing than a functional thing.. But
> what do
> people think of it?
> --Tim
>

Some of the guys here at work (actually most of them) seem to hate the
rounded sides/corners of the phone - any plans maybe on making it
rectangular?


ps. Im an engineer - I dont care what it looks like :)





E-Mail disclaimer:
http://www.sunspace.co.za/emaildisclaimer.htm

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Web-based GUI technology for OpenMoko

[adrian cockcroft]

On 6/11/07, Tim Newsom <[EMAIL PROTECTED]> wrote:


Interesting... Web services... I wonder if that makes it possible to
export the web service off the phone
To a program running somewhere else... Or if its limited to some local
channel.




I think these services are available within the Safari context on the
iPhone, there is no talk of  having them be exportable directly. However
with a javascript application you could post information back to a central
web service to do things like location tracking.

The public reaction seems to be negative overall, people wanted to be able
to port their existing J2ME based apps to the iPhone. There isn't an
existing base of mobile apps written in AJAX/Safari because there wasn't a
platform until now.

I think an interesting focus for the OpenMoko community is to figure out how
to get a full AJAX capable browser (FireFox?) to run well enough on the
device, and to build similar or identical web service interfaces to the
phone functions, so that new AJAX apps written for the iPhone work on
OpenMoko as well.

Adrian

And, anyway.. That only means you would have to wrap it in another,

fully exportable, web service for such integration.

--Tim
On Mon, 11 Jun 2007 20:51, Matthew S. Hamrick wrote:
> Wow. once again Apple justifies our lead.
>
> On Jun 11, 2007, at 5:54 PM, adrian cockcroft wrote:
>
>> Also, Apple's announcement today about iPhone development using AJAX
>> and exposing internal phone functions as web services to the iPhone's
>> safari browser is tipping everything in the same direction.
>>
>> Cheers Adrian
>>
>> On 6/11/07, Matthew S. Hamrick <[EMAIL PROTECTED]> wrote:
>>
>>> Yeah... we're thinking that we were going to totally separate the
>>> model and domain processing from the view/controller part of the
>>> application. That way we could have a couple different HTML
>>> interfaces as well as a SVG/ECMAScript interface. I'm not terribly
>>> familiar with XAML or XUL, but I understand that most (if not all) of
>>> the Firefox / Mozilla / Navigator interface was written in XUL.
>>>
>>> This is one of the benefits to this approach, IMHO. Separating the
>>> interface allows us to experiment with a number of different
>>> interface technologies. And the only thing the experimenters need to
>>> know is the semantics and syntax of the XML interface.
>>>
>>> -Cheers!
>>> -Matt H.
>>>
>>> On Jun 11, 2007, at 9:18 AM, Tim Newsom wrote:
>>>
>>>>  If we are heading in the direction of web interfaces, I think we
>>>>  should look at XAML or XUL or something similar.From what I can
>>>>  tell, they will be adding silverlight support to mono, so using
>>>>  XAML will be possible.This also separates the code for
>>>>  functionality from the interface and can allow skinning of the
>>>>  entire application interface set.
>>>>
>>>>  This will abstract you from every widget set.Each action could be
>>>>  exported and called from the UI without needing to worry about all
>>>>  that.
>>>>
>>>>  At least, that's my take on it currently.
>>>>
>>>>  --Tim
>>>>  On Mon, 11 Jun 2007 8:44, Florent THIERY wrote:
>>>>>  Here's a little look-and-feel example that could be done with an
>>>>>  opensource AJAX framework [javascript required]:
>>>>>
>>>>>  http://demo.qooxdoo.org/current/showcase
>>>>>
>>>>>  This may allow easier separation between apps and GUIs. Of course,
as
>>>>>  usual we have no idea how well such an app would perform (little &
>>>>>  gratuitous prediction: very bad), benchmarking is needed but ...
who
>>>>>  knows ?
>>>>>
>>>>>  This is going along with the ongoings gdk webkit port and gsmd
>>>>>  XmlHttpRequest interface (was topic: embedded webserver).
>>>>>
>>>>>  What do you think ? Is it REALLY unrealistic ? Could anybody try
the
>>>>>  url on it's Nokia N770 (lots of happy owners here, right?) and
rough
>>>>>  feedback the responsiveness ?
>>>>>
>>>>>  Cheers
>>>>>
>>>>>  Florent

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Web-based GUI technology for OpenMoko

[adrian cockcroft]

Also, Apple's announcement today about iPhone development using AJAX and
exposing internal phone functions as web services to the iPhone's safari
browser is tipping everything in the same direction.

Cheers Adrian

On 6/11/07, Matthew S. Hamrick <[EMAIL PROTECTED]> wrote:


Yeah... we're thinking that we were going to totally separate the
model and domain processing from the view/controller part of the
application. That way we could have a couple different HTML
interfaces as well as a SVG/ECMAScript interface. I'm not terribly
familiar with XAML or XUL, but I understand that most (if not all) of
the Firefox / Mozilla / Navigator interface was written in XUL.

This is one of the benefits to this approach, IMHO. Separating the
interface allows us to experiment with a number of different
interface technologies. And the only thing the experimenters need to
know is the semantics and syntax of the XML interface.

-Cheers!
-Matt H.

On Jun 11, 2007, at 9:18 AM, Tim Newsom wrote:

> If we are heading in the direction of web interfaces, I think we
> should look at XAML or XUL or something similar.  From what I can
> tell, they will be adding silverlight support to mono, so using
> XAML will be possible.  This also separates the code for
> functionality from the interface and can allow skinning of the
> entire application interface set.
>
> This will abstract you from every widget set.  Each action could be
> exported and called from the UI without needing to worry about all
> that.
>
> At least, that's my take on it currently.
>
> --Tim
> On Mon, 11 Jun 2007 8:44, Florent THIERY wrote:
>> Here's a little look-and-feel example that could be done with an
>> opensource AJAX framework [javascript required]:
>>
>> http://demo.qooxdoo.org/current/showcase
>>
>> This may allow easier separation between apps and GUIs. Of course, as
>> usual we have no idea how well such an app would perform (little &
>> gratuitous prediction: very bad), benchmarking is needed but ... who
>> knows ?
>>
>> This is going along with the ongoings gdk webkit port and gsmd
>> XmlHttpRequest interface (was topic: embedded webserver).
>>
>> What do you think ? Is it REALLY unrealistic ? Could anybody try the
>> url on it's Nokia N770 (lots of happy owners here, right?) and rough
>> feedback the responsiveness ?
>>
>> Cheers
>>
>> Florent
>>
>
> ___
> OpenMoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [SVHMPC] concept phone with only a touchscreen for UI

[adrian cockcroft]

Thanks for the link to Rapidobject. Looks like a nice idea. They
charge 1.9euro's per cubic centimeter (31 euro's per cubic inch),
while
techshop.ws charges $10 per cubic inch for 3D printing (plus membership fee
that gets access to lots more tools). They also seem to be in Germany rather
than California.

My 3D models for homebrew phone case designs are all being open sourced, so
when I get a stable design figured out and posted to the hbmobile.org wiki
I'll upload it to Rapidobject for Europeans to use as a source, and I'll
probably make parts at techshop and sell them on eBay as well.

However Laser cutting is *much* cheaper and faster if all we want is a 2D
template cut in thin plastic. The resulting part can also be transparent,
and 3D printer output is opaque.

Cheers Adrian

On 6/6/07, Sven Neuhaus <[EMAIL PROTECTED]> wrote:


adrian cockcroft wrote:
> Or invert the problem, instead of buttons, make holes. The touch
> sensitive surface is exposed through the holes, and you can feel which
> hole you are poking at. A relatively stiff transparent cover with holes
> in is easy to make ( techshop.ws <http://techshop.ws> laser cutter :-)
> and clip onto the face of the phone.

You could just whip one up in a CAD program and make it available at a
3D-printer store like http://www.rapidobject.com/ for everyone to order.

-Sven

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [SVHMPC] concept phone with only a touchscreen for UI

[adrian cockcroft]

Or invert the problem, instead of buttons, make holes. The touch sensitive
surface is exposed through the holes, and you can feel which hole you are
poking at. A relatively stiff transparent cover with holes in is easy to
make (techshop.ws laser cutter :-) and clip onto the face of the phone.

Adrian

On 6/5/07, Joe Friedrichsen <[EMAIL PROTECTED]> wrote:


On 6/5/07, Bradley Hook <[EMAIL PROTECTED]> wrote:
> Steven Milburn wrote:
> > Personally, I'd like to see a touchscreen with some type of ability to
> > raise
> > dimples at any point under software control.  Kind of like a braille
reader
> > on acid.  If only such a thing existed. (does it?)
>
> One word: expensive.
> Refreshable Braille displays do exist, and even the cheapest functional
> ones make the current cost of the Neo look like pocket change.
> Incorporating this sort of technology into the Neo would not only be
> expensive, but the mechanics of these things require a lot of
> maintenance, not a fun thing to have in a phone.

While refreshable Braille on a touch screen would be the final goal
for accessibility, I think the OP was talking about mimicking buttons,
which I imagine wouldn't need to be nearly as precise. One 'bump' per
finger-space requires a much smaller resolution than six bumps per
finger-space (as is used in Braille). Mechanical movement is still the
challenge, but reducing the actuators by a factor of 6 is a big help.

Joe

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Anti Iphone (Was Re: Some light ahead...)

[adrian cockcroft]

The Freescale i.MX31 is a 534MHz ARM CPU with 3D graphics, and the
full hardware specs are available for free download (hundreds of
pages...). The homebrew mobile phone group are working on an open
hardware module based on it, and we will port OpenMoko. This is taking
place in "homebrew time" :-)

It make take a while to get OpenGL ES on open linux based phones, but
I think that is the future goal to aim at.

Adrian

On 5/4/07, Arthur Marsh <[EMAIL PROTECTED]> wrote:

nitro wrote, on 2007-05-04 17:36:

> http://www.imgtec.com/PowerVR/products/Video/MVDA2/index.asp
>
> The bad point of this kind of chip are the limited amount of supported
> codecs, so this kind below would be better ; also because it's OpenGL|ES
> 2.0 compatible ;)
>
> "[...] Video processing for free, with the real-time programmable
> architecture providing extensive accelerated functions support for
> multi-standard video decode and encode." -- ak vertex&fragment shaders
> that seems to be extended in this chip to access other kind of resources
> (maybe a kind of fast texture wrapper around raw video blocks ?).
>
> http://www.imgtec.com/PowerVR/products/Graphics/SGX/index.asp?Page=2
>
> Now I think the main problem would be the price of a chip like that.
>
> Why not use an FPGA with a bunch of arithmetic operations widely used in
> audio / video compression (eg. DCT) and write a media library that
> forward most of the job on the FPGA. I don't know if there is more
> complete solutions available, but the basic idea is here :
>
> http://www.opencores.org/projects.cgi/web/video_systems/overview
>
>
> (well I don't have the whole mailing list archived here, so it has maybe
> been already mentioned before)

That sounds like a new project for the Open-Graphics Project:
http://www.opengraphics.org and mailing list available from
news.gmane.org as the newsgroup gmane.comp.graphics.opengraphics

Arthur.


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Anti Iphone (Was Re: Some light ahead...)

[adrian cockcroft]

Slingbox currently can stream your home video system (including TiVo)
to a computer or high speed (3G/WiFi) phone. It works well on laptops,
and I've seen it demonstrated on phones and it looks quite good. This
implies that its at least technically feasible to stream MythTV to a
Neo.

Adrian

On 4/30/07, Tim Newsom <[EMAIL PROTECTED]> wrote:


On Mon, 30 Apr 2007 11:56, Steven ** wrote:
/snip
> I don't understand.  Of course I'll want MythTV on my phone (iPhone or
> Neo).  I'm not going to buy Apple TV because I already have MythTV
> setup and doing everything I want and more.  I intend, at the very
> least, to use my Neo as a remote control for my Myth Box.  I'd also
> like to get a simple Myth frontend so that I stream video to the Neo.
> That will be harder, but awesome.
>
> -Steven

Can you imagine... Think of you tube but with channels of shared tv
broadcast to phones... Maybe like public tv but where users or
individuals could select the content... Does that exist?  I am not
talking rebroadcasting (copyright issues) but new content owned by
individuals who would like to share it and give the rights for that.

--Tim

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: CrossPlatform Programming

[adrian cockcroft]

There is a comparison of GTK+ and QT for mobile applications at this URL

http://www.hbmobile.org/wiki/index.php?title=GUI_Frameworks

Adrian

On 4/15/07, Joe Pfeiffer <[EMAIL PROTECTED]> wrote:

xnike writes:
>I just want to know is it good idea to use qt4 (not Qtopia) for
>OpenMoko's apps?

Probably not, unless you've got a compelling reason to use it.
Openmoko itself is GTK-based, so a non-GTK application will require
lots of extra libraries on a platform that really doesn't have much
room for them.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Google maps & caching

[adrian cockcroft]

When I use filez to look at the stuff stored on my PalmOS Treo 650
there is a fairly obvious google maps cache file. So I'm pretty sure
they do cache tiles for performance, the point is that we cannot
decode or use that tile cache for any other purpose.

Adrian

On 4/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Hi All,

I've read through several threads on this list, and others, which
discuss the use of Google Maps for mobiles. It has been mentioned
several times that Google doesn't allow map tiles to be cached. I've
read through the Google Maps API "Terms of Use" and I can't seem to find
any mention of caching being prohibited. Could someone please point me
to the relevant section please?

I find it a little odd that Google doesn't allow caching of map tiles as
they are quite large and I can imagine Google's server & bandwidth costs
are huge if every tile is fetched directly without going through a
caching http proxy.

My train of thought is going along the lines of running squid or similar
on the actual phone...


Cheers,

Tom

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Multi-Touch

[adrian cockcroft]

Two more thoughts...

If you hold down one finger and tap the other one, the mouse pops over
and back again. This could be a way to set a bounding box or turn on
the mode.

We may be able to set the sensitivity and sampling rate much higher
than normal to support a more advanced algorithm.

To test this, we could capture and share some raw (time,x,y) event
streams from a touch screen, and try processing them offline. Then we
don't need actual hardware (a spreadsheet is may even be good enough)
to figure out algorithms.

Adrian

On 4/3/07, mathew davis <[EMAIL PROTECTED]> wrote:




On 4/3/07, adrian cockcroft <[EMAIL PROTECTED]> wrote:
> This is key:- "Pressure has almost no effect on a single touch, but
> not so on a double touch. The relative pressures will cause a
> significant skewing effect towards the harder touch. You can easily
> move the pointer along the line between your two fingers by changing
> the relative pressure."


> So we will not see clearly defined bounding box limits. The point will
> skate around within the limits depending on relative pressure.



So I guess we need someone with a device to test this and see how much
pressure actually affects the neo touch screen.  With that information I
think we could see how easy it would be to get an average bounding box
approximation..

> The first finger will set a clear start point, the second finger will
> make that point shoot off towards it, but it will not go all the way
> to the second touch. The effect should be to oscillate along the line
> between the two end points, and it wont return to the position of the
> first touch.
>
> If we capture a clear single touch, and an average position of
> oscillation, then we can take the average oscillation to be the center
> of the bounding box, and project an estimate of the opposite corner
> where the second touch should be. With the right filtering and
> limiting algorithm it should be possible to get the effect we want. If
> we can give visual feedback on the screen showing the touch points and
> bounding box it may help the user control the input better.


Ok so what if this feature was disabled by default.  Since enabling it might
slow some functionality.  When the user enables the feature he/she will have
to go through a config which does a calibration.  The user runs through
several scenarios where the program can gather the relative pressure
difference in known circumstance with the desired result known as well.  It
could then store that information in a database based on which user is using
it, if there are multi users, if not just store it in a config file.

> Challenges: In comparison with a true dual touch input device, its
> going to react more slowly as the algorithm will need to gather more
> data to decide where the pointer should be. Some of the faster moving
> single touch gestures may be hard to distinguish from multi touch.
>
> Adrian


I agree, but it would still be a nice feature to have and I could deal with
a little lag for added feature especially if I could enable it or disable
it.  With the single touch fast gestures we could set that up inside of the
calibration also.  That way if it thinks it's multi touch it compares it
with it's database which links it to the single touch fast gesture instead.
It would be slow but you could disable the multi touch option and then
single gestures would be fast again.  Or we could have the multi touch be
enabled in certain programs like web browsing or picture viewing, and
disabled for the rest.  But I think a simple button in the header or footer
should work alright.  You could have it turn green when active and red when
deactivated.



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Multi-Touch

[adrian cockcroft]

This is key:- "Pressure has almost no effect on a single touch, but
not so on a double touch. The relative pressures will cause a
significant skewing effect towards the harder touch. You can easily
move the pointer along the line between your two fingers by changing
the relative pressure."

Tapping two fingers on and off on my Mac laptop (old G4 model) I can
see behavior that matches this, although the pointer algorithm it uses
is trying to figure out a single point.

So we will not see clearly defined bounding box limits. The point will
skate around within the limits depending on relative pressure.

The first finger will set a clear start point, the second finger will
make that point shoot off towards it, but it will not go all the way
to the second touch. The effect should be to oscillate along the line
between the two end points, and it wont return to the position of the
first touch.

If we capture a clear single touch, and an average position of
oscillation, then we can take the average oscillation to be the center
of the bounding box, and project an estimate of the opposite corner
where the second touch should be. With the right filtering and
limiting algorithm it should be possible to get the effect we want. If
we can give visual feedback on the screen showing the touch points and
bounding box it may help the user control the input better.

Challenges: In comparison with a true dual touch input device, its
going to react more slowly as the algorithm will need to gather more
data to decide where the pointer should be. Some of the faster moving
single touch gestures may be hard to distinguish from multi touch.

Adrian



On 4/3/07, Florent THIERY <[EMAIL PROTECTED]> wrote:

>With that being said I have been thinking about
> multi-touch lately and after some things on the wiki page
> http://wiki.openmoko.org/wiki/UI_Improvements I noticed
> that is mentioned the zoom feature of the iphone.

as an example. The aim of the question is to discover how a monotouch
screen behaves when you try to use it as multi touch: is it
determinist, or erratical?

If somebody could try reproducing various "strange" usages of the
screen and report any deterministic/detectable behaviour, we might
find ourselves additional input methods based on "guess hacks".

For instance, i think we can use cursor jumps as inputs; example:

P**+
* 2 *
**
*  1*
- **N
Zoom +

P **+
*  1 *
* *
*2   *
- **N
Next page/item

It would be some timing-based detection, like non-linear handgesture
recognition, done with 1 or 2 fingers.

We have to:
1- experiment the touchscreen with all imaginable gestures (ex: 2
finger sliding, ...)
2- select the interesting behaviours
3- evaluate their determinism, eventually low level hacks on the kernel module
4- integrate them into openmoko finger-based controls

> So my question now is do we have access to the bounding box?  If we can get
> at the coordinates of the bounding box can we not figure out if the bounding
> box is shrinking or growing?

Yes, that is an open question :)

> Also if we have
> access to the bounding box we could with some practice figure out when users
> are trying to rotate an image.

Indeed: if the "bounding box" is accurate, what if:
- you narrow the 2 fingers? <- zoom
- rotate the box? < rotation / linear map rotation
- 2 parallel fingers (horizontal) sliding down = flat bounding box
(almost a line) = scrolling down

... But, i'm not sure i understood what a bouncing box is: if all of
this was true, then the touchscreen would report 2 points / an area...

It would be great if people having access to hardware could try doing
some detailed testing / reporting. But, it can wait until the next
shipping phase is over :)

> the
> high resolution of the neo this should help a great deal.

Well, even with high resolution, our eyes don't have better zooming :)
Especially on mobility situation...

>.  You press the zoom button then click an area to enlarge.  Just
> curious how difficult would this be?

Well, it's quite easily doable if the webbrowser / image displayer
implements zooming !

> looking at the iphone and it doesn't seem to be very multi touch but as it
> has not come out I could be wrong.  It seems to only be able to accept 2
> simultaneous inputs.

Hey, that's just what's needed :) How many free space do you have on
such a screen?

Ciao

Florent

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: VoIP call transfer?

[adrian cockcroft]

On 4/2/07, Paul McMillan <[EMAIL PROTECTED]> wrote:


It's nice to have rational conversation and argument about this, rather than
the great amounts of handwringing which sometimes constitute the bulk of
these discussions...


Agreed :-)



I agree... there's very little reason for us to cache the skype password.
But if we're talking about an integrated function-library type application
rather than running the full-blown skype desktop ap in the background, these
needs may be different. I wouldn't want to have to put in my skype password
everytime I power cycled my device or reset it.


This doesn't seem to be a problem, as Skype stores something on disk
(key or encrypted password, I'm not sure), since I can restart skype
and reboot my laptop without needing to re-enter the password. Enter
the password once after installation. This is settable, so if you want
to keep skype use private, you can enter the password each time.
Either way, the Neo shouldn't store a copy of the password.



> I'm not sure that our only goal is "total integration". If I want to
> run Skype on my phone, I may want to use the standard Skype UI. A
> plugin could do addressbook integration as it does on the desktop.

We're talking about a limited resource device. Running the Skype desktop
application all the time in the background is not the most optimal solution
if a more streamlined one could be made available. In addition, a device
like the NEO is going to need fairly specific network activity profiles...
For instance, we probably want the user to be able to send and receive text
messages via GPRS, but we don't want to generate much traffic over that type
of link otherwise, and certainly can't accept voice calls. We don't want the
device to act as a proxy (probably ever, due to battery life concerns). When
it's connected via a broadband connection, we still want low-resource usage
where possible for power saving reasons.


I'm not sure how Skype behaves in a low bandwidth setup, it definitely
won't proxy unless it has spare bandwidth, stable IP address and a
long uptime (also a firewall can stop it), it may decide that it
doesn't have bandwidth for voice or video calls automatically, or
there may be a way to tell it that its going from Wifi to GPRS.

At the moment its all moot, as there is no ARM binary, and no
timescale to create one, however once the Neo is up and running I'll
make sure they see it and get asked the right questions. I'll also ask
about the API license, and see if they will consider changes.

Adrian

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: VoIP call transfer?

[adrian cockcroft]

On 4/2/07, Paul McMillan <[EMAIL PROTECTED]> wrote:

Adrian, thanks for an insider's viewpoint.


Likewise, thanks for this detailed response.



What you describe (a Linux/ARM gateway binary) would be an acceptable
solution for many people, since it wouldn't overly burden the device with a
full-blown Skype client, and would provide the connectivity to integrate
Skype contacts alongside sip and other voip protocol contacts. I would
probably use it myself, considering how many people I know who use Skype...


The "burden" of a skype client is not primarily in the UI, most people
would be happy to just have a way to run Skype on their phone, the
same as they run it on their desktop. Its easy to write a very simple
plugin that extracts the contact list info from Skype, so that it
could be presented in the OpenMoko PIM, and the PIM could call Skype
to start a call or chat session without even using the API, its a
command line option. What more do you want to do?



The other thing that worries me about Skype and this device is the license
for the Skype api... It's not an open source license, and it really departs
quite heavily from such ideals, to the point that many OS developers would
probably refuse to work on a project involving it because of the constraints
and requirements it places on their heads.


The Skype Java API that I have been working on is an Open Source project
https://developer.skype.com/wiki/Java_API created outside Skype and
hosted on SourceForge. Skype is helpful but doesn't contribute code to
this effort.

There are two kinds of Skype API developments, one is for embedded
devices, which license the Skype core and are a source of revenue,
hence most of the contract tries to protect this revenue stream. The
other is the Skype desktop plugin API, which is used to produce tools
that enhance or leverage Skype in some way. If you want to publish a
Skype plugin on the Skype developers web site or get it promoted in
the Extra's gallery then the license is needed, but there is nothing
to stop anyone writing code that uses the API without telling Skype
about it.


For anyone who hasn't looked at it, it can be found here:
http://www.skype.com/company/legal/terms/api.html


Yes its pretty one-sided, like many corporate legal docs.


The areas I feel are objectionable:
2.(b) Doesn't clearly define hardware device. Does an application installed
on the NEO qualify? I think it's rational to argue that no, OpenMoko is a
platform, users can install whatever they want, but an argument in court
would point to other "hardware devices" like handsets and say that the NEO
was no different, and thus subject to the additional requirements including
that all developers be part of Skype's Hardare Partner Scheme.


I agree that smartphones such as the Neo are in a grey area between
general purpose desktop platforms and special purpose embedded
devices. However an embedded device including Skype, and that has a
Skype logo on the box at the point of sale, clearly needs to have some
license agreement and Skype performs a lot of in-house device testing
to make sure that these implementations work properly. The general
purpose versions of Skype are downloaded from the web and installed by
the end user, and I think that is a clear distinction. If Skype was
bundled and advertised as part of the Neo/OpenMoko product then it
would need a license. This seems like normal commercial terms to me.


3.6 Potentially limits our ability to make the service useful... If we can't
cache the Skype password (and I'm assuming the api won't let us do that
either, I could be wrong), then we can't provide good functionality to users
who are moving in and out of internet coverage. This might be different in
the terms for an embedded oriented solution. Ideally, the user will never
have to interact with a skype-branded interface, since our goal here is
total integration.


You shouldn't ever cache the Skype password outside Skype, it uses PKI
to obtain a session key, and as long as that key is valid you don't
have to give your password. I leave Skype running for weeks on my
laptop (on/off line and several networks), and only have to sign-in
once. When I restart Skype it remembers my password internally as long
as I'm not switching between Skype accounts. This is important for
maintaining security for Skype users.

I'm not sure that our only goal is "total integration". If I want to
run Skype on my phone, I may want to use the standard Skype UI. A
plugin could do addressbook integration as it does on the desktop.



6. Places a great burden on developers. You become technically liable the
moment a new version is released. Open source developers are very wary of
even the most technical legal liability, since groups trying to kill open
source projects will often seize upon said liability and base entire court
cases around it. This also makes no provision for developer testing to make
certain the new version doesn't break their software before depl

Re: tomtom on the Neo1973

[adrian cockcroft]

I'm happy with the capabilities of Google maps, except that it doesn't
know where I am

So given java support on OpenMoko, I think there is already a fairly
generic mobile Java version of Google Maps that should just work...
However to interface to the GPS we will need a modified version. I
think there is at least one platform specific version of Google Maps
that does have GPS integration.

I'm sure we can find someone at Google who can help us figure out what
it would take to support the OpenMoko/Neo1973. I wouldn't be surprise
if there was someone who works at Google subscribed to this list :-)

Adrian

On 4/2/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:

If I remember correctly the company of smart2go was bought by Nokia
last year.
So I don't think they will support other phones but Nokias in near
future.

Regards
Karsten

On Monday 02 April 2007 11:42:51 Attila Csipa wrote:
> On Monday 02 April 2007 08:13, Hans L wrote:
> > I guess it is a question of whether the map providers are willing to
> > cooperate and divulge the details of their file format to an open source
> > project, or alternatively converting their data into some open format for
> > use with such a project.
>
> In my experience this is highly unlikely. Their first thought would be
> content protection - and on OpenMoko you (should) have none. When they
> license data to software companies, it's easier, since they have NDA-s,
> contractual obligations, etc, but they would see no incentive to open up
> their formats. The income from end users buying open format data is
> minuscule compared to the possible damages from pirated data and/or lost
> bulk contracts from their point of view. And to reiterate a personal
> opinion about commercial software on OM - please do not change or put a
> minute of effort in OpenMoko to make commercial software run easier than
> any other software (unless you get a substantial donation :) - if a company
> is to make some money on OpenMoko users, let it at least pay it's own costs
> in full.

and what about smart2go ?

www.smart2go.com

W

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: VoIP call transfer?

[adrian cockcroft]

First: I work for eBay, I'm a Skype beta tester and have helped
develop/test the Skype Java API. I'm not speaking here in any official
capacity.

Keeping to the technology issues, Skype for mobile is targeted at
Symbian and Windows mobile, Skype desktop for Linux runs on x86, its
being worked on but is lagging development on OSX and Windows. There
are also versions of Skype for embedded devices (wifi phones etc),
probably ARM architecture which are produced as the result of
licensing deals. I think the UI is coded using Qtopia, but I'm not
sure. There is also the concept of "naked skype" which exposes a low
level API instead of the UI, but this isn't generally available.

One of the Skype developer support guys has been instrumental in
releasing some parts of Skype under a BSD license. All the icons and
all the internationalized text (in 26 or so languages) was made freely
available for developers to use. He's also a Linux advocate and I
asked him to see if they could make a generic ARM/Linux binary
available. His response was that they are too busy right now, but they
are aware of the concept.

If we did have an ARM/Linux binary, it would provide a gateway into
the Skype network be a bit like the GSM module provide a gateway to
the phone network. It has a public stable API (including a cross
platform Skype4Java API) that exposes a lot of functionality. I've
built some applications using Skype and I'd like to develop mobile
versions of those applications.

Nothing in the above needs any agreements or deals with FIC or the
OpenMoko group. I don't think Skype should be closely integrated into
the OpenMoko bundle, but if we do integrate a SIP based VoIP client
into the bundle, then I may also do the work to make Skype integrate
as well where it seems useful.

My attitude is that its an open phone architecture, I can put what I
want on my phone and if I can get Skype then I can put that on it. if
you don't like Skype then no-one is going to make you use it.

However Skype is the most downloaded program ever, over 526 million
downloads and over 9 million concurrent users every day, and there are
a lot of people who want to use it on their phones.

Adrian


Perhaps we need some sort of announcement/explanation about Skype on the
Neo/OpenMoko platform for regular users, as I'm sure many of them will
be wondering if OpenMoko will support Skype and won't be aware of the
license/ethical issues surrounding it.


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: UI long term development perspective: physics engine

[adrian cockcroft]

If the touchscreen reports the last touch and two fingers cause the
position to hop between two points then the driver just needs an
algorithm that reports the last two places and has some smoothing and
clustering built in.  Given low level access to the hardware this
shouldn't be too difficult to code and test. How does the "pointer"
device driver report position? Is there a provision to report chords
in some standard way? This isn't specific to OpenMoko, it could be a
generic Linux trackpad capability.

Adrian

On 4/1/07, Florent THIERY <[EMAIL PROTECTED]> wrote:

> > i'm pretty curious to know what exactly the touchscreen sees when  you 
touch the screen with 2 fingers at the same time, when you move them, when you move 
only one of the 2, etc, ...).
> The output is the center of the bounding box of the touched area.
> Pressure has little, but not no effect. Almost no effect on a single
> touch, on a double touch, the relative pressures will have a slight
> skewing effect towards the harder touch.
> (from theory).
> The touch point skips instantly on double touch.

Thank you. I added your report to the wiki, and reorganized the mails
so that a human being can try to contribute :p

http://wiki.openmoko.org/wiki/UI_Improvements
Please take a look if interested to help.

If you have some spare time to continue reporting about the
touchscreen, there are some questions on the wiki, but anybody having
access to hardware can do it.

Why do i keep asking for this? Because i'm not sure apple's ibooks
have multi-touch pads, but if you slide 2 fingers in parallel, it
makes scrolling. Which means: if it's not multitouch at it's base
(and, if it was, there would be more of it), then they detect it using
a hack. So can we do too, but we have to know exactly how the
touchscreen reports "exotic" uses.

Regards

Florent

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Voice synthesizer for blind and visual impaired person

[adrian cockcroft]

There are a lot of people who can't read the tiny fonts on their phone
screen. I'm particularly interested in making a UI variant that is
optimized for people with failing eyesight, but not completely blind.
I have a friend with macular degeneration who wants me to make a phone
she can use, and many older people just get long sighted and want a
simple UI they can actually read.

For completely blind people we could make a voice driven UI using
VoiceXML to specify the flows. I work alongside someone who has done
VXML work using Tellme's backend service. I'm not sure if there are
implementations we could use on the phone itself.

Adrian

On 3/27/07, Gabriel Ambuehl <[EMAIL PROTECTED]> wrote:

On Tuesday 27 March 2007 10:23:08 Bartlomiej Zdanowski AutoGuard Ltd. wrote:
> There's so much to do for blind person and we can do it together so
> think guys and please provide some solutions and thoughts.

I would imagine that a touchscreen only phone is quite hard to use for blind
people as opposed to a phone with proper keys?

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community





___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: UI long term development perspective: physics engine

[adrian cockcroft]

The physics comes in if you give the slider "mass" and intertia. Then
it accelerates and decelerates depending upon how hard you push it and
how much friction there is.

The acceleration is driven by the difference in position of the touch
point and the slider as you move the touch point and the slider lags
the movement. Move the touch point slowly and the slider follows it,
flick it fast and the slider will get a bigger kick, accelerate more
then coast to a halt and have the overshoot that you want.

Adrian

On 3/24/07, Florent THIERY <[EMAIL PROTECTED]> wrote:

I'll add here sotg from an off-list msg;

In fact we have the position given by the touchscreen : [ x(t) ; y(t) ]
speed is: [ (x(t') - x(t)) / (t' -t) ; (y(t') - y(t)) / (t' -t) ] -
friction_factor*(t' - t)

... Where the friction_factor is in [0 ; 1]

If we want acceleration, then we have to integrate the equation once.

Shit, i gotta look into my college courses, it's terrible how fast it
fades away :-p

I'm not sure we really need to take acceleration into account.

The changes to bring to the standard gtk scrolling are:
- consider the list as scrollable (not just the scroll item)
- change the scrolling "stop" behaviour (when the user stops touching
the screen) like this: if (last_cursor_speed > 0),
continue_scrolling(last_cursor_speed)
- when touching the moving list again, stop the scrolling immediately
- addition of friction may be a plus, for a more
"wheel-of-fortune"-like experience

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: UI long term development perspective: physics engine

[adrian cockcroft]

While the initial phone doesn't have the power for OpenGL, the next
generation mobile CPUs do have graphics accelerators and OpenGL
support. I think this is a very good direction to take, as a follow-on
project, but not for the initial development.

Some simple parts of the physics engine may be useful to start with,
but would need to be coded to avoid using floating point math. If we
can define a common and extensible API to a physics engine that can
have simple/integer and advanced versions, then we can smooth the
transition.

Adrian

On 3/23/07, Florent THIERY <[EMAIL PROTECTED]> wrote:

Take a look @ this iphone video:
http://www.youtube.com/watch?v=nPqqfVLQ_qY

There is:
- it's as if the entire list is the scrolling bar, but reverted
(finger down -> scroll up)
- the list follows the pointer
- as soon as you stop touching, the list continues to scroll (in
contrary to standard gtk scrolling bar)
- the list moves at the speed measured at the end of the "touching"
- some "friction" lets it slow down
- when you touch it again, it stops the scrolling

Questions:
- will the neo/openmoko graphics system be powerful enough for such
animation? I suspect apple to do opengl acceleration on this device,
which is way impossible for us
- ok, akamaru is overkill. But it allows friction, speed etc...

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Screen size

[adrian cockcroft]

Apple's rendering model for the screen looks to me as if its resolution
independent and antialiased, which means that it appears to have higher
resolution than the raw pixel count. This is harder to do using an X11 based
rendering model, but if we move to OpenGL eventually it would be comparable.
I don't know if there are any other options to render to a large X11 virtual
frame buffer with antialiasing down to a smaller size (possibly with
pan/zoom capability?)

Adrian

On 3/12/07, Tim Shannon <[EMAIL PROTECTED]> wrote:


It looks to me like the Neo's screen resolution is higher even though it's
a small screen.

Screen 3.5" 320x480 at 160 ppi, multi-touch 2.8" 480x640 at 285 ppi, maybe
multi-touch 
laterNEO
specs on the right.

As I understand it, the IPHONE isn't meant to be used with a stylus, but
the NEO optionally can be.  Personally I'd rather have the higher
resolution.  If they would potentially switch to this other screen, would
they be sacrificing the resolution, and if so would it be worth it?


On 3/12/07, Steven ** <[EMAIL PROTECTED]> wrote:
>
> I was doing some size comparisons and it raised a question.
>
> People at FIC are probably sick and tired of being compared to the
> iPhone, but it is quite the competition when it comes to hardware.
> For example, http://www.sizeasy.com/page/comp/971 is a comparison
> between the iPhone and its screen against the Neo1973 and its screen.
> As you can see, the percentage of the face occupied by the screen is
> significantly more on the iPhone...
>
> I got the size of the Neo1973's screen from
> http://www.tpo.biz/ENG/business-eng/Activer-Matrix-VGA.htm  It is
> there that I noticed another screen: the TD035STEE1.  As you can see
> here, http://www.sizeasy.com/page/comp/972 it is the exact same size
> as the iPhone's screen.  Is that screen compatible with the rest of
> the Neo1973 hardware?  What would have to be changed to support that
> bigger screen?  Could it be a after-market mod?
>
> I'm not a hardware guy and most of the acronyms on that TPO site mean
> nothing to me, so type slowly.
> -Steven
>
> ___
> OpenMoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: What moblie service to get, part 2

[adrian cockcroft]

My son bought a Cingular pay as you go SIM card, and used it in a
phone he already had, then bought another phone outright and put the
same card in it.

In the past I bought a phone on eBay and separately bought a SIM card
with a contract.

In general there are some *phones* that are locked to a carrier, but
an unlocked phone will work with any SIM card.

The carriers want to take your money and give you dialtone, they don't
really care what phone you use to to that, although they like to sell
you a phone to lock you in if they can.

Adrian

On 3/9/07, Mike <[EMAIL PROTECTED]> wrote:



OK totally excellent info Erik thanks.  (You MIT alums beat us CMU alums
sometimes I guess.)  The openmoko people definately need to address this
stuff. A couple questions inline,


Erik wrote:
> I agree that this should be in a FAQ somewhere, because it's something
> lots of US free-your-phone users need to know.  It isn't OpenMoko
> specific, but definitely relevant.  I already wasted ^H^H^H^H^H^Hspent
> some time looking in to this so I'll share what I've found:
>
> 1. I believe Cingular prepaid can do GPRS data.  This would normally
>be excellent news.  Except that its $0.01 per kbyte. [!!!]  If you
>get the max bitrate that works out to something like $4 per minute!
>So "spending minutes" to use data would be a bargain.
>
> 2. But I'm not holding my breath that I will be able to just spend
>voice minutes getting infrequent data access from a prepaid plan.
>A cellular telephone voice connection is extremly highly compressed
>in ways that sound ok for speach, but ways that mean very little
>data would get through if you tried to use standard modem codings.
>Plus, the little cpu in the thing couldn't really be expected to do
>the decoding.  Perhaps someone could do a great hack with a
>self-powered modem on the headphone port, looping back into the
>unit via a bluetooth-to-serial dongle.
>
> 3. Data plan it is.  You can't add a data plan to a prepaid card.  So
>either you have a prepaid voice card + data plan card, or you suck
>it up and sign up for a voice plan as well.

Is there really such a thing as a "data plan card" ?  I can't find that
on the gophone section of the cingular site. It only lists:

$15 30 days
$25 90 days
$50 90 days
$75 90 days
$100365 days


>
> 4. Cingular differentiates plans based on what kind of phone/interface
>device you have, and how you intend to use it.  The cheapest is
>smartphone, the next is pda, the next is laptop.  And to use one of
>their locked smartphones or pdas as a bluetooth modem you have to
>pay an expensive extra $$ per month "tether" fee.  My guess is that
>all data plans work in all unlocked devices... but maybe I'm wrong
>and theres a whitelist on the simcard.
>
> 5. It seems to be a grey area, using a phone that they don't provide.
>I can see a good argument for calling the OpenMoko a SmartPhone.
>Which is great 'cause theres a $20/month unlimited data plan for
>smartphones.  But there's no way to limit whether you can use it
>for tethered/laptop data access so who knows if they'd want to slap
>the tether fee on you. "just in case" fortunately I don't think
>they're that clue-full.

I have a feeling that both tmobile and cingular are going to do whatever
they can to prohibit the openmoko phones.  And I'm thinking the cheaper
"smartphone" data plans will only work on cingular's devices, right?
Like the device has to do something in order to be able to make use of
it- some technical limitation?  Otherwise I don't know why cingular
sells two different plans, the "smartphone 5mb" is $9.99 and the "Data
Connect 5MB" is $19.99. I don't get how else they'd be different. Would
the neo be compatible with both? Who knows?  I hope someone from the
openmoko project reads this thread.


>
> 6. It seems that you can only order a plan [get a sim card] with a
>phone.  That's not such a financial problem if you're just getting
>a cheap voice plan, because there are lots of cheap/free after
>rebate voice phones you can get and not use.  But to order a data
>plan from Cingular [of any of the tweleve types] you have to order
>a phone that is valid for that plan.


OK, you're saying no matter what plan I sign up for with cingular, even
prepaid, I have to buy a phone from them too, right?  I can't like, go
on ebay and buy a cheap used phone and still sign up with cingular, even
prepaid?

The one useful piece of info I may have then, is to tell you about the
service I have now.  I have ecallplus.com, which resells cingular.  They
have a few GSM plans, and you can bring your own phone...  So if your
sprint phone breaks you may have a cheaper path to GSM through them for
your holdover.


>
> 7. So to get a SmartPhone unlimited plan [$20/month... unlimited data
>not bad imho] you'd have to also buy a smartphone. [$150]  There's
>a $100 rebate on the ch

Re: What moblie service to get, part 2

[adrian cockcroft]

I've had Cingular unlimited for a year or two on a Treo 650. The basic
plan (national roaming, and a bunch of minutes with rollover) is about
$40/month, then the unlimited data plan adds $35, and with a few text
messages (which are extra charge) added on top my monthly bill is
about $80. I got a big discount on the Treo650 for a two year commit
to this. The SIM card does work in other phones, I have used it in a
Treo600, Nokia 6682 and have no doubt that it will work in an OpenMoko
or homebrew phone.

I use the internet a lot from the Treo, it's EDGE speeds, good enough
for keeping up with a lot of email, google maps and basic browsing,
although its slow. Coverage in the SF Bay Area is good enough and has
been gradually getting better over the years. I had T-Mobile for a
while, and had worse coverage but much better customer support.

I hope this helps,
Adrian

On 3/9/07, Erik <[EMAIL PROTECTED]> wrote:


I agree that this should be in a FAQ somewhere, because it's something
lots of US free-your-phone users need to know.  It isn't OpenMoko
specific, but definitely relevant.  I already wasted ^H^H^H^H^H^Hspent
some time looking in to this so I'll share what I've found:

1. I believe Cingular prepaid can do GPRS data.  This would normally
   be excellent news.  Except that its $0.01 per kbyte. [!!!]  If you
   get the max bitrate that works out to something like $4 per minute!
   So "spending minutes" to use data would be a bargain.

2. But I'm not holding my breath that I will be able to just spend
   voice minutes getting infrequent data access from a prepaid plan.
   A cellular telephone voice connection is extremly highly compressed
   in ways that sound ok for speach, but ways that mean very little
   data would get through if you tried to use standard modem codings.
   Plus, the little cpu in the thing couldn't really be expected to do
   the decoding.  Perhaps someone could do a great hack with a
   self-powered modem on the headphone port, looping back into the
   unit via a bluetooth-to-serial dongle.

3. Data plan it is.  You can't add a data plan to a prepaid card.  So
   either you have a prepaid voice card + data plan card, or you suck
   it up and sign up for a voice plan as well.

4. Cingular differentiates plans based on what kind of phone/interface
   device you have, and how you intend to use it.  The cheapest is
   smartphone, the next is pda, the next is laptop.  And to use one of
   their locked smartphones or pdas as a bluetooth modem you have to
   pay an expensive extra $$ per month "tether" fee.  My guess is that
   all data plans work in all unlocked devices... but maybe I'm wrong
   and theres a whitelist on the simcard.

5. It seems to be a grey area, using a phone that they don't provide.
   I can see a good argument for calling the OpenMoko a SmartPhone.
   Which is great 'cause theres a $20/month unlimited data plan for
   smartphones.  But there's no way to limit whether you can use it
   for tethered/laptop data access so who knows if they'd want to slap
   the tether fee on you. "just in case" fortunately I don't think
   they're that clue-full.

6. It seems that you can only order a plan [get a sim card] with a
   phone.  That's not such a financial problem if you're just getting
   a cheap voice plan, because there are lots of cheap/free after
   rebate voice phones you can get and not use.  But to order a data
   plan from Cingular [of any of the tweleve types] you have to order
   a phone that is valid for that plan.

7. So to get a SmartPhone unlimited plan [$20/month... unlimited data
   not bad imho] you'd have to also buy a smartphone. [$150]  There's
   a $100 rebate on the cheapest phone, but who knows if you'd
   actually get the rebate.  And who knows if it'd actually work in
   the neo.

8. I'm not even sure that you can have a data plan without a voice
   plan.  Seems like at the very least you might not get the
   smartphone rebate if you don't get the rebate.


Good luck, please share what else you find!  You are indeed not the
only one trying to figure all this out!

-erik

ps.  A reasonable default, if you need a phone right now, is to buy a
cheap prepaid phone and use that for the couple months until it
becomes more clear exactly what plans work with the neo in the US.
That way you're not locked in... and you have a sim that you can use
for voice testing at the very least with the neo.  That's what I'm
going to do when/if my 4year old phone [on sprint month-to-month/no
contract all its life] croaks before i get a phase 1!


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Yet another finger keybord (gui mock-up).

[adrian cockcroft]

This technology is eventually going to be available on Linux according
to the author, there was a demo at ETel.

http://www.almaden.ibm.com/u/zhai/shapewriter.htm

Adrian

On 3/5/07, Joe Pfeiffer <[EMAIL PROTECTED]> wrote:

[EMAIL PROTECTED] writes:
>
>How about making use of AI techniques and having the layout self-adjust to
>generate a layout that pushes frequently used letters to the right places, and
>then arranges the surrounding letters to reduce typos? If this consumes too
>much processing power for normal use, there could be a separate "learning"
>mode during which you would tolerate the slowness, and later switch to fixed
>mode. Or it could be like SpamAssassin - keystrokes (both correct and
>incorrect) are logged in some efficient way, and later you can "train" the
>layout "engine" when the device is not in use, perhaps even pushing the
>processing to a different computer.

That would not be a good idea:  there is no key layout so bad that's
it's worse than one that changes out from under the user.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: A new approach to Re: Itch3: Anti-lost/theft protection

[adrian cockcroft]

I would like to include an accelerometer in a phone design (my own
homebrew design or a future Neo perhaps?), then all the Nintendo Wii
style interactions become possible.

If my phone is locked it asserts that it should be at rest, if someone
picks it up it needs a code or a secret gesture on the touchscreen to
unlock it or set moving locked mode.

if it doesn't get the code it asks to be put down again, if that fails
it complains loudly in speakerphone "help, I'm being stolen, put me
back!" or whatever audio you like.

It also posts its location to a web service.

Should be easy enough to code, I'm just waiting for the hardware to catch up...

Adrian

On 2/28/07, Attila Csipa <[EMAIL PROTECTED]> wrote:

On Wednesday 28 February 2007 21:44, Steven ** wrote:
> Caveat emptor.  Possession of stolen property is still a crime where I
> live, even if you didn't do the actual stealing.

All I'm saying (IANAL of course) that for many of those items (especially on
places like ebay) it is very hard for the buyer to establish whether the good
is actually stolen or not (receipts and boxes can be photoshopped all too
easy), and he has to rely on a level of reasonable doubt (based on seller
rating, price, provided images, etc) to determine whether he is getting the
good from a trustworthy source.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko workshop at ETel

[adrian cockcroft]

Sean said it will have a faster CPU in June, he implied that WiFi is
planned and graphics acceleration is on the roadmap somewhere, but not
June.

Adrian

On 2/27/07, Alan Ide <[EMAIL PROTECTED]> wrote:

So, I am a little confussed still. Are you saying the "Refreshed" version of
the Neo that will be released in June will have A faster CPU, dedicated
Graphics Acceleration, AND Wifi?? If so, thats a hell of an "upgrade" after
3 months.


-- Forwarded message --
From: Alan Ide <[EMAIL PROTECTED] >
Date: Feb 27, 2007 3:39 PM
Subject: Re: OpenMoko workshop at ETel
To: mathew davis <[EMAIL PROTECTED]>

So, I am a little confussed still. Are you saying the "Refreshed" version of
the Neo that will be released in June will have A faster CPU, dedicated
Graphics Acceleration, AND Wifi?? If so, thats a hell of an "upgrade" after
3 months.

On 2/27/07, mathew davis < [EMAIL PROTECTED]> wrote:
> Thnks for the info it answered a lot of questions I had.  I get more and
more excited about this project as it goes on.
> ___
> OpenMoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community




___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

OpenMoko workshop at ETel

[adrian cockcroft]

Rough notes, taken as Sean talked.

8:30am, about 30 people in the audience, in a large room, plenty of
space. Same basic presentation as FOSDEM, as far as I can tell, now I
can actually read the slides...

Showing actual screenshots of apps for the first time..

pim application UI shows translucent menu
Full GTK widget set
PIM uses evolution data server lite - EDS lite - outlook sync etc.

header panel, matchbox-panel-2 shared libraries
footer panel, task mgr, status stack, app toggle

Finger apps
Phase1 - Dialer, Main Menu, Music Player, History

Phase2 - Clocks screen saver, calc, unit conv, game, guitar tuning, code memo

Stylus apps
Phase1 - contcacts, dates, apps manager, today

Phase2 - feed eader, messages, prefs

Standard kit includes 512MB SD card.
120x60mm

Developer sales - Late March, maybe 1st week of April
Phase 1+ June - Hardware Refresh - faster CPU to allow alpha blend UI
etc. The #1 "request" i.e. WiFi - will be in the refresh hardware.

Q&A
They are working on phones that will have cameras.
VOIP needs WiFi, open source framework once they have WiFi
Graphics acceleration - you bet... OpenGL and hardware acceleration
Prototype in his pocket boots and runs X.
Multitouch - capacitive allows multi-touch, resistive doesn't. Lots of
prior art, so this isn't going to be a patentable thing
Unit volumes - can't say, but longest component lead time is 6 weeks
Widgets - GTK contains lots of legacy code, some ugliness needed,
trying to make it better, future UI work based on OpenGL for Linux is
promising.
Multimedia libraries - currently Mplayer, future may be Gstreamer
needs faster CPU
Application management needs a lot of work, based on openembedded
Languages, mainly C with projects to add Java, Python etc.
Questions about the proprietary GSM modules and variations.
Next get CPU will be a faster Samsung, which needs external graphics chip.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Back from FOSDEM

[adrian cockcroft]

The Nokia BL-5C is only 850mAh as standard, the BL-6C is 1050mAh.

For comparison the Treo 650/700 has a much fatter battery which is
1800mAh by default, with 2400mAh in aftermarket options.

Adrian

On 2/26/07, Mikko Rauhala <[EMAIL PROTECTED]> wrote:

ma, 2007-02-26 kello 16:57 +0100, Michael 'Mickey' Lauer kirjoitti:
> Suddenly the guy sitting right next to me said "If your battery is
> drained, try this Nokia one". I said "No way, the FIC one is
> compatible to nothing else." The guy: "Oh I think it is". And so I
> tried and it turned out it is _exactly_ the same battery!!! I put it
> in and *boom* it booted! :)

I've actually wondered about that since they look very much the same (in
pictures). Good to hear that confirmed, that means I've already got a
spare ;)

--
Mikko Rauhala   - [EMAIL PROTECTED] - http://www.iki.fi/mjr/>
Transhumanist   - WTA member - http://www.transhumanism.org/>
Singularitarian - SIAI supporter - http://www.singinst.org/>


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Content from the old wiki to the new wiki

[adrian cockcroft]

I added the ETel conference to the Events page. Sean Moss-Pulz is on
the agenda with OpenMoko, Surj Patel and Matt Hamrick of Tuxphone and
the homebrew club are also presenting, I'll be there...

Adrian

On 2/18/07, Richard Bennett <[EMAIL PROTECTED]> wrote:

On Sunday 18 February 2007 17:19, Ole Tange wrote:
> > Ok, I moved the FOSDEM article.
> >
> > I created a new section ' FIC / OpenMoko at Events' on the new wiki to
> > allow grouping all events together.
>
> I would think it might be better put under
> http://wiki.openmoko.org/wiki/Current_events
Except that that page is not linkled from the front page, that I can see.
Could the Current_events page be set to show its 5 first items on the
frontpage ?  (I'd use the views module if this was Drupal).
I added [[Category:events]] to both pages to tie them together for a start.

> > How would I go about making a category 'events' so all events can be
> > shown on a page grouped together, and the URL would become
> > .../wiki/events/FOSDEM ?
>
> A category is added using: [[Category:FOO]]. It will not create the
> URL, but it will make it easy to make pages like:
> http://wiki.openmoko.org/wiki/Category:Ideas
Ok, I used [[Category:events]] . It's irritating the way the wiki changes the
capitalization all the time, reminds me of windows...

> Events are typically date centered. Would it be feasible to change all
> event titles, so they start with the start date in ISO8601:
> -MM-DD? Then the category page would show events in calendar
> order.
> 2007-02-23 FOSDEM
> 2007-03-15 Pingwinaria 2007
I tried that, by moving the current page, but the category links don't get
updated, and I moved the main page first by accident (and moved it back), so
in the end I left it like that.
>

> > The Search function doesn't seem to work at all.
>
> That is a bad bug report.
If you search for NEO you get no results, so I thought it didn't work at all.
Now it seems it only searches the titles of pages, not the content, even after
selecting all the checkboxes in 'preferences'.
Maybe that's by design, but then 'Search Title' would be a better description.

Cheers,

Richard.

(BTW, no need to CC me offlist, I follow all posts to the list)

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: homebrew hardware and WiFi

[adrian cockcroft]

You can already get  the Telit GM862-GPS GSM Modem w/ GPS, along with
the Bluetooth/WiFi module, thats four networks in two packages, with
open specs and existing project plans for Linux. the fun part is going
to be figuring out how to lay out four antennas in a small package.

The OpenCell project
http://www.widgetry.org/dokuwiki/doku.php?id=parts_lists is
trailblazing this particular combination.

And of course, anything the homebrew designs work out is openly
documented so could be evaluated by the OpenMoko team for future
designs that might actually fit in your pocket

Adrian

On 2/18/07, Ian Stirling <[EMAIL PROTECTED]> wrote:

Wolfgang S. Rupprecht wrote:
> One other hope I have is that the RF chip designers will start making
> more flexible radios.  Does a GSM/wifi/bluetooth/GPS phone really need
> 4 different RF chips and associated antennas and cabling?  Using
> software-radio techniques it might be possible to combine some of the
> hardware.

Basically - perhaps at some time in the distant future.
For the moment, basically no.
There are a large number of reasons why not - firstly, 1GHz A/D
converter chips are both large, power-hungry, and expensive.
Secondly, processing the output from them is hard.
Thirdly, the dynamic range and intermodulation between different radio
frequencies mean that it's even harder.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

homebrew hardware and WiFi

[adrian cockcroft]

Hello, I'm new to the OpenMoko lists, but I'm a member of the Silicon
Valley Homebrew Mobile Phone Club that started up last year at
http://www.hbmobile.org . We have been working towards our own family
of hardware designs, based mostly on http://www.gumstix.com processor
boards, and will be adopting and contributing to whatever software
seems useful. We are very happy that the Trolltech Greenphone and the
OpenMoko project seem to have kick started an open source community
around mobile phone applications, we already have Greenphone-toting
members and several of us plan to get OpenMoko's when they ship to
developers.

Homebrew hardware takes the open phone concept one step further, and
uses exclusively components that can be fully documented and specified
without needing a manufacturer NDA. We are publishing our designs as
we get them done, and I've been playing around with one-off case
designs that can be produced on a 3D printer, to accomodate any LCD
size and feature set - which has become known as the "my phone"
project :-)

There is a WiFi and Bluetooth combo card available here that some of
us intend to use:
http://www.embeddedworks.net/newsite/WLAN/oem_sip_80211g.html

So if you want different design features than the Neo1973 offers, you
really can go build it yourself rather than grumbling about it on the
lists. It should be possible to run most of the OpenMoko software,
especially if you stay with the same screen resolution etc. Homebrew
designs are harder to minaturize so it works best with bigger format
designs  based around 3.7" or 4.3" LCDs.

Open phones are an idea who's time has come, we look forward to
working together..

Cheers Adrian

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community