Re: Apple is going to beat all competitors

[Joshua Layne]

Hi all,
I'm new to the listserv.  very much looking forward to the october  release of the neo.

While the announcement below is neat.  And the hardware for the iphone is
neat.

I'll wait for the neo.

I have no love for AT&T and will not spend a dime (much less $399) on
another closed system.

Now, if it ran linux with open drivers that might be another thing
entirely. :)

Rgds,
joshua
On Thu, 6 Sep 2007 19:43:12 +0300, Denis Parchenko <[EMAIL PROTECTED]> wrote:
> Hi folks!
> 
>   Anyone saw new Apple announcement? Now iPhone is priced at $399..
>  
>
http://www.engadget.com/2007/09/05/steve-jobs-live-apples-the-beat-goes-on-special-event/
> 
> =#=-===-===#=--- - -- -=#=-- - -   -  -
>  Best regards,
>Denis
> 
> 
> ___
> 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: Apple is going to beat all competitors

[Joshua Layne]

Ian Stirling wrote:

Jens Fursund wrote:



On 9/9/07, *Giles Jones* <[EMAIL PROTECTED] 
> wrote:


Nothing wrong with the hardware, there's just no open source GPS
driver yet.


I´m confused: Does this mean that the GTA02 will include GPS-hardware 
but not software because of not having an open source firmware?



No - the hardware and binary module is available for GTA01, and for 
GTA02 if the choice is made to release GTA02 with the same chipset.


The module is at the moment delayed, but will be along real soon now.

While I understand the desire to have a fully open-source module (and 
have read the large amount of discussion around this), I have used 
familiar linux with a bluetooth GPS spitting out NMEA and gpsd for 
several years now (primarily with roadmap 
(http://roadmap.digitalomaha.net)).  For 95%+ of all uses, the gpsd 
interface will be fine - whether the module is binary or OSS.


There is perhaps a significant philosophical difference between the two, 
but I think the functionality will be fine either way.  And regardless 
of which is chosen, an added benefit of using gpsd is that it allows 
multiple subsystems to use location data, as they can all listen to the 
stream.


my $0.01
j.


___
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

wiki problem?

[Joshua Layne]

Hi,
I am unable to verify my email address (and therefore edit pages) - tried
twice now (http://wiki.openmoko.org/wiki/Special:Confirmemail) and each
time the code that was sent was 'invalid' less than two minutes after
requesting it (the email claimed it was valid until Septembe3r 17)

Any thoughts, known issue?

Not that I have anything particularly burning to record on the wiki, but it
would be nice to help document and add ideas as I have time.

TIA,
joshua


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

fixed -- Re: wiki problem?

[Joshua Layne]

wow.
within a few minutes of sending this, I was sent another confirmation link
that worked.

thanks for the quick response.
joshua

On Mon, 10 Sep 2007 11:13:07 -0700, Joshua Layne <[EMAIL PROTECTED]>
wrote:
> Hi,
> I am unable to verify my email address (and therefore edit pages) - tried
> twice now (http://wiki.openmoko.org/wiki/Special:Confirmemail) and each
> time the code that was sent was 'invalid' less than two minutes after
> requesting it (the email claimed it was valid until Septembe3r 17)
> 
> Any thoughts, known issue?
> 
> Not that I have anything particularly burning to record on the wiki, but
> it
> would be nice to help document and add ideas as I have time.
> 
> TIA,
> joshua
> 
> 
> ___
> 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

GPS driver -- was: Re: Apple is going to beat all competitors

[Joshua Layne]

Joshua Layne wrote:

Ian Stirling wrote:

Jens Fursund wrote:



On 9/9/07, *Giles Jones* <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


Nothing wrong with the hardware, there's just no open source GPS
driver yet.


I´m confused: Does this mean that the GTA02 will include 
GPS-hardware but not software because of not having an open source 
firmware?



No - the hardware and binary module is available for GTA01, and for 
GTA02 if the choice is made to release GTA02 with the same chipset.


The module is at the moment delayed, but will be along real soon now.

While I understand the desire to have a fully open-source module (and 
have read the large amount of discussion around this), I have used 
familiar linux with a bluetooth GPS spitting out NMEA and gpsd for 
several years now (primarily with roadmap 
(http://roadmap.digitalomaha.net)).  For 95%+ of all uses, the gpsd 
interface will be fine - whether the module is binary or OSS.


There is perhaps a significant philosophical difference between the 
two, but I think the functionality will be fine either way.  And 
regardless of which is chosen, an added benefit of using gpsd is that 
it allows multiple subsystems to use location data, as they can all 
listen to the stream.


my $0.01
j.

I'd like to pretty much retract the above (typed before brain had 
engaged and was educated) based on two things:
1) I had forgotten (because I am not that much of a linux hacker really) 
about binary incompatibilities with newer kernels (often - doesn't 
always happen when the driver is firmly in userland) -- this appears to 
be a real problem based on a message I saw this morning between gllin 
(sp?) and 2.6


2) I had no idea how much you could munge the signal data (in a good 
way) before location was computed.  After reading a few articles on the 
wiki that detail this (WAAS, ionospheric conditions, etc...) - I realize 
that my position was wrong.


sorry to drag the list through my thought process, but I look forward to 
the open-source GPS driver.


best rgds,
j.

___
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

2007.2 dialer suggestions

[Joshua Layne]

I saw some feedback on this at one point, but I have been unable to locate
the thread - so...

I like most of what I see in the 2007.2 dialer mockups, but there are two
glaring usabiliy issues in my mind.

One, the answer icon doesn't look that much different from the ignore icon:
http://wiki.openmoko.org/images/f/f0/Dialer-incoming-arrows.png

Could there be a color shift here? maybe a green/red thing?  I know that
green/red is bad for color blind, but for those of us who aren't color
blind it would help (and I would argue that orange/orange is just as bad
for anyone colorblind (or not))


Two (and this was previously commented on), the hangup button should NOT
replace the answer button.
http://wiki.openmoko.org/images/f/f7/Dialer-talking-arrows.png

A suggestion would be to have the speakerphone button replace the answer
button.  Positional association with function can be very strong - it needs
to be intuitive.

Rgds,
joshua


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

Re: 2007.2 dialer suggestions

[Joshua Layne]

On Wed, 12 Sep 2007 12:27:53 -0700, "Roger Borges" <[EMAIL PROTECTED]>
wrote:
> I agree with both of these points. Red and green may interfere with the
> color scheme of the phone, but maybe making the ignore/hangup icon red
and
> leaving the answer icon orange would be effective?

While I would not suggest that we move the UI to an AngryFruitSalad
(http://catb.org/esr/jargon/html/A/angry-fruit-salad.html) - I am not
certain that a diachrome orange and black scheme is the only answer.

However, I know the UI is themed - my biggest concern is the button
location, not the color - the color can be easily changed by re-theming.

j.


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

Re: application idea

[Joshua Layne]

Denis Parchenko wrote:

  Is it really impossible somewhere in airport to find out current
weather outside? For example on some info-boards...
  
It isn't nearly as much fun.  How can you walk around the airport with 
your head buried in your neo, bumping into people otherwise?


Seriously - I think the augmented reality / location+context sensitive 
apps are very fun and useful - this particular example may not reflect 
all attributes of such systems, but if somebody has the itch to code 
it... scratch it.


j.

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

ping?

[Joshua Layne]

Hi - sorry for the 'spam' - I am not receiving messages from this (or
other) openmoko list.

anyone else having the same problem?


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

please disregard -- Re: ping? (nt)

[Joshua Layne]

error on my end apparently - sorry for the spam

On Fri, 14 Sep 2007 22:17:13 -0700, Joshua Layne <[EMAIL PROTECTED]>
wrote:
> Hi - sorry for the 'spam' - I am not receiving messages from this (or
> other) openmoko list.
> 
> anyone else having the same problem?
> 
> 
> ___
> 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: 2007.2 dialer suggestions

[Joshua Layne]

Thomas Wood wrote:

On Wed, 2007-09-12 at 11:55 -0700, Joshua Layne wrote:
  

I saw some feedback on this at one point, but I have been unable to locate
the thread - so...

I like most of what I see in the 2007.2 dialer mockups, but there are two
glaring usabiliy issues in my mind.

One, the answer icon doesn't look that much different from the ignore icon:
http://wiki.openmoko.org/images/f/f0/Dialer-incoming-arrows.png



We have already asked the designers for a bunch of new icons to solve
these issues.

  

great!

Could there be a color shift here? maybe a green/red thing?  I know that
green/red is bad for color blind, but for those of us who aren't color
blind it would help (and I would argue that orange/orange is just as bad
for anyone colorblind (or not))


Two (and this was previously commented on), the hangup button should NOT
replace the answer button.
http://wiki.openmoko.org/images/f/f7/Dialer-talking-arrows.png

A suggestion would be to have the speakerphone button replace the answer
button.  Positional association with function can be very strong - it needs
to be intuitive.



If you check the latest screenshots, you will notice this was already
fixed (as reported in this bug:
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=730).
  
Thanks for the reply and info - where would I find these updated 
screenshots?


Regards,
josh


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

dialer suggestion

[Joshua Layne]

kinda tongue-in-cheek, but...
so kinetic scrolling works now
and all the 'dialer' does is capture numbers to send to the GSM chip.
what about an old-school dialer?  OK, maybe 'retro' is a better name at 
this point.


ROTARY baby!

kitsch.  flare.  nobodyelsehasit.

(maybe there is a reason for that last one)

I dunno - crazy idea, but it could look really cool - " what the H are 
you doing?" - "I'm dialing my cell phone, jeez"


I have no photoshop skillz, so all I can tell you is: find an old rotary 
dial phone - make it look like that. - like a virtual of these: 
http://www.makezine.com/blog/archive/2005/06/portable_rotary.html (just 
the dialer)


priority (1 is high): 99 or 999

it's at least as important as TV.

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

Re: Qtopia coming for Neo1973

[Joshua Layne]

Michael Schmidt wrote:

Hi, great news, but what does this mean?
We need a posting of the projekt management, will Neo s Menue switch to QT?
This means a GTK application will not work?
Or: Any QT-Applicaiton will work now automatically?
 We need this info, for a decision, to stick to the library either a
GTK-Gui or the existing QT-Gui. To not saddle on the wrong horse..
please send a notice

Applications for Neo, should have a GTK or QT gui?

  
Applications for the _Neo_ can have whatever gui the developer wants to 
build (or as many - there are several apps that support multiple 
rendering environments)


Applications for _*openmoko*_ should have a GTK+-2 gui.

openmoko isn't switching to QT.

there is just now another gui available.

for myself - I much prefer GTK interfaces. and will be sticking with GTK 
on the Neo (when I buy)


Rgds,
j.

thanks

On 9/18/07, Mauro Iazzi <[EMAIL PROTECTED]> wrote:
  

before someone beats me to it.

http://trolltech.com/company/newsroom/announcements/press.2007-09-17.9260755578

and

http://www.linuxdevices.com/news/NS5429713730.html

In short: Qtopia is going to be fully GPL'd (telephony applications
included, which weren't) and is being ported to Neo1973.



___
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: Qtopia coming for Neo1973

[Joshua Layne]

[EMAIL PROTECTED] wrote:


This is something someone else touched on. If you're writing an application, 
abstract all the complicated stuff away from the UI code, then you can make 
whatever kind of UI you want. NetworkManager I think is a perfect example of this. 
It would be good to have a defined interface to access PIM info, make calls etc. I 
believe LiPS has been set up to do just that. So perhaps it would be better to make 
moth OpenMoko & Qtopia PE LiPS complient. I heard that the LiPS forum hired a 
load of GPE PE developers to develop a reference implementation. It might be worth 
looking at GPE PE and lifting some of the standardised bits. I don't know, perhaps 
this is happening already?
I asked this question on the G(PE)^2 listserv - both projects started 
very close in time to each other, have different backing and slightly 
different goals, but there is reasonable overlap and it is my 
understanding from one of the core G(PE)^2 members that they are working 
with the openmoko team to collaborate as much as possible.  I don't 
really have any detail beyond that.


Rgds,
j.

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

Re: Help Request for our Webshop

[Joshua Layne]

Sean Moss-Pultz wrote:

Dear Community,

We have a specification and database model in place for our new webshop
but we can't find the resources needed to implement this in the near
future.

We are looking for something as follows:

  * Accept numerous online and offline payment processing options
  * Add/Edit/Remove products, distributors, retailers, and customers
  * Support of inventory and RMA
  * Support for spare part ordering, stocking and shipment
  * Support multiple carriers / shipping methods
  * Automatic generation of invoices and shipping information
  * Secure transactions with SSL -- we need to have the highest possible
level of security and privacy
  * Clean, maintainable code which will be audited before being put into
full production.

Preferable this webshop should not be written in PHP. Either Perl,
Python or Ruby would be fine by us.


Hi Sean,
This may be a stupid comment (and feel free to ignore it if it is), but 
why build your own?
Having worked on ecom sites in the past and seen how convoluted 
individual requirements can make a site, I've come to the conclusion 
that there are significant advantages in doing just what everybody else 
does.


a brief googling *  turned up 'substruct' - open source, based on ruby 
on rails - meets a subset of your requirements, but may be extensible 
enough that you don't have to reinvent the entire wheel, only the shiny 
new spin-rims.


* Based on about a minute and a half of investigation - there are 
probably more appropriate projects out there, this is just an example.


And your requirements may really be complex enough that the pre-built 
OSS stack isn't viable.  In that case, I would take a closer look at the 
requirements and see if you can drop any for release 1.


Build when all else fails (unless it is your core competency, like 
say a linux phone distribution :P )


my $0.02
josh

If anyone is interested in developing this webshop, (for pay of course)
please email [EMAIL PROTECTED] with the following information:

  1) A summary of your qualifications
  2) How much time you could spend on this project

We will select from these emails a few especially qualified applicants
and ask them to sign our NDA and then provide them with the complete
specification and database model. There are too many confidential
business details to just post this all publicly now.

Thanks!

Sean

___
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: Help Request for our Webshop

[Joshua Layne]

On Mon, 24 Sep 2007 13:27:45 -0400, Ian Darwin <[EMAIL PROTECTED]> wrote:
> 
>> I've done enough work in django (python) recently that the idea of going
>> back to PHP sounds like some kind of really brutal punishment.   The
>> code is really much easier to read, because the code and presentation
>> are kept in separate files. The original idea with PHP of embedding code
>> in HTML was cool in theory, but in practice I think templates are a lot
>> easier to maintain.   Django isn't perfect, but I can see why people are
>> edging towards it and away from PHP.
> 
it's also very possible to code PHP using MVC - it just takes discipline.

easier to use a templating engine (like smarty) because it forces the
dicspline on you, but also extra overhead - I would argue it is better to
do it yourself using strict separation.

> It's not just PHP - Java EE had the idea (long ago) of embedding code in
> HTML, but now we tell people to "get the Java out of the JavaServer
> Pages".
> 
> It's funny in a sad sort of way - the original MVC paper was published
> in 1979, darn near three decades ago, and way too many developers still
> haven't got the idea. It's bad when they mess up one application, but
> when they publish a framework, and zillions of people start using it...
> 
we tried teaching basic design patterns to some of our internal developers
(we aren't a software shop, but do write some internal apps) - the
feedback: "Why would we ever need this?"

good development practices are rare IME.

anyway, somewhat far afield from openmoko. As long as the solution they
build makes the neo orderable and deliverable (without my identity being
lifted...), I'm happy  :)


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

Re: Unified PIM

[Joshua Layne]

On Wed, 26 Sep 2007 18:49:43 +0100, <[EMAIL PROTECTED]> wrote:
> 
>>I guess my only comment is that while I don't really care which
>>interface people use on their phones, it seems like the data interfaces
>>should be the same... If I open up qtopia phone edition and look at my
>>contacts or maybe even edit them and then close it down and open up my
>>OM interface and look at them, they should be the same.  All edit are
>>visible.. No double entry.
> 
> Agreed, but I'd take it one step further. Given the neo has an internet
> connection, why can't PIM data be stored on a web server and just cached
> locally. Couldn't you then integrate that into desktop PIM applications
> too?
> 

I would prefer to not have a network dependency on PIM data.  It might be a
nice extra feature, but I would like to see the core data held on the phone
supported by the different front-ends.  I may want to switch frontends
without resyncing all my data.

It seems like LiPS might be a good start for this shared architecture.

In the event of a "non-compliant" implementation, perhaps
wrapper/abstraction scripts could be built to make it transparent to the
end user?

Regards,
j.

> Ok, so this isn't a new idea. :-) Evolution Data Server supports
> integration to groupware backends, but from what I've seen, these are
> enterprise-class groupware servers designed for corporations. I can't
seem
> to find anything designed for the consumer, an internet-accessible
> groupware server I can sign up to and store my contacts in a single
place.
> 
> The problem is not local - I'd be surprised if Embedded EDS couldn't be
> adapted to store it's data on a server and just use a cached dataset
> locally. The problem is that this requires some server infrastructure and
> so far I've yet to find something which will do it. Has anyone else seen
> this done?
> 
> 
> 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: gtk-sharp packages available for neo

[Joshua Layne]

On Fri, 05 Oct 2007 18:59:11 +0200, Mikkel Meyer Andersen
<[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Thanks for your response.
> 
> Yes, I did see that. And I have the src locally
> (~/moko/openmoko/trunk/src/target/OM-2007/openmoko-libs/libmokoui) which
> is also well-documented.
> 
> The problem is that C# cannot use the C-files as references (directly),
> but instead has to use the libraries (the result of the C-files after
> compilation) with a lot of interoping - and that is really a error-prone
> task (just as an example byte in C corresponds to unsigned char in C#
> etc).
> 
> To the C-files could be used as documentation for making the interoping,
> and that's exactly what Swig does. So I'm going to test if those
> autogenerated C#-classes is usable.
> 

ok, sorry I couldn't be of more help - I am never sure if everyone else has
the same "crack addiction" that I have about all news openmoko-related.  I
check a few times a day :)

I am not a C# (or really C-anything developer), so while I understand the
basic details of your response - I have never had to do anything like that
- sounds like an ugly integration though.  The abstraction you propose in
your follow-up email sounds like a good way to manage it though.

The benefit of using C# is to run code developed for WM?

I don't know much about it as a language except that it was originally
(IIRC) developed for windows (by MS?)

I hope you don't mind, but I am copying the list on this - it might be
educational to more than me.

> Regards,
> Mikkel
> 
> Joshua Layne skrev:
>>
>> On Fri, 05 Oct 2007 18:05:21 +0200, Mikkel Meyer Andersen
>> <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> How shoud I refer to libmokoui (e.g. MokoApplication and MokoAlignment)
>>> from within a Mono-application?
>>>
>>
>> I assume you have seen this? http://folks.o-hand.com/thomas/libmokoui2/
>>
>> from Thomas' blog.
>>
>> it looks pretty well documented - not sure if you meant v2 above though
>> (although prob development should be done against v2 if possible)
>>
>> HTH,
>> j.
>>> Can anyone be so kind to just post a very small hello world-program?
>>> I've been through the MokoMakefile-procedure, so I have all the
> sources.
>>>
>>> Best regards,
>>> Mikkel Meyer Andersen
>>>
>>> Mikkel Meyer Andersen skrev:
>>>> Hi,
>>>>
>>>> Oh, that's really nice! Thanks a lot - also for the quick reply. Well,
>>>> on the other hand I'll not get much sleep this weekend now :-) Just
>>>> kidding, thanks.
>>>>
>>>> Regards,
>>>> Mikkel Meyer Andersen
>>>>
>>>> Cliff Brake skrev:
>>>>> On 10/5/07, Mikkel Meyer Andersen <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> Is this meaning that it's possible to make C#-applications to
> OpenMoko
>>>>>> with GTK as GUI (as opposed to e.g. WinForms)?
>>>>> Yes.
>>>>>
>>>>>> How much of the Mono
>>>>>> library is supported? I'm having a bit trouble finding documentation
>>> on
>>>>>> this on the wiki, sorry.
>>>>> Everything in the main mono package as far as I know -- just install
>>>>> as much as you need.  You can browse the following for a list of
>>>>> components:
>>>>>
>>>>> http://dev.bec-systems.com/feed/openmoko/mono/
>>>>>
>>>>> I'm sure additional mono libs and apps from other projects will be
>>>>> added in the future as there is need.
>>>>>
>>>>> Cliff
>>>>>
>>>>
>>>>
>>
>>
>>


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

Re: OpenMoko talk at SDForum, Palo Alto

[Joshua Layne]

The talk was great.  Thank you very much, Michael.

Also, for me it was the first time that I got hands-on with a neo.  I am
definitely getting a GTA02 - the form factor is actually pretty nice.

We didn't get the beer afterward organized though - we need to work on that
for next time :)

I think particularly as the next wave ships out and the software becomes
more final, local clubs would be a really cool way to get exposure and
perhaps even some viral marketing - get some people blogging or twittering
about it and you might not have enough seats to go around (at least here in
silicon valley)

j.

On Tue, 09 Oct 2007 09:48:17 -0700, Michael Shiloh <[EMAIL PROTECTED]>
wrote:
> Indeed, and many participants are active on this list as well. There is
> a good flow of information between the lists.
> 
> Michael
> 
> Lon Lentz wrote:
>>
>>   There's a Homebrew Mobile Phone Club? I am so on the wrong coast.
>>
>>
>> On 10/8/07, *Michael Shiloh* <[EMAIL PROTECTED]
>> > wrote:
>>
>>
>> Unfortunately, this conflicts with the monthly Silicon Valley
> Homebrew
>> Mobile Phone Club Meeting. Perhaps they would like to join us for
> beer
>> afterwards.
>>
>>
>>
>> 
>>
>> ___
>> 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: interface design suggestions

[Joshua Layne]

On Mon, 15 Oct 2007 12:19:57 -0500, Jeffrey Thomas <[EMAIL PROTECTED]>
wrote:
> To be honest, I understand the concepts of better contrast etc, but the
> proposed interface is very blockish and not nearly as nice looking as the
> fades and the use of Orange in the current.  I do understand that it is a
> quick mockup, and that I myself have had no suggestions (nor do I claim
to
> know about usability), but I really like the current look quite a bit
more
> than the proposed.  I dislike the white fields in the proposed, and the
> large number of colours; there is much to like in the current: the
circular
> keys, the rounded edges everywhere, the slight boarders to the various
> frames and fields, all make for a nicer looking interface (IMHO).  At the
> resolution the phone provides, I don't think that the phone should look
> like it has a lot less by removing these stylistic details.
> 
> Again, I am just one person with the desire to help influence this great
> project, and the overall goal is to make a great phone.  I appreciate the
> work of all in this endever, as I really am only a "buystander."  The
> usability team will really know best, and I am hoping it is all themeable
> anyway.  Dani, you've put more thought into this than I, and you seem to
> know.  I just like the current so much, orange and grey looks great.
> 
Hi Jeffrey,
all valid points, but I personally can't stand the orange and grey theme. 
the basic design is fine (curved buttons, etc), but the colors should be
_easily_ skinnable without having to entirely rewrite a theme.  Ideally,
just set somewhere in a preferences file, like ~/.openmoko
This should not reflect a philosophy of "all of these things are orange and
so they are all equivalent", but rather a functional characterization of
the UI element and association with base color.  For gradients where a
color shift is used for shadow/highlight, ideally this would be calculated
from base color, although allowing the specification of multiple colors to
form the gradient is an acceptable (if slightly more cumbersome)
alternative.

I know Thomas was doing work on converting away from a pixmap-based theme,
so this flexibility should be possible, the gradients just weren't quite as
pretty using GD.

Of course, if run-time customization is not possible, then a multitude of
nearly identical skins will spring up - workable, but less than ideal.

Regards,
joshua


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

Re: [Data & Calls] over [Wifi & Mesh network]

[Joshua Layne]

On Mon, 15 Oct 2007 12:57:55 -0500, "Steven **"
<[EMAIL PROTECTED]> wrote:
> They're not available to anyone yet.
> 
> -Steven
> 

I don't believe that is entirely true, given that they are on the third
revision of GTA02 and I believe Thomas Wood has posted about working on
both a GTA01 and a GTA02.

now, 'anyone' may be a _very_ small group of select people, but I think
some people have access to it.

rgds,
j.
> On 10/15/07, Francesco Pistillo <[EMAIL PROTECTED]> wrote:
>>
>> In my work group we need two phones GTA02v3. They say in the wiki that
> it
>> can be available in october to qualified developers.
>> How is the way to be "classified" qualified developers? Who to ask for?
>>
>> Francesco Pistillo
>> Computer science department
>> Bari University
>> Italy
>>
>> ___
>> 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: Bi-weekly OpenMoko community update

[Joshua Layne]

Derek Pressnall wrote:

If the gpsd falls into catagory 3 (and not 2), then for me that is ok,
as long as it is bug free, will work with updated kernels, and has a
defined api for talking to it from other apps.  In that case, I can
treat it as if I'm using a gps chip that spits out the protocal that
the daemon is spitting out. (I assume that is what the daemon is for,
to take the propriarity api on the chip and convert it to a
standards-based api).
  
gpsd does a bit more and a bit less than that - most chips already spit 
out NMEA 0183 sentences.  gpsd wraps these and provides a shared 
interface to the gps, so that apps don't need to bind to a comm port and 
multiple apps can leverage gps data.  gpsd will also run in some binary 
modes (SiRF and garmin, perhaps others) and will signal to switch 
between binary and NMEA modes.  Otherwise, diagnostics , gpsfake, etc...


more info (if you are interested) at http://gpsd.berlios.de

The 'bug free' is the part that I would be most worried about - often 
the bugs are only discovered after extended use, because real users are 
capable of getting machines into states that testers couldn't dream of 
:) although not so much with gpsd, which seems to be pretty robust - I 
have had problems with older versions where it did not suspend properly 
(and was extremely difficult to kill), but I never really sorted whether 
that was gpsd or something else.

Now a secondary purpose of having source availability is to study the
code to improve my programming techniques.  So having a closed gpsd
doesn't help there.  But it doesn't affect the primary purpose. (Of
course, other people have different primary purposes than me, so this
won't apply to them).
  
The core of gpsd is totally open for code review, I think the closed 
binary only applies to the gllin piece, but I could be mistaken.


Rgds,
Joshua

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

Re: Possible to add "OpenMoko" to the email title

[Joshua Layne]

On Thu, 18 Oct 2007 14:59:41 -0600, "David Shanks"
<[EMAIL PROTECTED]> wrote:
> Hi All,
> 
> New to the list and excited about the possibility of a open phone.  Still
> new so i'm mainly lurking for now.
> 
> I suppose this is directed to the list moderators/admins.
> I was wondering if there is a way to have "openmoko" or some list
> descriptor
> like "community" added in front of the subject of the emails sent out by
> the
> list.
> It would make sorting my emails much simpler, as right now i'm forced to
> sort my mailbox by hand daily.
> 
I don't know what you are using to sort your incoming mail, but in exim,
this is very simple.  If you are using a 'real' user account, simply set up
a .forward in your home directory with the following contents:

---
if
  $header_to: CONTAINS "lists.openmoko.org"
or
  $header_cc: CONTAINS "lists.openmoko.org"
then
 save $home/Maildir/.Listservs.openmoko/ # use your own path
 finish
endif
---

HTH,
josh


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

Re: HD8X FCC approved

[Joshua Layne]

Adam wrote:

Sorry if this has been posted before.


FCC:
http://www.phonescoop.com/phones/fcc_query.php?gc=EUN&pc=HXD8V2

http://wiki.openmoko.org/wiki/HXD8

It is called "Dash Express."  http://dash.net/ instead of dash.org

"NameDash Express
Screen  4.3" 480x320 WQVGA
Flash3 GB
CPU Samsung s3c2440 SoC @ 400 MHz (Source)
SDRAM   128MB
GSM GSM, GPRS (Calypso solution)
GPS SirfStar III GPS,
OS  Dash Linux
USB Standard USB 1.1 (unpowered), with a Mini-B receptor (can be
   connected via adapter to both host and client devices)
Battery 2200 mAh

The form factor doesn't look like it would make a very good phone :P

yes... i know I've looked at the dash previously - this was the 
first I saw that it is the HXD8 - thanks for the link.


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

Re: Community Update

[Joshua Layne]

On Wed, 31 Oct 2007 12:01:30 -0500, Adam <[EMAIL PROTECTED]> wrote:
> The current neo1973 is not FCC approved to operate in the 850Mhz band.
> It would be illegal for FIC to sell the device in the US with it
> activated.  BT and PCS is the only approved band currently.
> 
> http://www.phonescoop.com/phones/fcc_query.php?gc=EUN&pc=GTA01BV4
> 

This is actually a little disconcerting, if true (and I looked at the FCC
site, I agree with your assessment, I just hope we're wrong)

_many_ areas in the US only have 850MHz GSM coverage - including my commute
to-from work, IIRC.  That would unfortunately be a deal-breaker for me in
the GTA02.

This is only for the GTA01BV4 though, I assume the GTA02 will have separate
FCC approval.

interesting site - I imagine this is where the initial news on the iphone
leaked... :P


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

Re: Community update: The 850 MHz issue

[Joshua Layne]

I hate to add to the fire on this one, but no 850 is a definite deal 
breaker.
No quad-band is a serious limitation, as it has been marketed since 
inception as a quad-band phone.  I'm not sure that I am willing to spend 
$450 for a non-world phone.


Regards,
joshua
Tupshin Harper wrote:
FWIW, I was planning on buying a GTA02 as soon as its available, but 
no 850 is a deal breaker since I would be using it on AT&T's network 
in California. I would certainly be willing to buy it without 900MHZ 
support, though.


-Tupshin

Michael Shiloh wrote:
Unfortunately, this also affects the GTA02, which is now far too 
close to production to try to enable quad-band operation.


An 850/1800/1900MHz variant has been suggested but this is not yet 
determined.


Michael


Randall Mason wrote:
Will the GTA02 have the quad band board (full working quad band 
capabilities to end users)?


On 11/5/07, *Michael Shiloh* < [EMAIL PROTECTED] 
> wrote:


Hello Community,

I've just arrived in Taiwan and have figured out the quad band 
issue.


The chipset is capable of quad band but the board was laid out 
to only
support 3 bands. So, 850Mhz is not supported on the GTA01 board. 
Instead

we support 900/1800/1900MHz.

Anyone interested in more details is welcome to email me.

Michael

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




--
Randall Mason
[EMAIL PROTECTED] 


 



___
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 community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community update: The 850 MHz issue

[Joshua Layne]

On Mon, 05 Nov 2007 17:37:39 -0800, Joshua Layne <[EMAIL PROTECTED]>
wrote:
> I hate to add to the fire on this one, but no 850 is a definite deal
> breaker.
> No quad-band is a serious limitation, as it has been marketed since
> inception as a quad-band phone.  

I see now that the openmoko.com page has been updated to state that it is a
tri-band phone, not a quad-band phone - last night it clearly stated quad
band.

I just wish this had been clearly identified 3 or 4 months ago.




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

Re: developing C/C++ applications for OpenMoko -- where do we stand?

[Joshua Layne]

On Mon, 12 Nov 2007 09:10:18 -0800, "Ron K. Jeffries" <[EMAIL PROTECTED]>
wrote:
> *** I HOPE I AM W-R-O-N-G!!! ***
> But this issue needs some discussion.
> 
> 
> Emre Turkay says below, (in essence)
> 
> --developing scripts for OpenMono is relatively easy
>   GOOD!
> 
> -- writing C/++ OpenMoko apps is very difficult to almost impossible.
>   BIG PROBLEM...
> 
> As an interested onlooker I want OpenMoko to not
> only survive but thrive, I am concerned that this project may
> not be able to reach critical mass.
> 
> If what Turkay says about the OpenMoko development platform
> is approximately correct, this project may be doomed.
> How can we be this far down the road without enough
> documentation that a larger group of developers can successfully
> write C/C++ apps for OpenMoko?
> 
I believe the core of this perceived issue is the cross-dev environment, as
most developers are not developing on native armv5te platforms.

There are libraries for the openmoko 'widgets' that have been produced
(openedhand).  Otherwise, I woul dimagine it is very similar to developing
in any other gtk+ environment.

The development environment uses openembedded - a monotone repository using
bitbake for builds - allowing for building against multiple targets from
the same source.

This *does* require learning a new tool - you have to set up an
openembeeded environment and you need to learn to write bitbake recipes to
build and deploy your project (if you use autotools, this is easy) -- at
least if you want your software to be incorporated into the main tree.

I hope this is helpful - for what it's worth, I'm not a C or C++ developer,
and I have gotten openembedded to build third-party packages that I am
personally interested in. (these third party packages are in C/C++...)

Regards,
joshua


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

question on 850... and alternate hardware hack ideas

[Joshua Layne]

So I am sure that this is a silly question and there is no way to send 
an AT command to set the TI GSM modem to use NA frequencies, but 
that is exactly the case with the telit modules (e.g. the GM862: 
http://www.sparkfun.com/commerce/product_info.php?products_id=757) -- 
AT#BND=1 sets the modem to NA: 
http://www.sparkfun.com/commerce/product_info.php?products_id=280


So, any news on this front? -- I had to ask.

Secondarily, on the alternate hardware front, has anyone thought of 
using a Nokia N810 with a telit GM862 and the USB eval board from 
sparkfun 
(http://www.sparkfun.com/commerce/product_info.php?products_id=281)? - 
yeah, it would be a $600 package by the time you were done and it would 
probably require a custom case or duct tape and a minature mule to carry 
it. but it seems like it would work. (why oh why didn't nokia include a 
gsm modem they certainly know how to...)


thoughts or flames are welcomed.

my favorite solution is still a software switchable (i.e. by AT 
commands) quad-band neo, but I am hedging my bets.


Best Regards,
joshua

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

Re: Android isn't a Java Platform - Say Hello to Dalvik

[Joshua Layne]

William Weinberg wrote:

Dear OpenMoko Friends

See the following blog about the "neat tricks" that Google performed to
sidestep Sun Java licensing requirements.

http://www.betaversion.org/~stefano/linotype/news/110/

The short of is

- Android code is written to a unique dialect of Java (super/subset)
that runs on Android's own Dalvik VM.  It's not J2ME or any other Sun
profile and apparently not subject to Sun's licensing regimes

- In doing so, Google created a new platform, better technically
perhaps, but not a Java-based platform.  This act by definition
increases fragmentation, whatever you may think of the ugly Java-based
status quo in the broader mobile market.

Your comments and reflections appreciated.
  


There are apparently good reasons for doing that type of fragmentation 
with java (although I would argue staying as close to the spec as 
possible would be better) in open source development


Bug labs details this a bit on their blog - Sun has no certification 
program for open source implementations of java, so it kind of forces 
the issue. http://www.bugblogger.com/2007/10/gpl-sun-java-tr.html


This one _may_ not just be google throwing their weight around.

regards,
joshua

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

Re: Neo1973/OpenMoko as a laptop replacement

[Joshua Layne]

Ted Lemon wrote:

On Sat, 2007-11-17 at 11:19 -0800, Michael Shiloh wrote:
  

I'd like to explore adding a head mounted display to the Neo, like the
i-glasses PC/SVGA Head Mounted Display at about $700. Would require
an 
off-board SVGA controller, which could be prototyped with a USB SVGA 
controller, assuming Linux drivers can be found.



I think when you add all the pieces together, this isn't going to be a
cost-effective solution, and it's not going to perform well either.
Head mounted displays need to get higher resolution before they're worth
the money.   What's the point of having a six-foot-tall screen in your
visual field if it's only 640x480?   And having direct access to the
frame buffer makes a big difference in performance.

I like the way you're thinking, though - if it were possible to get
WUXGA glasses, that would completely solve the portable display problem.
And I don't think it's out of the question - it's just too soon.   The
parts you'd need to make one are only just becoming available.   But
it's with this in mind that I mention the DVI output - you really don't
want to plug VGA into a display like that.

  


agreed.

meanwhile, and I am well aware that this isn't FIC/OpenMoko hardware, 
but for a portable laptop replacement, I think the upcoming Nokia N810 
is a pretty good fit.


no phone, but that's what the neo is for.

still waiting on the unification device - one handheld to rule them all.

j.

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

RDS/RBDS FM receiver (external) for traffic conditions

[Joshua Layne]

Hi All,
A lot of my personal interest is in context-aware aps (particularly with 
the embedded GPS) and (unfortunately) I spend a fair bit of time in my 
car each day.  It would be really nice to get traffic updates to the neo 
as an enhancement to any mapping/navigation programs.
and *no*, this is not a request to change the hardware - there are 
external modules that would work.


The one that looks most interesting to me is the Si4701 - available in 
the US from mouser electronics for $35.

http://www.silabs.com/usbradio for more info
The interesting thing to me is that they supply source for both the 
firmware and the GUI 
http://www.silabs.com/public/documents/software_doc/othersoftware/Microcontrollers/USB/en/AN264SW.zip
unfortunately it looks to be linked to M$ c++ extensions.  I got an 
error on missing stdafx.h when I tried to compile the RDSData.cpp file 
(which as near as I can tell comes from a M$ dev kit)


Would this be usable as reference to generate linux code 
(copyright/licensing mavens among you)?  is there any interest in this?


They claim it uses standard USBaudio for the sound and that they use the 
HID spec for control interface (which doesn't make a ton of sense to me, 
as it seems backwards, but I have not reviewed the spec).
This is also the FM chip used in the M$ Zune, but there doesn't appear 
to have been a lot of progress made on the linux front there.


Interested to hear your thoughts on this.

Rgds,
josh

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

Re: RDS/RBDS FM receiver (external) for traffic conditions

[Joshua Layne]

Doug Sutherland wrote:

Josh,

I have the USB FM radio stick.
A USB audio device does appear when it's plugged in.
However, there is no audio until the FM radio app is run.
This does SPI communication with the SI4701 to init
and change its settings.

  

They claim it uses standard USBaudio for the sound and that they use the
HID spec for control interface (which doesn't make a ton of sense to me,
as it seems backwards, but I have not reviewed the spec).



Why would this be backwards?
  
I have always thought of HID as using an external device that then 
communicates to the computer, this is using a virtual app on the 
computer to control an external device - I don't disagree that it is 
Human Interface.

HID is human interface, which in this case is buttons on the FM radio
GUI application, you have a stereo/mono select, volume slider, mute button,
up and down frequency tune and scan buttons, a button for configuring the
preset stations, and buttons for preset stations. What is backwards about
this? Audio is standard USB audio, controls are custom "generic USB HID".

  

This is also the FM chip used in the M$ Zune, but there doesn't appear
to have been a lot of progress made on the linux front there.



I haven't looked at the code for the FM radio application, and have no
idea about making this existing application work with linux. There is
other source code also for the evaluation board for the chips.

The FM radio stick doesn't appear to demo any RDS/RBDS capability,
at least not where I am, no station or artist/song names are appearing.

  
Interesting - they claim it does, but it may not be present in the GUI 
they provide - there certainly is code in the source they provide.
I don't think the firmware would need to be reflashed - it would just 
need the proper command.


Thanks for the detailed replies.
josh

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

Re: RDS/RBDS FM receiver (external) for traffic conditions

[Joshua Layne]

Doug Sutherland wrote:

Josh wrote:
  
I have always thought of HID as using an external device that then 
communicates to the computer, this is using a virtual app on the 
computer to control an external device - I don't disagree that it is 
Human Interface.



Aside from keyboards and mice, this idea is exactly what generic
HID is for. I have seen others that do the same. For example 
audio codec evaluation boards use generic HID communication

and have volume, balance, fader etc controls in a similar PC app.
Interestingly though, generic USB HID can also be used as just a 
simple comminication protocol between host and slave, and can

do pretty decent throughput.

  

ok, cool - thanks for the explanation.

I will look further into this, because I have some of the SI4701
chips here too, my intention was to write my own SPI code on
a different micro, so I haven't looked too closely at their source.
I was thinking about doing something better: using a micro to 
create a virtual com port, using the driverless USB ACM CDC

(communication device class), which would be translated to the
necessary SPI commands on the micro firmware, to control 
the FM tuner and to read and send the RDS/RBDS data.


This way you would have generic USB audio and generic 
USB CDC serial, and you could just open a serial port and

send commands to change stations and such, and the RDS
data would just "arrive" at the serial port.

This assume a different custom small board with SI4701 and
microcontroller, most likely an ARM7.
  


wow - that sounds like a pretty cool approach.  Not having those 
engineering skills :) I was looking to more COTS products.  I may pick 
up one of the dongles to just see if I can hack something out with my 
utter lack of C++ expertise.


Please keep the list posted on your progress and let me know if I can be 
of any help.


One of the apparent weaknesses of the Si USB dongles (from my armchair 
research) is the antenna connection - it might be nice to have a mini 
SMA or something (with the standard FM resistance -- 75 Ohms?) that 
would be robust and an adpater cable could be used to car antenna or 
such - of course, in an embedded device, the old 'headphones as antenna 
works well enough, but since this would external anyway, it might make 
more sense to allow for a 'real' antenna.


j.

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

Re: FM radio reception on neo/openmoko and some other questions

[Joshua Layne]

somehow I missed this entirely (although I know I read it)
I apologize for jumping threads and starting a new topic - it wasn't 
even a week ago

j.
Doug Sutherland wrote:

Georg wrote:
 > no only in terms of speakerphone, also the navigational software (as far
  

as there'll be one) may be connected through it.. There are a lot of
possible ways to use that extension and I personally think that it's a
very useful additional feature .



Speaking of navigation, this is interesting, Locosys makes something
called Traffic Message Channel (TMC) using the Silicon Labs
SI4701 FM tuner RDS feature to gather real-time traffic and
weather information. They use an 8051 microcontroller to read
the RDS data from SI4701 and convert it into NMEA sentence
format, which is of course, also a format used by GPS receivers.
So, if you have onboard GPS, and bolt-on FM tuner with RDS,
and some processing, you could do something similar. The NMEA
part presumably is just to make it somewhat standard, is useful
data on its own, but this is quite interesting.

http://www.locosystech.com/download/module/TMC-1513_datasheet_v1.1.pdf

I'm going to design just a very simple breakout board for the
SI4701 to start playing around with it, this RDS stuff is very
interesting. Later will make another board with SI4701 and
small microcontroller plus audio codec. Microcontroller
will read the RDS and also control/configure the FM tuner.
Analog audio output would work alone but could also input
into Neo or other application. Currently in the middle of
switching jobs and residence though, so it may be a short
while before I get any boards made.

  -- Doug


___
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: BT Laptop tether profile

[Joshua Layne]

DUN (Dial up Networking) is the standard, I believe.
That gives control to the 'laptop', whereas PAN (Personal Area Network)
really just networks the two devices and doesn't necessarily provide for
connection sharing, IIRC, but this is all from memory, so I may be quite
mistaken.

HTH,
josh

On Tue, 27 Nov 2007 14:16:25 -0700, Michael Welter
<[EMAIL PROTECTED]> wrote:
> What BT profile is used for laptop tether?
> 
> 
> ___
> 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: need someone to develop this....

[Joshua Layne]

+1

that would be sweet

On Wed, 28 Nov 2007 13:35:27 -0500, "Dean Collins" <[EMAIL PROTECTED]>
wrote:
> Lol - I love it. Fantastic.
> 
> 
> Regards,
> Dean Collins
> Cognation Pty Ltd
> [EMAIL PROTECTED] 
> +1-212-203-4357
> +61-2-9016-5642 (Sydney in-dial).
>  
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Robin Paulson
> Sent: Wednesday, November 28, 2007 1:18 PM
> To: List for OpenMoko community discussion
> Subject: need someone to develop this
> 
> ok, it's pointless, stupid and probably a waste of resources, but this
> has to be developed by somebody:
> 
> http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248
> 
> it's a phone app that reports the remaining battery life, when shaken,
> by making sloshing sounds - the more battery, the more 'full' it
> sounds
> 
> what a wonderfully inventive use of accelerometers
> 
> ___
> 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: Development env *on* the neo?

[Joshua Layne]

First, while I have done basically what you are talking about, I am now a
believer in cross compile environments, even with all their pain.  Several
years ago, I built roadmap-gtk2 on my h2200 ipaq because I couldn't then
get the cross compile environment set up.  It took over a day and locked
the system up more then once (it actually elapsed over 3 days).  The same
build takes about 15 minutes on my Epia MII 1.2GHz desktop (and that isn't
a _fast_ system - just quiet :)

Lars Hallberg wrote:
> Shawn Rutledge skrev:
>> On Dec 4, 2007 7:13 PM, Lars Hallberg <[EMAIL PROTECTED]> wrote:
>>
>>> My plan was to mount the sd card as /dev and use 'ipkg -d /dev' to
>>> install all dev related.
>>> But I'm not sure about all needed to tie it all
>>> up (PATH, lsconfig etc).
>>
>> Maybe ipkg -d takes care of some of the work for you, but I haven't
>> tried lately (seems like something was not quite right when I tried it
>> on the zaurus a while back).

ipkg-link (from ipkg-utils) does what you want (and is what I used).  I
don't know how available it is in the current images - you may need to
build it yourself.  It can bork your system a bit if you don't know what
you are doing (your system becomes dependent on that SD card, basically)
but when set up properly - it allows you to do all this stuff pretty
seemlessly.

ipkg -d by itself does nothing except install the package to that location
- if it is a library or anything else that needs to be found in a system
path, you either have to set up all the symlinks manually, or you have to
use ipkg-link.

you can install everything you want to the card (provided they are not
dependent on each other) and then run 'ipkg-link $card' (whatever your card
is) and it will link everything found on the card.

YMMV, you should be able to find packages for most if not all of what you
need in the way of libraries, compilers, etc...

Rgds,
josh



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

OT:administrivia -- a request to reduce duplicate mails

[Joshua Layne]

Hi all,
I am subscribed to several of the openmoko lists.  When someone copies
multiple lists on a message, I get all the copies (usually 3 for some
reason).  Worse, when anyone replies to the initial mail, they reply all
and I get another full set of mails.

I realize that there are valid reasons for crossposting some of the content
(particularly by core devs).  Could I request the following?

Send one email to each list (instead of copying all lists on a single
email)

it is more work, but it solves the reply-all issue, which is really what
generates the most redundant traffic.  I don't mind getting multiple copies
of the initial email.

flames, comments, etc... welcomed.

This is intentionally only posted to the community list, as it seems to be
copied on all the 'offending' emails.

Best Rgds,
Josh


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

Re: OT:administrivia -- a request to reduce duplicate mails

[Joshua Layne]

On Wed, 05 Dec 2007 22:57:54 +0100, Lars Hallberg <[EMAIL PROTECTED]> wrote:
> Joshua Layne skrev:
>> Hi all,
>> I am subscribed to several of the openmoko lists.  When someone copies
>> multiple lists on a message, I get all the copies (usually 3 for some
>> reason).  Worse, when anyone replies to the initial mail, they reply all
>> and I get another full set of mails.
>>
>> I realize that there are valid reasons for crossposting some of the
> content
>> (particularly by core devs).  Could I request the following?
>>
>> Send one email to each list (instead of copying all lists on a single
>> email)
> 
> That's a bad idea for two reasons:
> 
> 1) If the message was appropriate for cross posting, so is the
> discussion. Else we get a fragmented discussion repeating the same
> points in all lists, making thing worse for people reading all lists.
> 

ok, I didn't think that all the way through.  I agree.

> 2) If it is the same mail it is trivial for mail software to detect
> duplicates and remove them. If its different mail the problem get much
> harder to handle technically.

'trivial' might be a tad strong here :)  I, for example, have no idea how
to do this with exim4 - I have no doubt it is possible though.  I'll see
what my brain extender (aka google) turns up.

The first rebuttal was reason enough - I withdraw the 'rfc'.

thanks for the comments.
Josh


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

Re: What to use while waiting of v2?

[Joshua Layne]

On Sun, 16 Dec 2007 16:09:47 +0100, Krzysztof Kajkowski
<[EMAIL PROTECTED]> wrote:
> 
> Wiadomość napisana w dniu Dec 16, 2007, o godz 3:45 PM, przez Ben:
> 
>> I can't hold out any longer.
> 
> I'm thinking of ipod touch (the jailbreaked one) for GTD and PDA. I'm  
> using mac as my primary computer and ipod touch seems to be a nice  
> companion to my MacBook :) Although I would wait until February when  
> the SDK for it appears if I was you.
> 
I bought a Nokia N810 - the software is still kinda beta in some ways and a
lot of apps haven't made it over.  o-hand's 'Contacts' is what I am waiting
for most.  Haven't tried to sync anything yet - only imported vCards, so I
can't really comment on that.  It is a nice little bit of gear though.

I'm still potentially in the market for a neo too, provided the 850 MHz
band issue gets sorted, but 3G would be really nice (I know it won't happen
this round, no flames necessary).  I may choose freedom (mostly) on my
tablet with higher-speed bandwidth on a non-free phone.

josh


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

Re: Network questions

[Joshua Layne]

On Sat, 22 Dec 2007 21:15:50 -0500, "Nick Guenther" <[EMAIL PROTECTED]>
wrote:
> On Dec 22, 2007 12:38 PM, Nicolas Linkert <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I am geting confused with the network settings:
>>
>> - my PC has IP 192.168.0.2
>> - my router has IP 192.168.0.1
>> - my printer has IP 192.168.0.10
>>
>> Now I am, supposed to set usb0 to 192.168.0.202. Does that work with my
>> current configuration? Or do I need to have
>>
>> 192.168.0.100 PC
>> 192.168.0.101 router
>> 192.168.0.102 printer
>> 192.168.0.200 usb0
>> 192.168.0.202 phone
> 
> You're probably getting confused because you don't realize that your
> PC will have *two* IPs. The network card with .2 is different then the
> network interface that the neo presents. The PC will have two
> addresses: .2 (ethernet) and .200 (usb0) and the neo has .202 (it
> already has it, in the default configuration).
> You will also have to make sure the PC is bridging packets from usb0
> to the other interfaces. The details of how to do this depend on your
> OS.. it sounds like you have Ubuntu?

so standard disclaimer here: I am not an expert on this.

...but, it seems like setting up the proper subnet masks will be more
difficult if the 'normal' network (his existing) and the usb network
(ethernet gadget) for the neo are on the same 192.168.0.0/24 network.  I
know it can be subdivided beyond that by using different address masks. but
is this really handled natively with the standard iptables rules that one
finds via google, etc?

After changing usb and device IPs from their default for a while, I ran
into a conflict with an internal address range at work (when I connect over
VPN) and so moved my entire network to 10.x.x.x, which (thankfully) never
seems to get used for this stuff.

Am I totally wrong on this?

Regrds,
Josh


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

Re: New screen?

[Joshua Layne]

Matthew S. Hamrick wrote:

Actually...

I'm pretty sure this is the same screen we're using on the "myPhone" 
project, and it's actually quite usable.


The 4.3" 480x272 has the advantages that:

* it's a tad cheaper than the 3.8" 640x480 screen, way cheaper in 
volume

* it has slightly better color
* there seems to be a metric butt-load of them in the supply chain


* it is widescreen (16x9) :P
I finally got mplayer working on my myPhone (albeit only for a few 
seconds at a time), and it's actually quite a nice screen for videos.
not that I don't have enough projects, but google is giving a lot of 
stuff that I don't think is the myphone project - I know it is a bit off 
topic for this list, but could you send me a link to the 'home'?


Much appreciated.
josh

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