Re: dbus moving into kernel?

[Tilman Baumann]

Patryk Benderz wrote:
> Dnia 2010-09-16, czw o godzinie 17:23 +0100, Al Johnson pisze:
>> kdbus is proof-of-concept at the moment, the idea being to reduce the
>> number
>> of context switches needed for each dbus message. One synthetic
>> benchmark
>> shows a 3x speed increase on the n900 but speedup in real world
>> applications
>> seems much more modest.
>
> There are a lot of complaints about Dbus IPC. That makes me wonder why
> people don't use one of already existing kernel IPCs [1][2] , and
> instead try to develop another one, which is not secure as I heard?
> [1] http://tldp.org/LDP/lpg/node7.html
> [2] http://tldp.org/LDP/tlk/ipc/ipc.html

Actually, netlink comes to mind as a transport layer for something like dbus.
It can not all that dbus can, but most of those so called features are
actually a total wank anyway. At least it would scale.
But I suppose this discussion was lost when dbus was new and it is
pointless these days. Dbus will probably have a successor some day, and
with any luck it will have more sane foundations...

Actually, dbus is not that bad. Some of the things it can do require a
approach like they took. Question is, should we have sacrificed those
features on the alter of simplicity? I'm not even sure I have a answer to
that...

Regards
 Tilman Baumann

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

Re: GNU/Linux Wrist Watch

[Tilman Baumann]

Jon 'maddog' Hall wrote:

> BUT
>
> the battery life was pathetic, and it was rather clunky looking, and it
> still could not make a telephone call, so it was never produced.
>
> BUT
>
> technology moves forward, and someday.

Indeed. Some month ago a bought a wrist watch phone for 199 USD just for
the fun of it. It is not terribly clunky, has bluetooth and even a
(video)camera and stereo mp3 player via bluetooth.

But no Linux or any smart Operating system for that matter. :(
But it shows, technology is there. I'm just not the right person for a non
smart phone with limited user interfaces.

Regards
 Tilman Baumann

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

Re: [WikiReader] French Image

[Tilman Baumann]

Tilman Baumann wrote:
>
> David Reyes Samblas Martinez wrote:
>> 2009/12/1 Thomas HOCEDEZ :
>>> No, I didn't. What would be the interest to do so ?
>> it generate the index from the final filesto be able to search them
>> correctly generating a hash file that must be included, in the image
>> directory:
>> $../host-tools/has-gen/has-gen --fnd=pedia.fnd --pfx=pedia.pfx
>> --hsh=pedia.hsh
>
> I suspect there is still something wrong with my modification to the
> script.


Indeed there was. I forgot to append the parser output instead I overwrote
it.

see
http://github.com/tbaumann/wikireader/commit/e5f95508476b34c6c381fa5fec16f1986010f5b4

Now it is much much better. But unfortunately still not 100% correct.

At least one link/keyword points to the wrong article.
I found the problem with the "Walt Kelly" keyword which points to a jpeg
file article.

I suppose if we skip articles we have to also remove them from the index?
I will investigate this, but I have little time and my python foo is weak.

Regards
 Tilman Baumann



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

Re: [WikiReader] French Image

[Tilman Baumann]

David Reyes Samblas Martinez wrote:
> 2009/12/1 Thomas HOCEDEZ :
>> No, I didn't. What would be the interest to do so ?
> it generate the index from the final filesto be able to search them
> correctly generating a hash file that must be included, in the image
> directory:
> $../host-tools/has-gen/has-gen --fnd=pedia.fnd --pfx=pedia.pfx
> --hsh=pedia.hsh

I suspect there is still something wrong with my modification to the script.

Building of my German wikipedia finally finished, but it does not work
correctly.
No link or even search points to the right article. Some articles are not
even found.

I removed all files that started with pedia* and copied the following
files from my image dir on it.
pedia0.dat  pedia0.idx-tmp  pedia.fnd  pedia.hsh  pedia.idx  pedia.pfx


Any ideas?
I think I jinxed the PARSER_COMMAND and it re-writes the output file every
time I restart it. But to test that I need two or three days again. :)

Regards
 Tilman Baumann


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

Re: [WikiReader] French Image

[Tilman Baumann]

Thomas Hocedez wrote:
> Hi people.
>
> I manage to generate a French image for the wikireader .. but it is not
> usable. A sad "Failed to load article " is always displayed.
> My image strangely a single 1.4Go file ... any idea ?

> I'm regenerating an image. using lasts scripts. We'll see tomorrow.
>
> Tilmasn did you manage to generate something good ?

Unfortunately not. I'm building in a virtual machine. So it's slow. :)
And I still missed a bug in the code. The programme does not terminate
correctly because I left crap in the cleanup routine.
Damn runtime errors after 10 hours or so. :)

Keep you posted...


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

Re: [WikiReader] Sharing compiling sources.

[Tilman Baumann]

I realized that it does not apply to the latest version.
So I took the liberty of making a fork on github and merged it.
http://github.com/tbaumann/wikireader

I think I cracked the nut, but have a look if you would be so kind.
I'm not sure I completely got it.

(Please ignore the first commit. I did not test correctly before checking
in. :-/ )

Regards
 Tilman Baumann


David Reyes Samblas Martinez wrote:
> Here you have :)
>
> David Reyes Samblas Martinez
> http://www.tuxbrain.com
> Open ultraportable & embedded solutions
> Openmoko, Openpandora,  Arduino
> Hey, watch out!!! There's a linux in your pocket!!!
>
>
>
>
> 2009/11/30 Tilman Baumann :
>> Hi,
>>
>> can you maybe release this as a patch?
>> I like to inegrate this in github. But I fear I might miss something if
>> I
>> try to fiddle out the changes by hand.
>>
>> Thanks
>>
>> David Reyes Samblas Martinez wrote:
>>> Sorry for the wait Thomas,
>>> I was working to solve the broken pipe issue that stops the parser
>>> when it finds an error. I have applied a quick and dirty workaround
>>> using try-catch technique and now the process will not stop  and just
>>> skip the faulty article and keeps going :) it logs the faulty ones in
>>> a text file (title and position) for posterior forensics, but my first
>>> guesses in that is not a codification issue with utf8 is more an
>>> unexpected formating tag the php parser don't know how to deal with
>>> Actually parsing the german wikipedia with more than 1.3 million
>>> articles
>>>
>>> Count: 1043000
>>> Failing count: 2
>>>
>>> and keeps going I supose we can sacrificate two articles for having
>>> one milion available now :)
>>>
>>> as you requested I uploaded my working compiled tools[1]  but without
>>> any xml sources it's about 113Mb, but if you have a working tools on
>>> your system you just have to change
>>> host-tools/offline-renderer/ArticleParser.py by the attached on this
>>> mail and you can forget to cry like a child that his ice cream has
>>> fall to the floor when after more than 24h parsing hundred of thousand
>>> articles pased the process you see this ugly python error backtrace
>>> blablabla and not your desired file :)
>>>
>>> by the way the faultyarticles.txt is saved at same
>>> host-tools/offline-renderer directory, (i'm too lazy to put a
>>> parameter for change that and I hardcoded the name of the file ,
>>> yes... don't waste typing on correct that bad habit, I know)
>>>
>>> If you have curiosity of what articles on the german wiki are causing
>>> troubles
>>> on dewiki-latest-pages-articles.xml (date 2009-11-20)
>>>
>>> ~Storck Bicycle
>>> 832673
>>> ~Musculus serratus posterior inferior
>>> 857334
>>>
>>> Regards I hope I will upload the German wikipedia on Sunday... and
>>> will be available on Monday, sorry for the wait but my Asymmetric DSL
>>> is very asymmetric and upload 1.5-2 Gb (expected file size) will take
>>> a bunch of hours.
>>>
>>> For those than wants to compile his own , go for it :) the
>>> Quickreference in the doc directory on the souce is all you need to
>>> start working,  just remember than if you have a 64 bit system you
>>> will have to follow the 64 bits method to compile the tools,
>>>
>>> Regards
>>> [1]http://tuxbrain.org/downloads/wikireader/wikireaderbinaries20091127_dsamblas_modified_trycatch.tar.bz2
>>> David Reyes Samblas Martinez
>>> http://www.tuxbrain.com
>>> Open ultraportable & embedded solutions
>>> Openmoko, Openpandora,  Arduino
>>> Hey, watch out!!! There's a linux in your pocket!!!
>>>
>>>
>>>
>>>
>>> 2009/11/27 Thomas HOCEDEZ :
>>>> Thomas HOCEDEZ a écrit :
>>>>>
>>>>> Hi DAvid,
>>>>>
>>>>> Can you share your scripts & configs to do the same in French (and
>>>>> other
>>>>> languages) ?
>>>>> Thanks
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>
>>>> As the Mailing list seems to be broken (or users started hibernating
>>>> for
>>>> winter...) I find by myself the way to compile things step by step.
>>>> I'm for now rendering the French Wikipedia. As it started a few
>>>> minutes
>>>> ago,
>>>> the result will be availabel during the weekend (I hope).
>>>>
>>>> I'll also post the way I managed to do so ! (I'm at the office for
>>>> now,
>>>> and
>>>> I'm leaving...)
>>>>
>>>> Regards to you all !
>>>>
>>>> Thomas
>>>>
>>> ___
>>> 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: [WikiReader] Sharing compiling sources.

[Tilman Baumann]

Actually the tar file seems to be broken. So much for potentially missing
stuff. ;)

Tilman Baumann wrote:
> Hi,
>
> can you maybe release this as a patch?
> I like to inegrate this in github. But I fear I might miss something if I
> try to fiddle out the changes by hand.
>
> Thanks
>
> David Reyes Samblas Martinez wrote:
>> Sorry for the wait Thomas,
>> I was working to solve the broken pipe issue that stops the parser
>> when it finds an error. I have applied a quick and dirty workaround
>> using try-catch technique and now the process will not stop  and just
>> skip the faulty article and keeps going :) it logs the faulty ones in
>> a text file (title and position) for posterior forensics, but my first
>> guesses in that is not a codification issue with utf8 is more an
>> unexpected formating tag the php parser don't know how to deal with
>> Actually parsing the german wikipedia with more than 1.3 million
>> articles
>>
>> Count: 1043000
>> Failing count: 2
>>
>> and keeps going I supose we can sacrificate two articles for having
>> one milion available now :)
>>
>> as you requested I uploaded my working compiled tools[1]  but without
>> any xml sources it's about 113Mb, but if you have a working tools on
>> your system you just have to change
>> host-tools/offline-renderer/ArticleParser.py by the attached on this
>> mail and you can forget to cry like a child that his ice cream has
>> fall to the floor when after more than 24h parsing hundred of thousand
>> articles pased the process you see this ugly python error backtrace
>> blablabla and not your desired file :)
>>
>> by the way the faultyarticles.txt is saved at same
>> host-tools/offline-renderer directory, (i'm too lazy to put a
>> parameter for change that and I hardcoded the name of the file ,
>> yes... don't waste typing on correct that bad habit, I know)
>>
>> If you have curiosity of what articles on the german wiki are causing
>> troubles
>> on dewiki-latest-pages-articles.xml (date 2009-11-20)
>>
>> ~Storck Bicycle
>> 832673
>> ~Musculus serratus posterior inferior
>> 857334
>>
>> Regards I hope I will upload the German wikipedia on Sunday... and
>> will be available on Monday, sorry for the wait but my Asymmetric DSL
>> is very asymmetric and upload 1.5-2 Gb (expected file size) will take
>> a bunch of hours.
>>
>> For those than wants to compile his own , go for it :) the
>> Quickreference in the doc directory on the souce is all you need to
>> start working,  just remember than if you have a 64 bit system you
>> will have to follow the 64 bits method to compile the tools,
>>
>> Regards
>> [1]http://tuxbrain.org/downloads/wikireader/wikireaderbinaries20091127_dsamblas_modified_trycatch.tar.bz2
>> David Reyes Samblas Martinez
>> http://www.tuxbrain.com
>> Open ultraportable & embedded solutions
>> Openmoko, Openpandora,  Arduino
>> Hey, watch out!!! There's a linux in your pocket!!!
>>
>>
>>
>>
>> 2009/11/27 Thomas HOCEDEZ :
>>> Thomas HOCEDEZ a écrit :
>>>>
>>>> Hi DAvid,
>>>>
>>>> Can you share your scripts & configs to do the same in French (and
>>>> other
>>>> languages) ?
>>>> Thanks
>>>>
>>>> Thomas
>>>>
>>>>
>>>
>>> As the Mailing list seems to be broken (or users started hibernating
>>> for
>>> winter...) I find by myself the way to compile things step by step.
>>> I'm for now rendering the French Wikipedia. As it started a few minutes
>>> ago,
>>> the result will be availabel during the weekend (I hope).
>>>
>>> I'll also post the way I managed to do so ! (I'm at the office for now,
>>> and
>>> I'm leaving...)
>>>
>>> Regards to you all !
>>>
>>> Thomas
>>>
>> ___
>> 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: [WikiReader] Sharing compiling sources.

[Tilman Baumann]

Hi,

can you maybe release this as a patch?
I like to inegrate this in github. But I fear I might miss something if I
try to fiddle out the changes by hand.

Thanks

David Reyes Samblas Martinez wrote:
> Sorry for the wait Thomas,
> I was working to solve the broken pipe issue that stops the parser
> when it finds an error. I have applied a quick and dirty workaround
> using try-catch technique and now the process will not stop  and just
> skip the faulty article and keeps going :) it logs the faulty ones in
> a text file (title and position) for posterior forensics, but my first
> guesses in that is not a codification issue with utf8 is more an
> unexpected formating tag the php parser don't know how to deal with
> Actually parsing the german wikipedia with more than 1.3 million articles
>
> Count: 1043000
> Failing count: 2
>
> and keeps going I supose we can sacrificate two articles for having
> one milion available now :)
>
> as you requested I uploaded my working compiled tools[1]  but without
> any xml sources it's about 113Mb, but if you have a working tools on
> your system you just have to change
> host-tools/offline-renderer/ArticleParser.py by the attached on this
> mail and you can forget to cry like a child that his ice cream has
> fall to the floor when after more than 24h parsing hundred of thousand
> articles pased the process you see this ugly python error backtrace
> blablabla and not your desired file :)
>
> by the way the faultyarticles.txt is saved at same
> host-tools/offline-renderer directory, (i'm too lazy to put a
> parameter for change that and I hardcoded the name of the file ,
> yes... don't waste typing on correct that bad habit, I know)
>
> If you have curiosity of what articles on the german wiki are causing
> troubles
> on dewiki-latest-pages-articles.xml (date 2009-11-20)
>
> ~Storck Bicycle
> 832673
> ~Musculus serratus posterior inferior
> 857334
>
> Regards I hope I will upload the German wikipedia on Sunday... and
> will be available on Monday, sorry for the wait but my Asymmetric DSL
> is very asymmetric and upload 1.5-2 Gb (expected file size) will take
> a bunch of hours.
>
> For those than wants to compile his own , go for it :) the
> Quickreference in the doc directory on the souce is all you need to
> start working,  just remember than if you have a 64 bit system you
> will have to follow the 64 bits method to compile the tools,
>
> Regards
> [1]http://tuxbrain.org/downloads/wikireader/wikireaderbinaries20091127_dsamblas_modified_trycatch.tar.bz2
> David Reyes Samblas Martinez
> http://www.tuxbrain.com
> Open ultraportable & embedded solutions
> Openmoko, Openpandora,  Arduino
> Hey, watch out!!! There's a linux in your pocket!!!
>
>
>
>
> 2009/11/27 Thomas HOCEDEZ :
>> Thomas HOCEDEZ a écrit :
>>>
>>> Hi DAvid,
>>>
>>> Can you share your scripts & configs to do the same in French (and
>>> other
>>> languages) ?
>>> Thanks
>>>
>>> Thomas
>>>
>>>
>>
>> As the Mailing list seems to be broken (or users started hibernating for
>> winter...) I find by myself the way to compile things step by step.
>> I'm for now rendering the French Wikipedia. As it started a few minutes
>> ago,
>> the result will be availabel during the weekend (I hope).
>>
>> I'll also post the way I managed to do so ! (I'm at the office for now,
>> and
>> I'm leaving...)
>>
>> Regards to you all !
>>
>> Thomas
>>
> ___
> 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: [Wikireader] Error on processing the German Wikipedia

[Tilman Baumann]

David Reyes Samblas Martinez wrote:
> Don't hold your breath :( failing at Count: 832000

Same error as I?

> David Reyes Samblas Martinez
> http://www.tuxbrain.com
> Open ultraportable & embedded solutions
> Openmoko, Openpandora,  Arduino
> Hey, watch out!!! There's a linux in your pocket!!!
>
>
>
>
> 2009/11/20 Tilman Baumann :
>>
>> David Reyes Samblas Martinez wrote:
>>> Well spanish one give me the same error before but now it works,
>> Any idea what solved it? Or is it just random and will go away if I try
>> it
>> again? :)
>>
>>> I'm parsing the de wikipedia right now (Count: 173000) lets see whats
>>> happens :)
>>
>> I would definitely be interessted in the results...
>>
>>> Note:Parsing the 2009-Nov-11
>>> http://download.wikipedia.org/dewiki/latest/dewiki-latest-pages-articles.xml.bz2
>>>
>>> Regards
>>>
>>> David Reyes Samblas Martinez
>>> http://www.tuxbrain.com
>>> Open ultraportable & embedded solutions
>>> Openmoko, Openpandora,  Arduino
>>> Hey, watch out!!! There's a linux in your pocket!!!
>>>
>>>
>>>
>>>
>>> 2009/11/20 Tilman Baumann :
>>>> Can you reproduce this with a neutral locale?
>>>>  export LC_ALL=C
>>>>
>>>> I'm at the moment trying the same. I had a lot of hickups, caused by
>>>> many
>>>> things. Among them missing tools and not enough memory.
>>>>
>>>> This is currently where I'm stuck with the German wikipedia.
>>>>
>>>> Count: 823000
>>>> Count: 824000
>>>> Count: 825000
>>>> Count: 826000
>>>> Count: 827000
>>>> Count: 828000
>>>> Count: 829000
>>>> Count: 83
>>>> Count: 831000
>>>> Count: 832000
>>>> Count: 833000
>>>> Traceback (most recent call last):
>>>>  File "./ArticleParser.py", line 203, in 
>>>>    main()
>>>>  File "./ArticleParser.py", line 168, in main
>>>>    process_article_text(title.encode('utf-8'),  f.read(length), newf)
>>>>  File "./ArticleParser.py", line 197, in process_article_text
>>>>    newf.write(text + '\n')
>>>> IOError: [Errno 32] Broken pipe
>>>> make[1]: *** [parse] Error 1
>>>> make[1]: Leaving directory
>>>> `/home/tilli/wikireader/host-tools/offline-renderer'
>>>> make: *** [parse] Error 2
>>>>
>>>> I suppose it failed somewhere in PARSER_COMMAND
>>>>
>>>>
>>>> Before that, the following steps went through without fail.
>>>> make
>>>> make DESTDIR=image WORKDIR=work
>>>> XML_FILES=dewiki-20091028-pages-articles.xml index
>>>>
>>>>
>>>> David Reyes Samblas Martinez wrote:
>>>>> After the "success" of the spanish wikipedia pending to resolve the
>>>>> indexing part, I was starting to work on the german wikipedia
>>>>> http://download.wikipedia.org/dewiki/latest/dewiki-latest-pages-meta-current.xml.bz2
>>>>>
>>>>> but it fails at first step with the following error
>>>>>
>>>>> #make DESTDIR=image WORKDIR=work
>>>>> XML_FILES=dewiki-latest-pages-meta-current.xml index parse render
>>>>> combine
>>>>>
>>>>> awk: línea ord.:1: fatal: no se puede abrir el fichero
>>>>> `work/counts.text' para lectura (No existe el fichero ó directorio)
>>>>> cd host-tools/offline-renderer && make index \
>>>>>
>>>>> XML_FILES="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml"
>>>>> RENDER_BLOCK="0" \
>>>>>
>>>>> WORKDIR="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work"
>>>>> DESTDIR="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image"
>>>>> make[1]: se ingresa al directorio
>>>>> `/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer'
>>>>> ./ArticleIndex.py  \
>>>>>
>>>>> --article-index="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/articles.db"
>>>>> \
>>>>>
>>>>> --article-offsets="/OE/Proyectos/tuxbrain/productos/wikirea

Re: [Wikireader] Error on processing the German Wikipedia

[Tilman Baumann]

David Reyes Samblas Martinez wrote:
> Well spanish one give me the same error before but now it works,
Any idea what solved it? Or is it just random and will go away if I try it
again? :)

> I'm parsing the de wikipedia right now (Count: 173000) lets see whats
> happens :)

I would definitely be interessted in the results...

> Note:Parsing the 2009-Nov-11
> http://download.wikipedia.org/dewiki/latest/dewiki-latest-pages-articles.xml.bz2
>
> Regards
>
> David Reyes Samblas Martinez
> http://www.tuxbrain.com
> Open ultraportable & embedded solutions
> Openmoko, Openpandora,  Arduino
> Hey, watch out!!! There's a linux in your pocket!!!
>
>
>
>
> 2009/11/20 Tilman Baumann :
>> Can you reproduce this with a neutral locale?
>>  export LC_ALL=C
>>
>> I'm at the moment trying the same. I had a lot of hickups, caused by
>> many
>> things. Among them missing tools and not enough memory.
>>
>> This is currently where I'm stuck with the German wikipedia.
>>
>> Count: 823000
>> Count: 824000
>> Count: 825000
>> Count: 826000
>> Count: 827000
>> Count: 828000
>> Count: 829000
>> Count: 83
>> Count: 831000
>> Count: 832000
>> Count: 833000
>> Traceback (most recent call last):
>>  File "./ArticleParser.py", line 203, in 
>>    main()
>>  File "./ArticleParser.py", line 168, in main
>>    process_article_text(title.encode('utf-8'),  f.read(length), newf)
>>  File "./ArticleParser.py", line 197, in process_article_text
>>    newf.write(text + '\n')
>> IOError: [Errno 32] Broken pipe
>> make[1]: *** [parse] Error 1
>> make[1]: Leaving directory
>> `/home/tilli/wikireader/host-tools/offline-renderer'
>> make: *** [parse] Error 2
>>
>> I suppose it failed somewhere in PARSER_COMMAND
>>
>>
>> Before that, the following steps went through without fail.
>> make
>> make DESTDIR=image WORKDIR=work
>> XML_FILES=dewiki-20091028-pages-articles.xml index
>>
>>
>> David Reyes Samblas Martinez wrote:
>>> After the "success" of the spanish wikipedia pending to resolve the
>>> indexing part, I was starting to work on the german wikipedia
>>> http://download.wikipedia.org/dewiki/latest/dewiki-latest-pages-meta-current.xml.bz2
>>>
>>> but it fails at first step with the following error
>>>
>>> #make DESTDIR=image WORKDIR=work
>>> XML_FILES=dewiki-latest-pages-meta-current.xml index parse render
>>> combine
>>>
>>> awk: línea ord.:1: fatal: no se puede abrir el fichero
>>> `work/counts.text' para lectura (No existe el fichero ó directorio)
>>> cd host-tools/offline-renderer && make index \
>>>              
>>> XML_FILES="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml"
>>> RENDER_BLOCK="0" \
>>>              
>>> WORKDIR="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work"
>>> DESTDIR="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image"
>>> make[1]: se ingresa al directorio
>>> `/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer'
>>> ./ArticleIndex.py  \
>>>              
>>> --article-index="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/articles.db"
>>> \
>>>              
>>> --article-offsets="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/offsets.db"
>>> \
>>>              
>>> --article-counts="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/counts.text"
>>> \
>>>              
>>> --prefix="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image/pedia"
>>> /OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml
>>> Traceback (most recent call last):
>>>   File "./ArticleIndex.py", line 611, in 
>>>     main()
>>>   File "./ArticleIndex.py", line 172, in main
>>>     limit = processor.process(f, limit)
>>>   File
>>> "/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer/FileScanner.py",
>>> line 141, in process
>>>     if '#' == body[0] and 'redirect' == body[1:9].lower():
>>> IndexError: string index out of range
>>> Flushing databases
>>>

Re: [Wikireader]Compling from source fails

[Tilman Baumann]

I had many failed attempt on Fedora.
After I went to ubuntu it pretty much worked throughout the toolchain and
kernel compiling steps. (Ok I had to install tons of dependencies)

 Tilman

jcolb...@netins.net wrote:
> I have followed the instructions on
> http://wiki.github.com/wikireader/wikireader/building-from-source
> .
>
> I run make mbr, trying to make a new flash.rom file to
> change the boot splash image. It runs for a long time and
> then fails at this point.
> It creates an mbr.elf file, but no flash.rom .
>
> c33-epson-elf-ld: region a0ram is full (menu.elf section
> .rodata)
> make[1]: *** [menu.elf] Error 1
> make[1]: Leaving directory
> `/home/jcolbert/wikireader-wikireader-4e90213/samo-lib/mbr'
> make: *** [mbr] Error 2
>
> Any ideas or help?
>
> Thanks
> Jeff
>
> ___
> 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: [Wikireader] Error on processing the German Wikipedia

[Tilman Baumann]

Can you reproduce this with a neutral locale?
 export LC_ALL=C

I'm at the moment trying the same. I had a lot of hickups, caused by many
things. Among them missing tools and not enough memory.

This is currently where I'm stuck with the German wikipedia.

Count: 823000
Count: 824000
Count: 825000
Count: 826000
Count: 827000
Count: 828000
Count: 829000
Count: 83
Count: 831000
Count: 832000
Count: 833000
Traceback (most recent call last):
  File "./ArticleParser.py", line 203, in 
main()
  File "./ArticleParser.py", line 168, in main
process_article_text(title.encode('utf-8'),  f.read(length), newf)
  File "./ArticleParser.py", line 197, in process_article_text
newf.write(text + '\n')
IOError: [Errno 32] Broken pipe
make[1]: *** [parse] Error 1
make[1]: Leaving directory
`/home/tilli/wikireader/host-tools/offline-renderer'
make: *** [parse] Error 2

I suppose it failed somewhere in PARSER_COMMAND


Before that, the following steps went through without fail.
make
make DESTDIR=image WORKDIR=work
XML_FILES=dewiki-20091028-pages-articles.xml index


David Reyes Samblas Martinez wrote:
> After the "success" of the spanish wikipedia pending to resolve the
> indexing part, I was starting to work on the german wikipedia
> http://download.wikipedia.org/dewiki/latest/dewiki-latest-pages-meta-current.xml.bz2
>
> but it fails at first step with the following error
>
> #make DESTDIR=image WORKDIR=work
> XML_FILES=dewiki-latest-pages-meta-current.xml index parse render
> combine
>
> awk: línea ord.:1: fatal: no se puede abrir el fichero
> `work/counts.text' para lectura (No existe el fichero ó directorio)
> cd host-tools/offline-renderer && make index \
>   
> XML_FILES="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml"
> RENDER_BLOCK="0" \
>   
> WORKDIR="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work"
> DESTDIR="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image"
> make[1]: se ingresa al directorio
> `/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer'
> ./ArticleIndex.py  \
>   
> --article-index="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/articles.db"
> \
>   
> --article-offsets="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/offsets.db"
> \
>   
> --article-counts="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/work/counts.text"
> \
>   
> --prefix="/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/image/pedia"
> /OE/Proyectos/tuxbrain/productos/wikireader/wikireader/dewiki-latest-pages-meta-current.xml
> Traceback (most recent call last):
>   File "./ArticleIndex.py", line 611, in 
> main()
>   File "./ArticleIndex.py", line 172, in main
> limit = processor.process(f, limit)
>   File
> "/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer/FileScanner.py",
> line 141, in process
> if '#' == body[0] and 'redirect' == body[1:9].lower():
> IndexError: string index out of range
> Flushing databases
> Writing: files
> Time: 0s
> Writing: articles
> Time: 0s
> Writing: offsets
> Time: 0s
> Loading: articles
> Time: 0s
> Loading: offsets and files
> Time: 0s
> make[1]: *** [index] Error 1
> make[1]: se sale del directorio
> `/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer'
> make: *** [index] Error 2
>
> Regards
>
> David Reyes Samblas Martinez
> http://www.tuxbrain.com
> Open ultraportable & embedded solutions
> Openmoko, Openpandora,  Arduino
> Hey, watch out!!! There's a linux in your pocket!!!
>
> ___
> 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: WikiReader - first impressions

[Tilman Baumann]

Hi Sean,

I was playing around a bit with the sources on github lately. I have
stumbled over some issues.
I know I can go to c...@thewikireader.com (and I will)
But I guess we should have a mailing list for software aspects of
WikiReader...

Just a thought. :)

Sean Moss-Pultz wrote:
> Hi Torfinn
>
> Really appreciate your feedback. My comments are inline:
>
> On Tue, Nov 10, 2009 at 5:48 AM, Torfinn Ingolfsen 
> wrote:
>>
>> Hello,
>>
>> After a few days with the WikiReader, here are my first impressions:
>> The obvious things:
>> - good size: this device is small enough to drag along (ok, it won't fit
>> in my trouser pockets), but has a big enough screen to read on
>> comfortably
>> - use in places: I knew about the "missing" backlight. I can read the
>> WikiReader while commuting (most tram's have good lighting), but on the
>> other hand it is difficult in a "cosy" cafe, because the lighting is not
>> s good there.
>> - scrolling: this works great, even better than I thought. One friend
>> asked: how do I get to the next page, but was happy with scrolling after
>> I told him to use that instead.
>
> Are you running the latest kernel? (The way to tell is if you have
> kinetic scrolling, yes == latest kernel)
>
>   
> http://cloud.github.com/downloads/wikireader/wikireader/kernel-2009-10-30.zip
>
> Scrolling is really really good there.
>
>> - history: it's there when I turn on the device - and I like that.
>> - the search button removes the on screen keyboard so I can scroll on
>> the search screen. Yes! I like that.
>
> That's another fun "random" like way of searching.
>
>> The questions:
>> - search screen: where is the "delete word and start over" button? (this
>> was the first question I got from two friends trying the device)
>
> You can hold down the backspace key. It will delete the word extremely
> fast. We're working on a few minor UI changes for the next release.
> Clear will be more obvious.
>
>> - why isn't there a back button? Sure, I can use the history button and
>> select from the list (and that works quite well), but a back button
>> would save one keypress
>
> We didn't want to add another button. We might use left to right
> swipes in a later release. Not sure yet...
>
>> Annoyances:
>> - it is impossible (for me at least) to take out the microSD card
>> without using a tool (pliers or something). Why do I want to take it
>> out? To actually show people the small size of a Wikipedia database. :-)
>
> Push it in and it will pop out (beware it will *really* pop sometimes)
>
>> - the buttons on the on screen keyboard is a bit small for my fingers
>> (it is easy to press the character left or right of the one I want). I
>> don't know how to solve this yet.
>
> Software. If you've used an iPhone, the keypad is 70% of WikiReader's
> size. And typing is a lot better. So just bear with us. We're working
> on this big time.
>
>> - sometimes, the history screen is unresponsible, I have to press the
>> other two buttons a couple of times before I can select anything on the
>> history screen
>
> Working on this, too...
>
>> small annoyances:
>> - the moment it takes to display an article (after selecting it, either
>> from the search screen or from a link) is just long enough that the
>> device feels a bit slow sometimes.
>
> Same as my last comment :)
>
>> Some things I haven't figured out yet:
>> - how do I get another Wikipedia (for example the Norwegian one) onto a
>> MicroSD card?
>> - how do I convert an e-book and put it onto a microSD card for the
>> device?
>
> Like David said, we encourage you to check out github.com/wikireader for
> now.
>
>> All in all - I really like this device.
>
> Great. We love to hear this!
>
>   -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: [wikireader] Images on the WR not so imposible :P [was [wikireader]Error on parsing the spanish wikipedia]

[Tilman Baumann]

David Reyes Samblas Martinez wrote:

>> But having maps, flags, schematics and other low dynamic stuff makes
>> total
>> sense.
> I see the flags more problematic than van Gough ... a lot of them
> relies on colors to diferentiate each other so italian,french,irish,
> and all the miriad trhee vertical colors flags will be very hard
> differentiable

You see that effect on cheap newspaper prints. They have fairly large 1bit
pixels. It works good enough.
It's ugly for pictures. But very well for diagrams or anything like that.

You won't have absolute colours but that still works well.

>> PPS: Apropos SVG. I guess we can keep them as some kind of vector format
>> to save space.
> With the sizes we are talking abuout (3-4Kb once compressed), rarely a
> svg will be smaller than this, and I think reder a vector image is
> more resouce hungry than just a plain bitmap, but if the device can
> hold it it can be awesome as map viewer :)

True. 1 bit images are probably smaller then vector graphics. What would
be a miss could maybe 'scrolling' (Paging)





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

Re: [wikireader] Images on the WR not so imposible :P [was [wikireader]Error on parsing the spanish wikipedia]

[Tilman Baumann]

Rui Miguel Silva Seabra wrote:
> On Tue, Nov 03, 2009 at 12:15:11PM +0100, David Reyes Samblas Martinez
> wrote:

>> Also some way to not infringe the authoring and licencing text
>> includings clauses must be used by the images viewer. but I guess it
>> can be done by links to text as other wikipage more.
>
> The problem isn't so much about WikiMedia or OpenMoko, but that the
> original authors did not free the images.
>
> As such, whilst maybe they can be on Wikipedia, which is on a non-profit
> environment, distributing on the WikiReader (which is for-profit) may
> be legally problematic.

I'm not sure if this is a desired workflow. But I don't think whis will be
a problem if everybody builds his own wikireder offline database.

Meaning, Wikireader ships and maintains a database with all safe content.
And if you like more you do it yourself.

PS: I think it would be a good idea to only use pics with low dnamic in
the first place. There is no use to have a van Gough on a 1bit low res
screen.
But having maps, flags, schematics and other low dynamic stuff makes total
sense.
I especially think about the huge amount of svg content.
I imagine, that this can be fairly easily detected. (Maybe just simply by
compression factor)

PPS: Apropos SVG. I guess we can keep them as some kind of vector format
to save space.

PPPS: We need a mailinglist

 Tilman


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

Re: [WikiReader] Hardware

[Tilman Baumann]

Thomas HOCEDEZ wrote:
> Hi folks,
>
> I opened my WR this weekend and I took some pictures for those who wants :
> http://freerunner.daily.free.fr
>
> I was really surprised to see a little connector (not soldered) which is
> exactly a mini USB !
> I soldered it, plugged it on my desktop and ... TADA !! ..nothing, nada,
> keutch, queudalle  "lsusb" is totally quiet ...
> If someone have informations about this plug,  and the other "jtag" plug
> (on more than the one present near batteries).
> I think there will be rough hacking those future nights.

I'm not sure what you are talking about.

The software is free. http://github.com/wikireader (Can't see any caviats
if there are any)
If you look at it you will notice that is not running a OS in the regular
sense. Especially not a full blown OS with a USB stack like Linux.
The software is fully loaded from SD card. As far as I understand you can
compile anything you like and get it booted from SD.

http://github.com/wikireader/wikireader/blob/master/samo-lib/00ReadMe.text

I suppose you can create a usb stack. And I think a usb-storage mode would
be fantastic to update the SD contents.
If you find out if it has a battery charger you could maybe even charge
the device via usb...

The gist. Wikireader is not anything like the Neo. It's very minimalistic.

Regards
 Tilman


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

Re: Rod Whitby (MokoMakefile author) moves on to start WebOS Internals

[Tilman Baumann]

Thank you anyway. Traitor! :)
And ROFL about the northern hemisphere chauvinism issue with your GPS. *g*
I hope that is not a omen...

See you back ;)

Rod Whitby wrote:
> http://www.rwhitby.net/blog/webos-internals/palm-pre-lands-in-australia.html
>
> It is with some sadness that I must say goodbye to the OpenMoko
> community, and move on to new things.
>


-- 
MFG
 Tilman Baumann


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

RE: [SHR] Setting regional codes

[Tilman Baumann]

Sorry I missed the whole thread. Need to read it all in a free minute.
Sorry if I spam you with irrelevant stuff. But my post to dial plans and
number cannonification from last year might be interesting for you guys.

http://www.mail-archive.com/de...@lists.openmoko.org/msg00073.html

There was much discussion on that thread. But the conclusion is, if you
know your dialplan (internationalPrefix, longDistancePrefix and
countryCode) you can transform every local number into the full
international form +xxyyz

And from that, if you would like you can transform it back by applying
your dial plan. But there is of course not much need for that on cell
networks.

Regards
 Tilman

Niels Heyvaert wrote:
>
>>> + should be an alias to 00 if at the beggining of a number. This usage
>>> of +
>>> is so common and international that it would be IMHO dumb to
>>> intentionally
>>> ignore it.
>>
>> Not only that, but I intentionally store all my numbers in the +
>> (usually +31...) format, since not every country has 00 as its
>> international prefix!
>>
>> If you look at http://www.kropla.com/dialcode.htm, there is a whole
>> list of IDD codes, and there are lots of 'em that aren't 00...
>>
>> I'm looking forward to having full number recognition, since I now
>> regularly have to 'mentally lookup' a number when it's calling me...
>>
>> Christ van Willegen
>> --
>
> Adding my observations to the mix:
>
> I haven't changed any of the phone settings and store all my phone numbers
> in the international format (with '+' sign). In the config file the
> default country code is set to 49, which is different from my actual
> country code.
>
> Incomming calls and messages map very nice to the contact names.
>
> I haven't received any international calls or text messages since I've
> started using SHR-U, but will keep an eye on it.
>
> Niels.
> _
> Reageer op foto’s van je vrienden en bekijk hun reacties op de jouwe.
> Gegarandeerd hilariteit!
> http://www.microsoft.com/belux/nl/windows/windowslive/products/photos.aspx
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


-- 
MFG
 Tilman Baumann


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

Re: One second Openmoko boot?

[Tilman Baumann]

On 21 Aug 2009, at 18:10, Edder wrote:

> On Fri, Aug 21, 2009 at 6:52 PM, Michal  
> Brzozowski wrote:
>> 2009/8/21 Tilman Baumann 
>>>
>>> Remember, there is almost absolutely no use case for total shutoff  
>>> and
>>> suspend to 'Disk' since you want your GSM to stay on line on  
>>> suspend. And
>>> for that everything but past resume from RAM is useless.
>>
>> There are many use cases if you're on battery for an extended  
>> period (for
>> example when traveling) and don't need the GSM to be online all the  
>> time.
>>
>> There have been a few occasions where suspend to disk would have  
>> helped me,
>> assuming reasonable wakeup time. But I understand I'm in the  
>> minority.
>>
>
> I would also like suspend to disk and agree that there are a number of
> use cases when it is very practical. For example I am often out of the
> country for a weekend. Often it is not practical to recharge the phone
> during that time and it would be a lot easier if I could just suspend
> to disk and quickly check for missed msgs every couple of hours or so.

Well yea, but it's a phone after all. :)
I would be really interested how long the phone would survive on the  
deepest not off sleep possible (No radio, all chips possible shut  
off). That could beat system to disk I would expect.

>
> Maybe I am biased because I also always suspend my laptop to disk, so
> know from experience how nice it is to be able to quickly boot up :)

Your laptop would probably survive for three month on suspend to  
RAM. ;-)

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

Re: One second Openmoko boot?

[Tilman Baumann]

Michael 'Mickey' Lauer wrote:
> On Friday 21 August 2009 16:36:07 Helge Hafting wrote:
>> Now, implement suspend-to-disk (SD-card), and you can start
>> reasonably quick after changing the battery.
>
> It should take around 40 seconds to read the memory back from SD, so if
> you
> can live with that, implementing suspend-to-disk might be interesting.

I like the hybrid suspend method that is used by apple (and possibly others)

They do suspend to RAM for fast resume. But also do suspend to disk. And
if the battery runs out (or is yanked out for replacement) the system
comes up again from disk.

It would be neat to have. If it is easy.

Remember, there is almost absolutely no use case for total shutoff and
suspend to 'Disk' since you want your GSM to stay on line on suspend. And
for that everything but past resume from RAM is useless.

Resume speed is in my eyes just not a issue. Boot speed is something else.
The only reason to boot a phone is if it crashed, ran out of battery or
kernel update.
Avoiding reboots seems to be the answer for me.
Not that it would be cool it it could boot faster. But any modern
smartphone has horrendous boot times this day.

How long could a phone on a almost empty battery survive after it has shut
off all radios and gone into standby?
We could maybe have some 'survival' mode to make it to the next charger
without shutting off.
If that is worth it at all.

> Still I prefer working on the actual boot process, since getting away from
> booting like a PC will also have positive effects on memory consumption
> and
> battery lifetime.

+1
Booting after init still takes ages. I don't know, but it seems to be a IO
throughput problem rather then CPU speed. Maybe more compression can help?
Just a hunch, I'm basically clueless.
And of course delaying stuff.

What I would wish for is quicker GSM login. I think have the latest
firmware, but SHR still takes ages after the phone is fully booted until
it is on line.

-- 
MFG
 Tilman Baumann


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

Re: Replacement battery for GTA01/Neo

[Tilman Baumann]

Gerald A wrote:
> Hi,
> Looking at my Neo this morning, I noticed that it looked like the case
> wasn't put back on straight.

My GTA01 Battery was always a bit bulgy from the beginning.
If you feel it has become worse quickly, be afraid. :)

-- 
MFG
 Tilman Baumann


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

Re: Tangogps or navit with prepackaged Europe map

[Tilman Baumann]

arne anka wrote:
>> basically a memory format and as far as I can read it mmappable.
>
> i never looked into navit's source code.
> the train of thought was simply:
> small file -> highly compressed information -> increased cpu usage while
> extracting.

No it is more like optimised computer readable format versus human
readable very redundand and bloated format. *g*

-- 
MFG
 Tilman Baumann


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

Re: Tangogps or navit with prepackaged Europe map

[Tilman Baumann]

arne anka wrote:
>> Since the 'bin' format is a .zip file with lots of smaller files in
>> it, unzipping the (europe).zip file won't grow the data much...
>
> that's actually quite interesting! it never occured to me to analyze the
> resulting file.
> so, which map format would be faster -- navit or osm?
> the same map in osm being far bigger suggests somehow that less cpu is
> necessary ...
I'm not sure I'm getting the point here.
But the navit format is binary and the osm format is (zipped) xml.
The navit binfile format is clearly more economical.
osm files contain redundant informations and the xml needs to be parsed
and built into a in memory structure (i guess) and the binfile format is
basically a memory format and as far as I can read it mmappable.


-- 
MFG
 Tilman Baumann


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

Re: Tangogps or navit with prepackaged Europe map

[Tilman Baumann]

btw. if you consider it.
The reiseplaner maps are great. But at least on my GTA01 (64MB) it does
not really work well because navit becomes unusabely slow.

http://wiki.navit-project.org/index.php/European_maps#Marco_Polo_Grosser_Reiseplaner

Would be interesting to see how it does on a gta02...

Tilman Baumann wrote:
>
> Laszlo KREKACS wrote:
>> Dear List,
>>
>> Is anyone aware of any images, with prepacked maps with tangogps or
>> navit?
>> Im going to travel in the next days across Europe, and a gps device
>> would be handy.
>> I have a spare 2G uSD card. So some ready-made uSD image would be
>> extremely cool.
>>
>> I only need the map and gps, no phone functionality is required.
>>
>> Any ideas?
>
> Navit has support for that kind of use. But I don't think you can get a
> europe opkg package quite yet.
>
> But there is a template how to throw a little xml snipped into some
> directory (included in the mapset esction of navit.xml). Just poit it to
> your sd card where your europe.bin is.
>
> I can't give you a exact description sinc ei don't have a openmoko phone
> at hand right now. But the wiki tells you how to get osm maps and the
> default config shows you how to integrate it.
>
> --
> MFG
>  Tilman Baumann
>
>
> _______
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


-- 
MFG
 Tilman Baumann


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

Re: Tangogps or navit with prepackaged Europe map

[Tilman Baumann]

Robin Paulson wrote:
> 2009/5/28 arne anka :
>> don't know about any images. but with a map for all of europe 2gb is
>> pretty little.
>> it certainly won't work with tangogps -- once i tried to get all of
>> germany in a usable resolution for tangogps and it exceed by far 2gb.
>> so, your best bet would be navit with its binary maps which are much
>> smaller for the same are covered.
>>
>> ho to fetch a map for a selected area is described in the navit wiki (in
>> short: wget an url with the coordinates), and there are even a lot of
>> links at osm where others have put together more or less regularyl
>> updated
>> binary map files of several regions of the world.
>
> cloudmade.com provide ready to go navit maps - the one for new zealand
> was 4 megabytes; i imagine germany won't be too much bigger

ROFL. I see, the Kiwis have some catching up to do with their OSM
coverage. :)

Europe ~550MiB
Germany ~250MiB
http://wiki.navit-project.org/index.php/OpenStreetMaps#Getting_a_pre-processed_planet.osm
-- 
MFG
 Tilman Baumann


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

Re: Tangogps or navit with prepackaged Europe map

[Tilman Baumann]

Laszlo KREKACS wrote:
> Dear List,
>
> Is anyone aware of any images, with prepacked maps with tangogps or navit?
> Im going to travel in the next days across Europe, and a gps device
> would be handy.
> I have a spare 2G uSD card. So some ready-made uSD image would be
> extremely cool.
>
> I only need the map and gps, no phone functionality is required.
>
> Any ideas?

Navit has support for that kind of use. But I don't think you can get a
europe opkg package quite yet.

But there is a template how to throw a little xml snipped into some
directory (included in the mapset esction of navit.xml). Just poit it to
your sd card where your europe.bin is.

I can't give you a exact description sinc ei don't have a openmoko phone
at hand right now. But the wiki tells you how to get osm maps and the
default config shows you how to integrate it.

-- 
MFG
 Tilman Baumann


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

Re: Launcher/Home Page (Proof of concept) Working Release

[Tilman Baumann]

I think this is so far focused on SHR.

Warren Baird wrote:
> so - the question I have - should this be a separate app - or should this
> be
> considered a proposal for the new Paroli UI?
>
> I think the intent of Paroli was to be a proper home page for OM2009,
> right?   shouldn't it provide all of the functionality this app provides?
>
>
> On Mon, May 25, 2009 at 9:57 AM, Rui Miguel Silva Seabra
> wrote:
>
>> On Mon, May 25, 2009 at 06:45:48AM -0700, c_c wrote:
>> >
>> > Hi,
>> >  22 views and no feedback? I thought this was a much needed app! Hmmm.
>>
>>
>> Shouldn't repeat functionality from Paroli (even if it's currently
>> lacking)
>> like the missed calls, and separation by f.d.o categories are way more
>> needed
>> before I'll give it a try!
>>
>> But good work so far, it looks good! :)
>>
>> Rui
>>
>> ___
>> Openmoko community mailing list
>> community@lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>
>
>
>
> --
> Warren Baird - Photographer and Digital Artist
> http://www.synergisticimages.ca
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


-- 
MFG
 Tilman Baumann


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

Re: root almighty

[Tilman Baumann]

GNUtoo wrote:
> *a free version compilable from source without "google stuff"(such as
> maps)
> I was told I had to gab source.android.com, type make and then make sdk

Yes, a hand full of Google apps are unfree.
But what I find amazing is, that they cust comply to a known api as any
other program could do. So you can in fact repace them without yinxing
usability. Even on a 'official' android device.

> so I think I'll try android...but I'll look first if it's tight to
> google services...(I'm already spied a lot using google search
> engine...I don't want to be spied more)

_that_ is a real issue for me too. I use a G1 for a while now, and I
mostely like it. Though it has serious problems.
But the fact that is not even intended not to have a google account and
not having your contacts and calendars mirrored in the google cloud is
really annoying. Not not annoying, it angers me greatly.


And Bluetooth support is a mess. No OBEX, no FTP nothing useful.
Imagine a smartphone where you can't send contacts via bluetooth! (ok,
varous OM distros don't do it out of the box too...)

-- 
MFG
 Tilman Baumann


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

Re: shr-testing timezones! responding?

[Tilman Baumann]

On 30 Apr 2009, at 15:40, jeremy jozwik wrote:

> sorry, that last post did not work right. how do i properly respond to
> mail list messages?

If your mail client does not know better, reply-to-all.

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

Re: NEW e-tasks Alpha release

[Tilman Baumann]

On 30 Apr 2009, at 02:44, c_c wrote:

>
> Hi,
>  20 odd views and no feedback? Seems like PIM apps aren't really on  
> very
> many people's radar :-)

I'm still trying to understand the UI.
PIM is second most important after phone. So, go ahead. And thank you  
for your effort. :)

But really, I did not understand how to use it yet. But hings happen  
when I press buttons. *g*

  Tilman

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

Re: [all e/illume based] copy/paste

[Tilman Baumann]

On 27 Apr 2009, at 02:07, Carsten Haitzler (The Rasterman) wrote:

> On Mon, 27 Apr 2009 00:38:20 +0200 "Marco Trevisan (Treviño)"  >
> said:
>>
>> Recent versions of Elementary include a support for easy copy/paste
>> actions. I think it's a good example that could be ported also to  
>> other
>> toolkits (wich mostly need patches, BTW).
>
> yes. just hold down your finger for a second and presto.. menu (you  
> can paste
> or begin selecting things). the selection is "malleable" ie the  
> first time when
> there is no selection you define it with a drag. but after that  
> pressing near
> the beginning or end of the selection allows you to adjust it to get  
> it right.
> press and hold again for menu to "copy" or "cut" or "cancel". cancel  
> just
> clears the selection and does nothing. copy and cut put that  
> selection in the
> copy buffer, and going anywhere else to paste will paste it.

Wow, nice! But it does only work in text edit fields.
Not for example in the sms message view text area. Feature request... ;)

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

Re: e in framebuffer?

[Tilman Baumann]

Michael 'Mickey' Lauer wrote:

>> > with e providing a
>> > reasonable
>> > windowing environment,
>>
>> Window management on plain framebuffer? Are you sure?
>> I would be very interested in learning more about this.
>> My expectation would be that you still need some fb multiplexer that
>> needs
>> to be relatively smart.
>
> This solely depends on your usecase. If you're in for
> single-window-single-app
> paradigm, combined with some clever logic to always show a panel, then you
> don't really need window management.

Yes, but this really means always only one app _running_. (or drawing)

This would require some extensive framework and very specialised code in
the apps. (Apps need to free the fb and save the screen state and there
would be some supervision needed for managing accesses to screen
resources/and switching windows.)

I don't think we have the resources for that.
I mean, we just barely manage to make a working phone. :)

And just forget about porting apps from any other environment.

I could imagine doing this all with a evas (that rendering thingy of E, i
always confuse the names) frontend which gets instructed to draw some
scenario and connects the signals via rpc to a client...

>> Probably by rendering into a shared mem that gets composed to a fb frame
>> by some central daemon.
>
> If you do that, you quickly reinvent X ;)

My point exactly.

> Seriously though, some projects have gone that way (evoak, picogui, ...),
> but
> dropped the ball. If you really do need window managment, use X. If not,
> fb-
> only could be a very viable alternative -- if only we had illume's
> softkeyboard working...

If there is no swap out solution. I would just don't bother.

-- 
MFG
 Tilman Baumann


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

Re: e in framebuffer?

[Tilman Baumann]

c_c wrote:

>  The thought came from the fact that QTE seems faster. So, if X was
> removed
> from the equation - how would the freerunner perform?

I never felt a noticeable speed difference.

> with e providing a
> reasonable
> windowing environment,

Window management on plain framebuffer? Are you sure?
I would be very interested in learning more about this.
My expectation would be that you still need some fb multiplexer that needs
to be relatively smart.
Probably by rendering into a shared mem that gets composed to a fb frame
by some central daemon.

-- 
MFG
 Tilman Baumann


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

Re: GTA01 question : what capacity of ....

[Tilman Baumann]

Ben Wilson wrote:
> Tilman Baumann wrote:
>> Tim Niemeyer wrote:
>>
>>> Hallo wim.delvaux,
>>>
>>> * wim.delv...@adaptiveplanet.com 
>>> [24-04-09 04:16]:
>>>
>>>> I.e. if I buy a 8GB micro SD card, would the GTA01 be able to use it ?
>>>>
>>> I have never tried it, but i have heared it supports SDHC cards, but
>>> can't
>>> boot it? (Booting with Uboot???/Qi???; i don't know)
>>>
>>
>> More or less. :)
>> SDHC is no problem for Linux. But UBoot can not load a kernel from SDHC.
>> The wiki has a section how to boot a rootfs from sd and use the kernel
>> from internal flash.
>>
>> And *never ever* use Qi on GTA01. You will loose the DFU loader!
>>
>>
> It says this on the wiki
> "Booting from SDHC requires a u-boot from 2008-07-23 or later. *But pay
> attention* : there are problems with SDHC cards at suspend time."

This is GTA02

> I got it from here
> http://wiki.openmoko.org/wiki/Supported_microSD_cards
>
> Might only apply to GTA02 though.

It does. Unfortunately the ancient knowledge of GTA01 users degenerates in
the wiki. Some GTA02 only topics are not marked as such.

-- 
MFG
 Tilman Baumann


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

Re: bluetooth spam

[Tilman Baumann]

Jose Luis Perez Diez wrote:
> El Friday, 24 de April de 2009 13:48:37 Alexey Feldgendler va escriure:
>> > O group of girls answered. Was really funny.
>> > Bur did not help me to ge laied tough. :)
>>
>> Modern advances in mobile computing technologies still don't get one
>> laid.
>>   Someone needs to work on that.
>
> we need to fill a bug report then. 

And if someone stets the bug on 'WORKSFORME'?


-- 
MFG
 Tilman Baumann


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

Re: bluetooth spam

[Tilman Baumann]

Roland Whitehead wrote:
> What you haven't experienced then is "Toothing". Apparently, it's rife
> on the trains between London and Brighton (in the UK) and often ends
> up with the people toothing each other getting it together... Nothing
> to do with spam. If OpenMoko made this really easy then there'd be
> lots of new users!

Hehe, I once did this on a ICE train.
I was bored so I scanned for bluetooth devices. And then send them text
files.

O group of girls answered. Was really funny.
Bur did not help me to ge laied tough. :)

-- 
MFG
 Tilman Baumann


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

Re: GTA01 question : what capacity of ....

[Tilman Baumann]

Tim Niemeyer wrote:
> Hallo wim.delvaux,
>
> * wim.delv...@adaptiveplanet.com 
> [24-04-09 04:16]:
>> I.e. if I buy a 8GB micro SD card, would the GTA01 be able to use it ?
> I have never tried it, but i have heared it supports SDHC cards, but can't
> boot it? (Booting with Uboot???/Qi???; i don't know)

More or less. :)
SDHC is no problem for Linux. But UBoot can not load a kernel from SDHC.
The wiki has a section how to boot a rootfs from sd and use the kernel
from internal flash.

And *never ever* use Qi on GTA01. You will loose the DFU loader!

-- 
MFG
 Tilman Baumann


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

Re: Navit is not finding current position

[Tilman Baumann]

On 07.04.2009, at 09:23, Francesco de Virgilio wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Christ van Willegen ha scritto:
>> On Mon, Mar 9, 2009 at 6:55 PM, Christ van Willegen
>>  wrote:
 Any hint on this?
 What am I doing wrong?
>>> If you run Navit from the terminal, it may tell you...
>>>
>>> In my case, it seems that the libgps installed on my system is too  
>>> new.
>>>
>>> I haven't figured out how to solve this yet, but I'll let you know  
>>> if
>>> I find out.
>>
>> I got Navit to work doing the following
>> - Drop to a shell prompt on the FreeRunner (or use ssh to connect)
>> - cd /usr/lib
>> - ln -s libgps.so.17 libgps.so.16
>>
>> This makes Navit think that libgps.so.16 is installed.
>>
>> Note: This may work for Navit for now, but may break other programs.

Pardon!? Yes it is hackish and ugly and potentially not stable.
But there is just no way how it could break other apps that are  
correctly linked. And wrongly linked apps might work which they did  
not before.

>>
>
> If someone has used this solution, could confirm me that TangoGPS
> continued to work? I'm trying this in my SHR-testing, but I don't want
> any breakage.

Com on. People who don't understad what this command does should not  
use a developer phone or should not tinker with it.



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

Re: GPS emergency call standards

[Tilman Baumann]

Harald Welte wrote:
> On Tue, Feb 24, 2009 at 12:06:20PM +0100, Tilman Baumann wrote:
>> Hi,
>>
>> I'm just wondering if there are any open standards for emergency  
>> services for location.
>> I'm thinking about services like http://www.steiger-stiftung.de  
>> (European, websites in other languages should be available)

I have asked them. They are basically not prepared to share any 
information on details.
It is somehow a service they provide, but how it is implemented is unknown.

Reply to my question if I might have some information to make my phone 
use their service, the answer was 'there are many phones which support 
us...'
Yes, and I want to become one of them. But this is to much to ask from 
them. Stupid fuckers.
I'm sure they did not even understand what I was asking. :-/

eCall seems to be a more open system, but still no real informations to 
find. And it as a slightly different focus too.

>>   A SMS to the respective emergency (112, 911) number containing the  
>> GPS position could be a start, but then someone has to read it.
>> I would guess there is a standard for a computer readable format.
>>
>> Building a emergency call app would be a nice thing to have.
>>
>> PS: According to Wikipedia, 112 works on all GSM networks no matter if  
>> the number is a emergency number in tie state.
> 
> that depends on what the network operator does.

Yep, but there seems to be some international agreement on the 
significance of 112.
I don't have any quote yet, but as far as I understood it is even 
required to by the GSM standards. But that might be wrong.

> The SIM card has a list of
> emergency numbers.  If you call one of those numbers, or make an emergency
> call without a SIM card inserted, the phone will do itts request for a 
> physical
> channel indicating its a EMERGENCY call, and then use EMERGENCY SETUP instead
> of SETUP, so the network can decide to rather kill somebody elses call and 
> free
> resources for your emergency call in case the cell is otherwise full.

That would be a great thing to have indeed. This needs to be included in 
the (FSO) dialer/contacts framework. Including the other special numbers 
the sim has, like ones own.



-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: New SHR-Testing release

[Tilman Baumann]

Klaus 'mrmoku' Kurzmann wrote:
> Am Freitag 06 März 2009 16:43:47 schrieb Tilman Baumann:
>> Klaus 'mrmoku' Kurzmann wrote:
>>> Am Freitag 06 März 2009 11:13:41 schrieb Tilman Baumann:
>>>> Klaus 'mrmoku' Kurzmann wrote:
>>>>> Am Freitag 06 März 2009 10:47:20 schrieb Tilman Baumann:
>>>>>> Klaus 'mrmoku' Kurzmann wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> for those of you who didn't see the blog on Openmoko-Planet or read
>>>>>>> the SHR Mailinglist... We did publish new testing images.
>>>>>> Time for re-install by image or is opkg upgrade safe?
>>>>> See the announcement :-) upgrading from old shr-testing does not
>>>>> work... Sombody even tried it me thinks. Changing the repo config and
>>>>> upgrading from shr- unstable is supposed to work though.
>>>> Oh, sorry. I was a bit unclear.
>>>>
>>>> I was on unstable before and I intend to stay on the bleeding edge.
>>>> (Or at least see where that brings me...)
>>>>
>>>> Question is, what will happen if I do nothing.
>>>> Is the new unstable a clean continuation of the old unstable or does it
>>>> break updates?
>>> It still is a clean continuation... that might change though some day.
>> Something is odd with this repo. :)
>> See below.
>>
>> Looks like the repository is broken.
>>
> 
> you catched the moment while building with a new EFL_SRCREV :-) while 
> building 
> the packages already built are there, but the index not yet...

Sorry to further pollute this thread.
I successfully upgraded.
No my desktop is completely empty. No icons whatsoever.

-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: New SHR-Testing release

[Tilman Baumann]

Klaus 'mrmoku' Kurzmann wrote:
> Am Freitag 06 März 2009 17:14:41 schrieb Tilman Baumann:
>> Or maybe not, I just remember that our admin has enabled a transparent
>> proxy. That might give me the old index...
> that would indeed be bad then :-)

Indeed. Luckily there was a alternative route which I could use.

-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: New SHR-Testing release

[Tilman Baumann]

Klaus 'mrmoku' Kurzmann wrote:
> Am Freitag 06 März 2009 16:43:47 schrieb Tilman Baumann:
>> Looks like the repository is broken.

> you catched the moment while building with a new EFL_SRCREV :-) while 
> building 
> the packages already built are there, but the index not yet...
> 
> That might happen quite frequently in shr-unstable ;)

Updating the feed should be more atomic. If I might say so.
I would suggest uploading in a temp dir and then moving it on the right 
location.
Or uploading dirs with build numbers and after finished just symlinking 
the new build on the default location. That would not break anyone 
currently in the process of upgrading.

> Build has finished now and upgrade should work.

Oddly not. Still same error after update,uprade.
Is there sill anything uploading?

Or maybe not, I just remember that our admin has enabled a transparent 
proxy. That might give me the old index...

-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: New SHR-Testing release

[Tilman Baumann]

Klaus 'mrmoku' Kurzmann wrote:
> Am Freitag 06 März 2009 11:13:41 schrieb Tilman Baumann:
>> Klaus 'mrmoku' Kurzmann wrote:
>>> Am Freitag 06 März 2009 10:47:20 schrieb Tilman Baumann:
>>>> Klaus 'mrmoku' Kurzmann wrote:
>>>>> Hi all,
>>>>>
>>>>> for those of you who didn't see the blog on Openmoko-Planet or read the
>>>>> SHR Mailinglist... We did publish new testing images.
>>>> Time for re-install by image or is opkg upgrade safe?
>>> See the announcement :-) upgrading from old shr-testing does not work...
>>> Sombody even tried it me thinks. Changing the repo config and upgrading
>>> from shr- unstable is supposed to work though.
>> Oh, sorry. I was a bit unclear.
>>
>> I was on unstable before and I intend to stay on the bleeding edge.
>> (Or at least see where that brings me...)
>>
>> Question is, what will happen if I do nothing.
>> Is the new unstable a clean continuation of the old unstable or does it
>> break updates?
> It still is a clean continuation... that might change though some day.

Something is odd with this repo. :)
See below.

Looks like the repository is broken.

I had to disable the /etc/opkg/armv4-feed.conf feed.
(src/gz shr-armv4 http://shr.bearstech.com/shr-unstable/ipk//armv)
Since it always produced 404. But that should not have anything to do 
with that.

(shortened output)
r...@om-gta01 ~ $ opkg upgrade
Upgrading python-ecore on root from 0.3.1+svnr38274-ml0 to 
0.3.1+svnr39379-ml0...
Downloading 
http://shr.bearstech.com/shr-unstable/ipk//armv4t/python-ecore_0.3.1+svnr39379-ml0_armv4t.ipk
Upgrading libecore-evas on root from 2:0.9.9.050+svnr38274-r1 to 
2:0.9.9.050+svnr39379-r1...
Downloading 
http://shr.bearstech.com/shr-unstable/ipk//armv4t/libecore-evas_0.9.9.050+svnr39379-r1_armv4t.ipk
Upgrading libevas-engine-buffer on root from 2:0.9.9.050+svnr38274-r1 to 
2:0.9.9.050+svnr39379-r1...
Downloading 
http://shr.bearstech.com/shr-unstable/ipk//armv4t/libevas-engine-buffer_0.9.9.050+svnr39379-r1_armv4t.ipk
Upgrading libehal0 on root from 2:0.5.0.050+svnr38274-r1 to 
2:0.5.0.050+svnr39379-r1...
..
Collected errors:
  * Failed to download 
http://shr.bearstech.com/shr-unstable/ipk//armv4t/python-ecore_0.3.1+svnr39379-ml0_armv4t.ipk,
 
error 404
  * Failed to download python-ecore. Perhaps you need to run 'opkg update'?
  * Failed to download 
http://shr.bearstech.com/shr-unstable/ipk//armv4t/libecore-evas_0.9.9.050+svnr39379-r1_armv4t.ipk,
 
error 404
  * Failed to download libecore-evas. Perhaps you need to run 'opkg update'?
  * Failed to download 
http://shr.bearstech.com/shr-unstable/ipk//armv4t/libevas-engine-buffer_0.9.9.050+svnr39379-r1_armv4t.ipk,
 
error 404
  * Failed to download libevas-engine-buffer. Perhaps you need to run 
'opkg update'?
  * Failed to download 
http://shr.bearstech.com/shr-unstable/ipk//armv4t/libehal0_0.5.0.050+svnr39379-r1_armv4t.ipk,
 
error 404
  * Failed to download libehal0. Perhaps you need to run 'opkg update'?
..


-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: New SHR-Testing release

[Tilman Baumann]

Klaus 'mrmoku' Kurzmann wrote:
> Am Freitag 06 März 2009 11:13:41 schrieb Tilman Baumann:
>> Or should I just go testing anyway because unstable is really not
>> intended for real use?
> Well... if you need it as a phone you should switch to testing. We intend to 
> do 
> some big changes that most definitely will lead to a not working phone in the 
> beginning. If you just want something to play with and do not depend on it as 
> your daily phone... thats different then :-)
> 
> Or you could do what most of us SHR devs do... Have them both. One in flash 
> and 
> one on SD.
Oh, good idea.
-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: New SHR-Testing release

[Tilman Baumann]

Klaus 'mrmoku' Kurzmann wrote:
> Am Freitag 06 März 2009 10:47:20 schrieb Tilman Baumann:
>> Klaus 'mrmoku' Kurzmann wrote:
>>> Hi all,
>>>
>>> for those of you who didn't see the blog on Openmoko-Planet or read the
>>> SHR Mailinglist... We did publish new testing images.
>> Time for re-install by image or is opkg upgrade safe?
> See the announcement :-) upgrading from old shr-testing does not work... 
> Sombody 
> even tried it me thinks. Changing the repo config and upgrading from shr-
> unstable is supposed to work though.

Oh, sorry. I was a bit unclear.

I was on unstable before and I intend to stay on the bleeding edge.
(Or at least see where that brings me...)

Question is, what will happen if I do nothing.
Is the new unstable a clean continuation of the old unstable or does it 
break updates?

Or should I just go testing anyway because unstable is really not 
intended for real use?

-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: New SHR-Testing release

[Tilman Baumann]

Klaus 'mrmoku' Kurzmann wrote:
> Hi all,
> 
> for those of you who didn't see the blog on Openmoko-Planet or read the SHR 
> Mailinglist... We did publish new testing images.

Time for re-install by image or is opkg upgrade safe?

-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: GSM Buzz fix also applicable to GTA01?

[Tilman Baumann]

Joerg Reisenweber wrote:

>>
>> So my question is basically if the GTA02 buzz fix works for me and is it 
>> reasonable to think that I need it?
>> Maybe it can really be fixed with a better alsa state file.

> I'll answer more detailed questions on HW-ML (as you can tell from delay I 
> read [community] rather infrequent).
Oh, good to know. I did not know that hardware topics have a seperate list.
I have the same problem with the community list. Too much noise, too 
much unimportant.

> Basically the answer is: yes applies to GTA01 as well.
> And no we don't think buzz can be fixed by better statefile neither on gta02 
> nor on gta01.
Does this mean you have a solution for me? Or maybe some upcoming?
Or only a conformation that it needs to be fixed too?
-- 
Imagination is more important than knowledge.
  Albert Einstein

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

GSM Buzz fix also applicable to GTA01?

[Tilman Baumann]

I have the feeling my GTA01 would also need the buzz fix.
Especially in high antenna power situations I have quite substantial 
buzzing.
That might be new, since I have never seen this before, but I only 
lately started to use my GTA01 as my main phone, I was more of a land 
line type before.

So my question is basically if the GTA02 buzz fix works for me and is it 
reasonable to think that I need it?
Maybe it can really be fixed with a better alsa state file.

GTA02 and GTA01 seem to differ quite substantially in regard to board 
layout, but I guess the audio schematic does not so much.

-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: GPS emergency call standards

[Tilman Baumann]

Am 24.02.2009 um 12:38 schrieb Helge Hafting:

> Tilman Baumann wrote:
>> Hi,
>>
>> I'm just wondering if there are any open standards for emergency
>> services for location.
>> I'm thinking about services like http://www.steiger-stiftung.de
>> (European, websites in other languages should be available)
>>
>>  A SMS to the respective emergency (112, 911) number containing the
>> GPS position could be a start, but then someone has to read it.
>> I would guess there is a standard for a computer readable format.
>>
>> Building a emergency call app would be a nice thing to have.
>>
>> PS: According to Wikipedia, 112 works on all GSM networks no matter  
>> if
>> the number is a emergency number in tie state.
>
> If you have the gps coordinates, just tell them over the phone as you
> make the call. They will use it if they have gps eqipment, which is
> likely.

As log as you are able to do so.
I'm more thinking about something like a machine readable side channel  
paralel to a regular emergency call.

BTW. the German ADAC is completely helpless if you provide them GPS  
coordinates.

> Automating this seems dangerous in that your SMS to the
> emergency service is delayed by a few minutes as the phone struggle to
> get the first fix. When you talk, you can fall back on other
> descriptions of the place (addresses, road names) if coordinates  
> aren't
> available.

Depends, when a GPS fix is made it will be much more precise and  
quicker.

And there seems to be a standard for cars to make automatic emergency  
calls on accidents.
It is called eCall and no technical information is to be found... :)

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

GPS emergency call standards

[Tilman Baumann]

Hi,

I'm just wondering if there are any open standards for emergency  
services for location.
I'm thinking about services like http://www.steiger-stiftung.de  
(European, websites in other languages should be available)

  A SMS to the respective emergency (112, 911) number containing the  
GPS position could be a start, but then someone has to read it.
I would guess there is a standard for a computer readable format.

Building a emergency call app would be a nice thing to have.

PS: According to Wikipedia, 112 works on all GSM networks no matter if  
the number is a emergency number in tie state.

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

Re: SHR-unstable, GTA01 (neo1973) and GPS?

[Tilman Baumann]

Tilman Baumann wrote:

> If nothing is broken, this should do automatically.
> fso-gpsd should fire up, which does connect to freameworkd.
> If you connect to gpsd gllin should start.
> 
> But to be honest, I had mine sitting on the shelf for some time now. But 
> the only thing it get is the GPS-Time.
I just re started tango and then it instantly had a position.
There is probably something racy...
-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: SHR-unstable, GTA01 (neo1973) and GPS?

[Tilman Baumann]

Jay Vaughan wrote:
>>> Do we still need to install the gllin package on neo1973?
>> Sure
>>> If so, how
>>> do I do it 'properly' on SHR-testing?
>> Just opkg install it.
> 
> okay it doesn't seem to be working for some reason.  the gta01 has sat  
> on the window for an hour, no fix .. FR got one in 5 minutes.
> 
> 
>> (I have my gllin package always on my SD card)
>> Rest should be taken care of by framreworkd.
>> Last time I checked, this worked with FSO and SHR.
>>
> 
> is there anything special to do with the /etc/init.d/* scripts and  
> setup of the /tmp/nmeaP file, like we used to have to do with OM?

If nothing is broken, this should do automatically.
fso-gpsd should fire up, which does connect to freameworkd.
If you connect to gpsd gllin should start.

But to be honest, I had mine sitting on the shelf for some time now. But 
the only thing it get is the GPS-Time.
But it could not be totally broken though, because at least I get the time.
But it is ondor, maybe the roof changes. It usually works pretty well in 
this spot. :)

>> But, as the flash space on GTA01 with SHR is extremely limited, you  
>> will
>> not be able to install Navit.
> 
> i opted for a SD-on-root install, with 4 gigs, so this shouldn't be an  
> issue.

Btw. Can you share how you did this? Last time I checked this u-boot did 
not find any partitions.
I have the feeling ongoing GTA02 shauvinism had let gta01 information to 
rot a bit on the wiki.

-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: SHR-unstable, GTA01 (neo1973) and GPS?

[Tilman Baumann]

Jay Vaughan wrote:
> Hiya,
> 
> Well, I got SHR-testing up and running on my neo1973 after many  
> recommendations from folks on this list and in the #openmoko channel,  
> and so far it looks pretty nice - can make calls and receive them and  
> so on, and it doesn't crash too much (after I did an opkg update 
> +upgrade), so for now at least the neo1973 seems to be useful for me  
> with SHR-testing .. except for one thing: GPS.  Can't seem to get it  
> working.
> 
> Do we still need to install the gllin package on neo1973? 

Sure
> If so, how  
> do I do it 'properly' on SHR-testing? 

Just opkg install it. (I have my gllin package always on my SD card)
Rest should be taken care of by framreworkd.
Last time I checked, this worked with FSO and SHR.

But, as the flash space on GTA01 with SHR is extremely limited, you will 
not be able to install Navit. Which is a pitty.
You might even get trouble while installing gllin, best you deinstall 
some crap before since opkg fails very very ungracefully on full file 
systems.
You may need to re flash it to get it working again in when this happens.
-- 
Imagination is more important than knowledge.
  Albert Einstein

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

Re: Buy GTA01

[Tilman Baumann]

Tilman Baumann wrote:
> arne anka wrote:
>> to whom do you prefer to sell?
>> angus or debian/fso, ie luca?
> 
> Oh, is this really a contest? Honestly I don't care much.

If anyone is interested please contact me off the list.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Buy GTA01

[Tilman Baumann]

arne anka wrote:
> to whom do you prefer to sell?
> angus or debian/fso, ie luca?

Oh, is this really a contest? Honestly I don't care much.
Angus was first on the list...

> price?

Ideally the same as a new Freerunner. *g*
Who makes the best offer?
I would be ready to invest something to upgrade to a Frerunner...

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Buy GTA01

[Tilman Baumann]

I have one.
And I would give it away if it brings me any further to a Freerunner 
which I would not buy right now.

Angus Ainslie wrote:
> Does anyone have a working gta01 they'd like to sell ?
> 
> Please message me of list if you do.
> 
> Thanks
> Angus
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Yaouh! out (update for tangogps maps)

[Tilman Baumann]

Tilman Baumann wrote:
> Carlo Minucci wrote:
>> Xavier Cremaschi ha scritto:
>>> Carlo Minucci a écrit :
>>>> http://wiki.openmoko.org/wiki/Yaouh!
>>>>
>>>> i a simple interface for update the maps of tangogps
>>>> it's optimized for low band usage
>>> Just a question : how can you check the remote file without dowloading 
>>> it before ? Do you use etag [1] to do that ?
>> yes
>> etag
>>
>> i check with this:
>>
>> curl -I http://tile.openstreetmap.org/$file | grep ETag | cut -d "\"" -f 2
>>
>> do you know a better way?
> 
> Doen't python have a http lib? Calling external apps is not really the 
> fastest and safest way.
> 

Untested code:

  import httplib
  conn = httplib.HTTPConnection("tile.openstreetmap.org")
  conn.request("HEAD", "/file...")
  r1 = conn.getresponse()
  print r1.status, r1.reason
  etag = getheader("ETag")
  print etag

And if stuff was new, make GET instead of HEAD



-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Yaouh! out (update for tangogps maps)

[Tilman Baumann]

Carlo Minucci wrote:
> Xavier Cremaschi ha scritto:
>> Carlo Minucci a écrit :
>>> http://wiki.openmoko.org/wiki/Yaouh!
>>>
>>> i a simple interface for update the maps of tangogps
>>> it's optimized for low band usage
>> Just a question : how can you check the remote file without dowloading 
>> it before ? Do you use etag [1] to do that ?
> 
> yes
> etag
> 
> i check with this:
> 
> curl -I http://tile.openstreetmap.org/$file | grep ETag | cut -d "\"" -f 2
> 
> do you know a better way?

Doen't python have a http lib? Calling external apps is not really the 
fastest and safest way.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: How do you like to read a phone number?

[Tilman Baumann]

Tilman Baumann wrote:
> DIN specification for German numbers is AFAIK
> 
> +49 (1 23) 1 23 45 68
> 
> That is, area code in parentheses and each number block in sets of two, 
> but from right to left. ("1 23 45" instead of "12 34 5")

Ah, and btw. There is no fixed number length. Phone numbers can range 
from tree digits to seven and probably more.
Some countries seem to have fixed length, so that's probably important.


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: How do you like to read a phone number?

[Tilman Baumann]

DIN specification for German numbers is AFAIK

+49 (1 23) 1 23 45 68

That is, area code in parentheses and each number block in sets of two, 
but from right to left. ("1 23 45" instead of "12 34 5")

Alternative variant for area code for not fully canonical numbers is (01 
23) ... (0 prefix within the area code)


Really a pitty that there is no universal method. But I have to say, i 
like this one pretty much.

Michele Renda wrote:
> Hello to all
> 
> I would like to know how do you like to read the phone number:
> 
> I try to explain: when we read a phone number we usually like to separe 
> it with some spaces or signs:
> for example in Italy when someone give me a mobile phone number I 
> usually write:
> 
> +39 347 123456
> 
> Or if it is a fixed number:
> 
> +39 02 123456 or +39 011 123456
> 
> But I know in USA is more common something like: +1-212-123456
> 
> Please, who has some time, can you please write your country (Italy, 
> France, etc.) and the way how usually is normal to read a phone number 
> in your country (with international prefix)
> 
> The format I use to descrive is this: +39 ### * or +1-###-* (where # 
> replace a char, and * replace all remaining chars)
> 
> Thank you a lot for your time
> Michele Renda
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: [GTA01 Qi] doku fuckup and SD-Boot problems

[Tilman Baumann]

I like to wrap this topic up.

First, any idea why booting from flash does not work for me neither with 
uboot or qi?

And second, as it looks like my Qi endeavour was futile, can I use the 
following command to go back to uboot?
nandwrite -p /dev/mtd0 $u-boot-image
Or is there some magic that needs to happen?

Tilman Baumann wrote:
> Hi,
> 
> I have just flashed Qi and have two questions.
> 
> First, http://wiki.openmoko.org/wiki/Qi clearly states that the boot 
> menu via power+aux will still work.
> I was sceptical about how that should work since gta01 has no NOR flash. 
> But I trusted the source. Needless to say that there is no boot menu!
> Am I right in assuming that the wiki is just BS  in this regard?
> If that is so, I like to change the text to warn others.
> 
> And, how can I get my device in DFU-Mode now? Am I right in assuming 
> that Qi has none?
> Does this mean that when I trash my rootfs I have no way to re-flash?
> How would I write a new bootloader (or whatever) to NAND via a running 
> system?
> 
> And secondly. I did flash Qi because booting from SD with U-Boot as 
> described in the Wiki did not work for me.
> Somehow u-boot was not able to read the SD (8gb SDHC).
> (Sorry, I have no exact error message because I stopped debugging when 
> the USB console trashed my hosts USB subsystem)
> 
> I thought maybe Qi does it right.
> I have a SD with one ext2 formated partition containing the rootfs and 
> /boot/append-GTA01 and /boot/uImage-GTA01.bin
> 
> But it still always boots from NAND.
> 
> I tried /boot/append-GTA01 with rootfstype=ext2 root=/dev/mmcblk0p1 but 
> this did not work either.
> 
> Any ideas?
> 
> 
> PS: Remember GTA01! Some people seem to forget them. ;-)
> 


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: [GTA01 Qi] doku fuckup and SD-Boot problems

[Tilman Baumann]

George Brooke wrote:
> On Friday 02 January 2009 19:40:00 Tilman Baumann wrote:
>> Hi,
>>
>> I have just flashed Qi and have two questions.
>>
>> First, http://wiki.openmoko.org/wiki/Qi clearly states that the boot
>> menu via power+aux will still work.
>> I was sceptical about how that should work since gta01 has no NOR flash.
>> But I trusted the source. Needless to say that there is no boot menu!
>> Am I right in assuming that the wiki is just BS  in this regard?
>> If that is so, I like to change the text to warn others.
> 
> Maybe just to warn people that its not true on the gta01.
> I have a feeling that you may need a debug board to restore a uboot in order 
> to flash a new rootfs (I may be wrong though).

That would be bad. But I can probably write it back from my running 
system. My phone still boots from internal flash.
But I have no idea how I should do this right now. (no block dev, mtd 
tools?)

And I'm not shure if I will. I will stick with Qi when SD-Boot works. 
That would be a easy fallback if things go wrong.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

[GTA01 Qi] doku fuckup and SD-Boot problems

[Tilman Baumann]

Hi,

I have just flashed Qi and have two questions.

First, http://wiki.openmoko.org/wiki/Qi clearly states that the boot 
menu via power+aux will still work.
I was sceptical about how that should work since gta01 has no NOR flash. 
But I trusted the source. Needless to say that there is no boot menu!
Am I right in assuming that the wiki is just BS  in this regard?
If that is so, I like to change the text to warn others.

And, how can I get my device in DFU-Mode now? Am I right in assuming 
that Qi has none?
Does this mean that when I trash my rootfs I have no way to re-flash?
How would I write a new bootloader (or whatever) to NAND via a running 
system?

And secondly. I did flash Qi because booting from SD with U-Boot as 
described in the Wiki did not work for me.
Somehow u-boot was not able to read the SD (8gb SDHC).
(Sorry, I have no exact error message because I stopped debugging when 
the USB console trashed my hosts USB subsystem)

I thought maybe Qi does it right.
I have a SD with one ext2 formated partition containing the rootfs and 
/boot/append-GTA01 and /boot/uImage-GTA01.bin

But it still always boots from NAND.

I tried /boot/append-GTA01 with rootfstype=ext2 root=/dev/mmcblk0p1 but 
this did not work either.

Any ideas?


PS: Remember GTA01! Some people seem to forget them. ;-)

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Default IP Address on All Distributions

[Tilman Baumann]

One word.
zeroconf

Oh, it is two words zeroconf and bonjour

www.zeroconf.org/

PS: As fallback for DHCP of course.

Esben Stien wrote:
> Why on earth would you choose 192.168.0.*?
> 
> This is probably the most common IP address on an internal network in
> the world and of course this means problems. 
> 
> If your network is configured with this IP range and you pop a
> freerunner in, it of course cause a world of pain. Please choose a
> more sensible default.
> 


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Navit city search ?

[Tilman Baumann]

Lothar Behrens wrote:
> Hi,
> 
> has someone an example of searching a city and a street that works with 
> the germany map when it was downloaded from the quicklink
> as of the page here 
> lists: http://wiki.navit-project.org/index.php/OpenStreetMaps ?

http://wiki.navit-project.org/index.php/OpenStreetMaps#Search_doesn.27t_work_in_most_countries
and following...

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Ask Sean Moss-Pultz about community matters

[Tilman Baumann]

Name a application that you would have expected to be made by the the 
community first but not has been delivered yet?
(Something quirky but obvious or just in dire need)

Where do you think has the community let you down? Name a aerea where 
you would have expected more community thrust but has failed.

Where do you think could any person do the most for the project right 
now? Think of if that person would be ideal and have all the skills needed.
And then, which skills are in most need right now and in the future?

Minh Ha Duong wrote:
> Dear friends,
> 
>   Sean kindly agreed to be interviewed for the next edition of the Community 
> Update newsletter. I invite every subscriber of this list to post the 
> question or questions that s-he cares about most. No gloves. The general 
> topic is "Openmoko, the community, past-present-future", but yours truly will 
> select with undue care the 3-5 most interesting / provocative / popular / 
> relevant / funny / whatever and forward them to Sean next Monday. You may 
> send your questions in this mailing list thread or privately to me.
> 
> Minh
> 
> PS: Everybody knows that Sean Moss-Pultz is Openmoko CEO, but you may also be 
> interested to find that many of his past interviews are available here:
> http://wiki.openmoko.org/wiki/Openmoko:Current_events
> http://wiki.openmoko.org/wiki/Press_Coverage
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Fast screen rotate app

[Tilman Baumann]

Moritz Bitsch wrote:
> Hi,
> 
> thanks for testing.
> 
> I've fixed the build script and the desktop file. All files are now
> with PREFIX=/usr.
> 
> I also fixed the stupid dependency error.
> 
> A updated ipkg and tgz can be get from here:
> https://turmspitze.org/files/

I suppose it works now.
I'm completely baffled by another problem, which seems unrelated to your 
app. X/enlightenment or Illume sems to be broken in the recent SHR feed.
rotate does not even work with the xrandr command.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Fast screen rotate app

[Tilman Baumann]

Carlo Minucci wrote:
> Tilman Baumann ha scritto:
>> Moritz Bitsch wrote:
> 
> 
> hi
> i have made a similar application, can you test on SHR for me? :)
> you can download from http://minucci.net/file/opkg/ruotami_0.2_all.opk
> 
> thank you

Sure. But I like to point out that I'm rather biased towards mortz's 
app, because he is my colleague and his app is only a hand full of C.
So i woud probably always dig his version.

I looked at your app. Here is what i found:

1. Problem
Not all Categories in .desktop files are shown. Which distro shows which 
Categories seems to be a moving target.
I changed your categories to
Categories=Utilities;Applications;
and the icon shows up in my launcher.
I don't know if these Categoreis are documented somewhere but this is at 
least what makes it work on SHR.

2. Problem
Your program is not Neo 1973 compatible.
[EMAIL PROTECTED] ~ $ ruotami.py
Traceback (most recent call last):
   File "/usr/bin/ruotami.py", line 16, in 
 fb = open("/sys/class/backlight/pcf50633-bl/actual_brightness", "r")
IOError: [Errno 2] No such file or directory: 
'/sys/class/backlight/pcf50633-bl/actual_brightness'

I guess framework has a interface which you could use here. That would 
be the only right thing to do on FSO and SHR. (Both using frameworkd)
You could ask the FSO guys what to do here.
I would have tested your app with the right backlight path 
(/sys/class/backlight/gta01-bl/actual_brightness), if it would have been 
a single variable in your script.
But it is all over the place. No thanks... ;)

3. The real problem
And I have t say, I find your idea of manipulating the .desktop file 
absolutely revolting. Sorry.
It seems to depend on being sliped by ruotami in the first place to get 
a grip on the current rotation.

I like the idea of blanking the screen while rotating. But this needs to 
be done in some other way.

Sorry, zero points for style. ;)


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: [debian] state of enlightment and illume packaging

[Tilman Baumann]

mallikarjun arjun wrote:
> 
> 
> On Mon, Nov 24, 2008 at 3:25 AM, The Rasterman Carsten Haitzler 
> <[EMAIL PROTECTED] > wrote:
> 

> 
> 
> Hello guys, can any one of u tell me how to install e17 on debian???
> because i did not find any package when i typed apt-get install 
> enlightenment

e17 is unstable, that is why it is not in debian right now.
I have recently installed it from source, which turned out quit nicely. 
No big deal, when you have figured out where the sources are on the 
enlightenment site.

Maybe there are some unofficial debian sources somewhere, i did not 
bother searching for one because i needed sources anyway.


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Fast screen rotate app

[Tilman Baumann]

Moritz Bitsch wrote:
> Hi,
> 
> I've built a small binary package. It can be get from here:
> https://turmspitze.org/files/rotate_0.0.1_armv4t.ipk
> 
> A Source package can be get from here:
> https://turmspitze.org/files/rotate-0.0.1.tar.gz

I have just installed your package.

The prefix /usr/ is missed on all files.

opkg files rotate
Package rotate (0.0.1) is installed on root and has the following files:
/share/pixmaps/rotate.png
/share/applications/rotate.desktop
/share/license/rotate/COPYING
/bin/rotate

That should be all /usr/...

And it depends against libx11 which is at least on my distro (shr 
testing) caled libx11-6.

And the .desktop file has misses the Icon field. (Icon=rotate)
And your .Rotate name hack looks really ugly in my desktop. I would 
rather have a alphabetical order instead of this. ;)
If the odering of icons turns out to be a problem, we might need some 
Categoeries hack in the desktop launcher.

PS: Hi moritz *g*

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Survey about the Touchscreen

[Tilman Baumann]

I just want to point out that I will not vote because the vote is bullshit.

The type of the screen is not the only thing. Size and resolution 
matters too.

And even more important. Price and availability.

What you want is totally unimportant. The question is which compromises 
are you ready to make?
This is nothing that can be figured out by some stupid two options poll. 
What goes is eventually a question that can only be answered by looking 
at sold units in retrospect.
What you all want is unimportant, because you can not honestly say that 
it will bias your buying decision in a way you would admit now.

I would like openmoko to do bold steps.
But they should also be careful.


Tilman Baumann wrote:
> Vikas Saurabh wrote:
>> I think we need to decide upon this without the bias of UIone
>> might get excited with iPhone's UI.
>>
>> What we would have to remember:
>> * capacitive screen would always require a touch of finger (hence all
>> the UI elements need to take enough space on screen) so the whole fun
>> of high reso is gone
>> * otoh, pressure based screen need a little more pressure to react but
>> is often manageable with fingers as well
>>
> Agree.
> Either a really big capacitive screen with no boarders or a small hi res 
> screen as currently (I like it) with either a stylus or a keypad.
> 
> I would vote for the same screen as currently used or at least the same 
> quality but bigger and a keypad. Finger use for the current screen is 
> pretty much a failure. (not impossible but as far as text input goes 
> pretty much failed)
> 
> 
> 


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Survey about the Touchscreen

[Tilman Baumann]

Anton Persson wrote:
> Less capable in which way? We just saw that you CAN use a stylus with
> a capacitive screen, if you really need that. What other arguments are there
> for a resistive screen?

This stylus is not much smaller than a finger tip.

I will not say that capacitive is bad, but it is certainly a much bigger 
  challenge for gui development. I'm not sure we are ready for this...

And I'm not convinced that a iphone like system is the right platform 
for a really versatile smartphone.
I'm convinced that people will start to see the iphone UI as a 
limitation when the novelty factor waers off.
We should take the best from the iphone (good productive finger 
controlled apps) but we should not totally commit to this.
And I'm not sure that multi touch is really so important and the low res 
touch sensitivity of the iphone started to anoy me really fast.
Text input on a iphone is better than T9, but not really good.

We need a bigger screen that's for sure.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Survey about the Touchscreen

[Tilman Baumann]

Vikas Saurabh wrote:
> I think we need to decide upon this without the bias of UIone
> might get excited with iPhone's UI.
> 
> What we would have to remember:
> * capacitive screen would always require a touch of finger (hence all
> the UI elements need to take enough space on screen) so the whole fun
> of high reso is gone
> * otoh, pressure based screen need a little more pressure to react but
> is often manageable with fingers as well
>
Agree.
Either a really big capacitive screen with no boarders or a small hi res 
screen as currently (I like it) with either a stylus or a keypad.

I would vote for the same screen as currently used or at least the same 
quality but bigger and a keypad. Finger use for the current screen is 
pretty much a failure. (not impossible but as far as text input goes 
pretty much failed)



-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Minty Boost && FreeRunner

[Tilman Baumann]

Cédric Berger wrote:
> On Thu, Nov 20, 2008 at 15:14, Matthias Apitz <[EMAIL PROTECTED]> wrote:
>>Adding the 47k resistor to the minty boost so that the Freerunner fast
>>charges at 1A is a poor idea for a couple reasons, the biggest one being
>>that the minty boost can't supply 1A the max is 600mA. as far as I know,
>>there is no magic resistor to identify a 500mA charger to the
>>Freerunner, it depends on USB host telling it that it can provide 500mA.
> 
> 
> Yes 1A is a lot.
> I am not an electronician but would not it be possible to have a
> little circuit in the minty boost limiting current to 500mA (or other
> value), even though the freerunner "tries" to get 1A ?

Nope. Current is a effect not a cause. *g*
-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Minty Boost && FreeRunner

[Tilman Baumann]

Matthias Apitz wrote:
> El día Thursday, November 20, 2008 a las 02:04:22PM +0100, Tilman Baumann 
> escribió:
> 
>> Matthias Apitz wrote:
>>> El día Thursday, November 20, 2008 a las 01:47:43PM +0100, Tilman Baumann 
>>> escribió:
>>>
>>>> Matthias Apitz wrote:
>>>>> El día Monday, September 22, 2008 a las 11:17:58PM +0200, Matthias Apitz 
>>>>> escribió:
>>>>>
>>>>>> Hello Stacy,
>>>>>>
>>>>>> I've stumbled over your page http://www.millions.ca/~stacy/mintyboost/
>>>>>> and as an owner of the FreeRunner I will build this nice box; thanks for
>>>>>> your pioneer work on this; ...
>>>> Shouldn't it be easy to add this 'wall charger indicator resistor' to 
>>>> the mintyboost circuit?
>>>> I don't remember where that resistor needs to go, but this can be 
>>>> researched on the wiki...
>>> What would be the bennefit of this? I'm not an electronic guy anymore
>>> :-(
>> 1A charging out of the box with no software needed.
> 
> Here is what the Wiki page says:
> 
> http://wiki.openmoko.org/wiki/Neo_FreeRunner_Battery
> 
> «DIY external battery pack from a Minty case 
> Mintyboost: 
> Charge from a couple of AA batteries: Minty Boost!, report on a Neo
> FreeRunner application. 
> Adding the 47k resistor to the minty boost so that the Freerunner fast
> charges at 1A is a poor idea for a couple reasons, the biggest one being
> that the minty boost can't supply 1A the max is 600mA.

Ups, that's a pitty. I did not anticipate this.


> Even if the Linear Technology step up voltage converter is supposed to
> be able to do 600mA, the AA cells seem to have a problem with supplying
> 500mA. They get a little toasty :-). One powerpack built using D cells
> doesn't seem to have any issues with supplying 500mA.»
Well, Batteries usually put out a great much of current without 
suffering too much.
I could not find any specifications (which of course vary) on a short 
notice, but I don't think that 5W (plus a little bit loss in the 
converter) is too much.

Maybe we just need to make a heavy duty mintyboost with a bigger 
converter...

> My FR switches outomagically to 1A charging mode, but maybe it's better
> to only use 500mA

Probably. The reports of hearing the converter when it is under load 
support this.



-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Minty Boost && FreeRunner

[Tilman Baumann]

Matthias Apitz wrote:
> El día Thursday, November 20, 2008 a las 01:47:43PM +0100, Tilman Baumann 
> escribió:
> 
>> Matthias Apitz wrote:
>>> El día Monday, September 22, 2008 a las 11:17:58PM +0200, Matthias Apitz 
>>> escribió:
>>>
>>>> Hello Stacy,
>>>>
>>>> I've stumbled over your page http://www.millions.ca/~stacy/mintyboost/
>>>> and as an owner of the FreeRunner I will build this nice box; thanks for
>>>> your pioneer work on this; ...
>> Shouldn't it be easy to add this 'wall charger indicator resistor' to 
>> the mintyboost circuit?
>> I don't remember where that resistor needs to go, but this can be 
>> researched on the wiki...
> 
> What would be the bennefit of this? I'm not an electronic guy anymore
> :-(

1A charging out of the box with no software needed.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Minty Boost && FreeRunner

[Tilman Baumann]

Matthias Apitz wrote:
> El día Monday, September 22, 2008 a las 11:17:58PM +0200, Matthias Apitz 
> escribió:
> 
>> Hello Stacy,
>>
>> I've stumbled over your page http://www.millions.ca/~stacy/mintyboost/
>> and as an owner of the FreeRunner I will build this nice box; thanks for
>> your pioneer work on this; ...

Shouldn't it be easy to add this 'wall charger indicator resistor' to 
the mintyboost circuit?
I don't remember where that resistor needs to go, but this can be 
researched on the wiki...

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: new application: AaTerm-terminal (patched openmoko-terminal2)

[Tilman Baumann]

Tilman Baumann wrote:
> Aapo Rantalainen wrote:
> 
>> Tell me what is missing?

I just installed it.
> Some questions. Does it invoke the keyboard when you select the text 
> area? (illume keyboard)
Does not, pitty.
> The current terminal does not, which is rather annoying.
> And what is this copy button for, intuitively I would think there is a 
> paste button missing.
I just got the idea how that works. Not bad.



-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: new application: AaTerm-terminal (patched openmoko-terminal2)

[Tilman Baumann]

Aapo Rantalainen wrote:

> Instructions and package:
> http://www.cs.helsinki.fi/u/rantalai/freerunner/aaterm/
> 
> Tell me what is missing?
Well, looks nice. (From a user point of view)
I really like the idea of the right side toolbar.

Some questions. Does it invoke the keyboard when you select the text 
area? (illume keyboard)
The current terminal does not, which is rather annoying.
And what is this copy button for, intuitively I would think there is a 
paste button missing.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: What theme is this?

[Tilman Baumann]

Richy wrote:
> I think "hire" did create the colorful theme.
> You should be able to catch him in #openmoko-cdevel

I did. It was not him.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: What theme is this?

[Tilman Baumann]

Leonti Bielski wrote:
> Hi!
> I found this image on scap.linuxtogo.org
> http://scap.linuxtogo.org/files/cb247f8d70308d5fec6a479c329e75f3.png
> There are also some other themes.
> Where I can download it? Who is making it?
> Thanks.
> Leonti

I agree it looks nice.
And as we are on this topic. I think this theme 
http://scap.linuxtogo.org/files/4dc340d6661464ca15a0789011cdd3c6.png is 
ingenious!
I never liked the grey theme. Bright colours on black are the way to go.


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

[shr] phone apps don't work

[Tilman Baumann]

I have problems with all openmoko-* apps regarding GSM/SIM.
But strangely the GSM applet shows i have service.

I have collected some messages from the console output.
Maybe they have a common cause which i can fix.

Because i really like to use shr, because it has just the right gui and 
the right philosophy in general.

openmoko-dialer starts, bu when i press call this comes:
** (process:1401): DEBUG: initiate call: 076145CENSORED
Failed to handle dbus error: type: 
, 69 (dbus-glib-error-quark), code 32
(Sorry for bad line breaks, emails suck for this kind of info)

openmoko-contacts (dies instantly)
Trying to get the system bus
Adding signals.
** (process:1215): DEBUG: phonegui_init()
** (process:1215): DEBUG: Entering ecore loop
** (process:1215): DEBUG: phonegui_contacts_show()
** (process:1215): DEBUG: Initiated elementary
** (process:1215): DEBUG: Initiated etk
** (process:1215): DEBUG: Added exit callback to ecore.
** (process:1215): DEBUG: event_callback()
** (process:1215): DEBUG: contacts_event(), event: 0
** (process:1215): DEBUG: window_create()
** (process:1215): DEBUG: Adding delete-request-callback
** (process:1215): DEBUG: contacts_event(), event: 1

openmoko-messages (also never comes up)
Trying to get the system bus
Adding signals.
** (process:1217): DEBUG: phonegui_init()
** (process:1217): DEBUG: Entering ecore loop
** (process:1217): DEBUG: phonegui_messages_show()
** (process:1217): DEBUG: Initiated elementary
** (process:1217): DEBUG: Initiated etk
** (process:1217): DEBUG: Added exit callback to ecore.
** (process:1217): DEBUG: event_callback()
** (process:1217): DEBUG: messages_event()
** (process:1217): DEBUG: Event: 0
** (process:1217): DEBUG: window_create()
** (process:1217): DEBUG: Adding delete-request-callback
** (process:1217): DEBUG: messages_event()
** (process:1217): DEBUG: Event: 1


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: [shr] SHR image released

[Tilman Baumann]

Julien Cassignol wrote:
> On Thu, Nov 13, 2008 at 5:49 PM, Lech Karol Pawłaszek <[EMAIL PROTECTED]> 
> wrote:
> 
>> ;-) I can confirm this. I've just flashed SHR and USB networking doesn't
>> work unless you restart networking.
> 
> This is weird and unheard of on our side. I flashed the image and had
> no problem last time. Did you flash the kernel too?
> 

I just like to report that I have no USB networking issues at all.
I have of course the right kernel and i have a gta01.


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: [shr] SHR image released

[Tilman Baumann]

Tilman Baumann wrote:
> Julien Cassignol wrote:
>>> PS: gta01
>>
>> This is interesting. We had issues on GTA01, could you please come and
>> join us on #openmok-cdevel on freenode, to give more input for us
>> think about?
> 
> Channel seems empty. I'm that DPThought dude there.

Doh, typo. Never mind.


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: [shr] SHR image released

[Tilman Baumann]

Julien Cassignol wrote:
>> PS: gta01
> 
> This is interesting. We had issues on GTA01, could you please come and
> join us on #openmok-cdevel on freenode, to give more input for us
> think about?

Channel seems empty. I'm that DPThought dude there.



-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: [shr] SHR image released

[Tilman Baumann]

GSM is flaky, but I can not put my finger yet on any specific faults.

But shutdown is broken. If I shutdown from X, the screen will freeze at 
some time and shutdown seems to abort some way. I had to reset the device.
If I shutdown with X stopped, I see dozens of exquisite errors, but it 
eventually shuts down.

But all after all I'm extremely pleased with this distro. I know it is 
not done yet, but this is my favourite from now on. ;)

Enlightenment/Illume crashes from time to time, but this seems to be 
normal on every distro I had so far.

PS: gta01

PPS: Nice fit
$ df -h /
FilesystemSize  Used Available Use% Mounted on
rootfs   61.1M 59.8M  1.3M  98% /


David Garabana Barro wrote:
> Anyone?
> 
> http://wiki.openmoko.org/wiki/SHR
> 
> Images:
> http://shr.bearstech.com/shr-testing/images/neo1973/
> 
> It's pretty, seems stable, is *fast* (for me faster than FDOM and FSO M3 for 
> sure)
> 
> 
> 
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: IMAGE/MP3 licensing issue.

[Tilman Baumann]

Oh, I'm really sorry. I read your mails in the wrong order.
Pardon, no hard feelings please. ;)

Tilman Baumann wrote:
> In-Reply-To: <[EMAIL PROTECTED]>
> Very professional :-/
> 
> Ray Chao wrote:
>> Dear Community;
>>
>> We are sorry that currently we have to remove all the images on the
>> download server of Openmoko. http://downloads.openmoko.org/release/
>>
>> We will make another stable release as soon as possible.  At the mean
>> time, we could rebuild those old releases without mp2/mp3.  However,
>> this might not stable due to the missing packages and we have no
>> capability to test them all.
>>
>> So, ladies and gentlemen, please let us know, if you want these old and
>> unstable images or any other ideas.  Any feedback are welcome, and
>> please, let us know what you think on this one.
>>
>> Ray Chao
>> Openmoko System Admim
>>
>>
>>
>> ___
>> Openmoko community mailing list
>> community@lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
> 
> 


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: IMAGE/MP3 licensing issue.

[Tilman Baumann]

In-Reply-To: <[EMAIL PROTECTED]>
Very professional :-/

Ray Chao wrote:
> Dear Community;
> 
> We are sorry that currently we have to remove all the images on the
> download server of Openmoko. http://downloads.openmoko.org/release/
> 
> We will make another stable release as soon as possible.  At the mean
> time, we could rebuild those old releases without mp2/mp3.  However,
> this might not stable due to the missing packages and we have no
> capability to test them all.
> 
> So, ladies and gentlemen, please let us know, if you want these old and
> unstable images or any other ideas.  Any feedback are welcome, and
> please, let us know what you think on this one.
> 
> Ray Chao
> Openmoko System Admim
> 
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: fso-control

[Tilman Baumann]

Nice

This adds some long missing featues.

Some way to invoke the illume lock thing as it did in early previews 
with the aux button would be great. Regarding the lock button... ;)

Invoking it via power button does not work tough. I still get the wired 
'keep pressed, let go, ...' dialog which seems like a nice idea but does 
not work well and i don't get the concept...





digger vermont wrote:
> Hello,
> 
> Here's something I'm working on, fso-control.  
> 
> http://mysite.verizon.net/~digver/apps/fso-control.tar.gz
> 
> Uses python and edje to control the state (suspend, reboot, shutdown)
> with frameworkd.  It's not unlike what I remember 2007.* and 2008.*
> having when the POWER button is pressed.
> 
> Some points
> * install.sh will cp the files to install but its probably safer
>   to do it manually.
> * It works from the desktop icon
> * "lock" and "more" buttons currently do nothing.
> * Add a rule to /etc/freesmartphone/oevents/rules.yaml
> ---
> trigger: InputEvent()
> filters:
>  - HasAttr(switch, "POWER")
>  - HasAttr(event, "pressed")
> actions: Command('fso-control')
> 
> * Why doesn't it work from the POWER button?
>   I asked about in devel list.
>   http://n2.nabble.com/-FSO-testing--Can%
> 27t-start-GUI-with-oevents-rule.-td1389692ef1958.html;cid=1225223928263-321
> 
> * With fso-testing /etc/dbus-1/system.d/frameworkd.conf has an error:
>   Its changed in frameworkd.git.
> --
> 
> 
> -   
> +   
> 
> 
> 
> 
> * I plan to add control of the various radios.
> * I plan to figure out how to package it.
> * Think thats all.  Hope it works!
> 
> 
> digger
> 
> 
> 
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: New Rasterman Image...

[Tilman Baumann]

Where does FSO stand in regard to rasters releases?
Is FSO bleeding edge on Illume and co?

I would like to have them in FSO. Since this is the distro i trust the 
most right now for delivering me the newest and greatest stuff that will 
also work on my gta01.

Marco Trevisan (Treviño) wrote:
> In the enlightenment archives there's a new Rasterman image:
>  - openmoko-illume-image-glibc-ipk--20080929-om-gta02.rootfs.jffs2 [1]
> It looks so cool with the new illume theme [2] [3] [4] [5] [6], but
> practically it has no telephony related software installed in since it
> seems a simple OE built with these scripts [7], so (I figure) that
> you're free to put in both the FSO and/or the Om2008.8 stack, just
> install the needed packages!
> 
> Bye.
> 
> 
> [1] http://download.enlightenment.org/misc/Illume/
> [2] http://forum.telefoninux.org/index.php/topic,533.0/topicseen.html
> [3] http://www.rasterman.com/files/illume-01.ogg
> [4] http://www.rasterman.com/files/illume-02.ogg
> [5] http://www.rasterman.com/files/illume-03.ogg
> [6] http://www.rasterman.com/files/illume-04.ogg
> [7] http://www.rasterman.com/files/oe-setup.tar.gz
> 


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Concept arts. Interface - how I would like it to see.

[Tilman Baumann]

Carsten Haitzler (The Rasterman) wrote:

>> really hard to scroll and not to miss and then, by so many scrolls
>> around, i usually accidentally trigger another app. I even tried
>> setting double tap :) What about paging while scrolling? Going up or
>> down given pages seems easier for me than having to scroll around and
>> always miss... or?
> 
> i don't plane to touch the launcher as it is as it is just a filemanager icon
> view widget. i do intend to actually pretty much nuke it in favor of a much
> better launching mechanism/idea. not just launching apps too - though i now
> note that android is kin of doing this (put not just apps but contacts, 
> clocks,
> calendars etc. on your "home screen" anywhere u like - and at any size). a
> launcher with a list of apps could be once such "desktop gadget" type

I like the idea.

And just for a useless opinion from me, the Nokia770 desktop had 
something like this. They allowed free positioning of elements with 
various sizes. The effect whas a cluttered appearance and a real pain to 
position the widgets in a nice way. And many of these elements wasted 
just some pixels too much to bring them into position next to each other 
with others.

Especially on a phone i would like the container to control size and 
placement of the gadgets.
The gadget designer could still decide how many 'units' he wants and 
shape his elements like tetris blocks but the container would enforce 
placement and size.

As i said, this is at the moment a useless idea. But i wanted to share 
my experience with a floating unconstrained gadget layout. *g*

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Concept arts. Interface - how I would like it to see.

[Tilman Baumann]

Am 25.09.2008 um 00:36 schrieb Carsten Haitzler (The Rasterman):

> On Wed, 24 Sep 2008 19:26:21 +0200 Tilman Baumann  
> <[EMAIL PROTECTED]> babbled:
>
>> woho!
>> I see great things to come.
>> I like the slider checkbox from illume-02.ogg
>
> that's not part of e/illume - it's a quick and simple toolkit i am  
> writing
> though.

Great. A phony (pun) toolkit seems to be the last thing missing for  
world domination, or at least world satisfaction. :)
>
>
>> And if i may throw some ideas in the pot too.
>> * Move the Remove button as bigger button to the top right corner  
>> of the
>> (opened) illume slider. (As proposed in my earlier mail)
>
> why top right as opposed to top-left? does it matter? as such the  
> close cutto
> n consumes the entire space that the visible shelf region has (just  
> slid down
> ) - just the icon uses a sub-section of it, but the "hit area" is  
> large. (and as
> such the theme is able to just do this - no code changes needed).
The top right corner is not used and easily reachable with your thumb  
if you hold the phone just in one hand.
I tried how it would feels, and i think it's the best position.


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

Re: Concept arts. Interface - how I would like it to see.

[Tilman Baumann]

woho!
I see great things to come.
I like the slider checkbox from illume-02.ogg
And the keyboard zoom thing.

But i also really like WP's idea for a desktop shelf homescreen with 
info screen and quicklauncher.

And if i may throw some ideas in the pot too.
* Move the Remove button as bigger button to the top right corner of the 
(opened) illume slider. (As proposed in my earlier mail)
* App launcher as scrollable list like in the 2008.2 home screen. (with 
sections as in 2008.2 too)



Carsten Haitzler (The Rasterman) wrote:
> On Wed, 24 Sep 2008 18:00:56 +0200 DJDAS <[EMAIL PROTECTED]> babbled:
> 
> shameless plug:
> 
> http://www.rasterman.com/files/illume-01.ogg
> http://www.rasterman.com/files/illume-02.ogg
> http://www.rasterman.com/files/illume-03.ogg
> http://www.rasterman.com/files/illume-04.ogg
> 
> new (incomplete though) theme with e's new "scaleability" options enabled and
> demos in multiple dpi's and resolutions - keyboard had a few minor tweaks.
> theme is INCOMPLETE. definitely not done, but on its way.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: Concept arts. Interface - how I would like it to see.

[Tilman Baumann]

Petr Vanek wrote:
> On Tue, 23 Sep 2008 15:48:07 -0700
> Kelvie Wong <[EMAIL PROTECTED]> (KW) wrote:
> 
>> On September 23, 2008 15:16:26 wp wrote:
>>> http://server6.theimagehosting.com/image.php?img=artconcept1.png
>> These look really nice :)  One problem I see, though, it seems that
>> without a stylus, the ">>" links (and just hyperlinks in general) are
>> _really_ hard to press.  I think we should be optimizing for
>> finger-based usability instead.
> 
> What you say makes sense. Just think about the "REMOVE" link in Shelve.
> 80% impossible without a stylus. But as far as the REMOVE link stays
> as it is and one has a stylus in his hand already, than the small links
> are actually OK. So the whole concept has to go either one direction or
> another.

I would like to have the 'remove' button in the upper right corner as a 
big button (named close not remove) which i can press with my thumb.
This would even make one handed finger use possible.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: fso bug/oddity

[Tilman Baumann]

Michael 'Mickey' Lauer wrote:

>> I see fso walking a fine line between genius and insanity. :)
> 
> Agreed. But you'll never know on which part you walk unless you start moving. 
> That's what we're doing atm.
> 
> Please help us to stay on the genius' path ;)

Happyly.
At the moment i'm just observing the show. My time management for 
private projects is currently just horrible. I always feel bad talking 
about doing great stuff and never doing it. :)

>> settingsd vs. gconf would be one of these cases. I just refused to
>> really think about it yet, so i don't really know how much sense it
>> makes. I think i would not like the outcome... (gconf is horrible, but
>> it was there long enough to be considered a standard...)
> 
> Hmm, that doesn't count for me as a stopsign. First, gconf is already 
> deprecated by the "powers" (with dconf being the dbus-based successor they 
> work on),

O i did not notice. But i guess the api and namespaces will stay?

> 2nd being a "standard" doesn't necessarily mean it should stay 
> there forever unquestioned.

Certainly not. But i see the influence from the desktop to the phone as 
more important and fruitful as the other way around. (For being in the 
position to change the world)

>> pimd vs. eds the same...
> 
> Again, lets first concentrate on sane APIs (which is what the GSoc'08 project 
> did) and then check whether any of the existing solutions fit our needs.

Right. Full steam ahead!


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: fso bug/oddity

[Tilman Baumann]

Federico Lorenzi wrote:
> On 9/17/08, Tilman Baumann <[EMAIL PROTECTED]> wrote:
>>  I see fso walking a fine line between genius and insanity. :)
>>  settingsd vs. gconf would be one of these cases. I just refused to
>>  really think about it yet, so i don't really know how much sense it
>>  makes. I think i would not like the outcome... (gconf is horrible, but
>>  it was there long enough to be considered a standard...)
>>  pimd vs. eds the same...
> 
> Just because something has been around long enough to be considered a
> standard, doesn't make it a good one. Look at .doc, it has been around
> for a few years (in one incarnation or another), but does that make it
> a good standard?

No, but something where you need to carefully think about before you 
waste resources on replacing it and nobody wants it. ;)

And i don't say we should all use .doc, that's something where the ugly 
penalty is too great. *g*

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: fso bug/oddity

[Tilman Baumann]

Michael 'Mickey' Lauer wrote:
>>> How do these programs know each other? Are all supposed to concurrently
>>> program the RTC? => Boom.
>> That's why i'm suggesting this abstraction.
>> Programms should never set the rtc. They should just tell the backend
>> that they need a timer for a specific time, and the backend can then
>> make sure the system is running at this time and inform the client about
>> the event.
> 
> Heh, sounds we're on the same page then.
> 
> org.freesmartphone.Device.RealtimeClock always belonged to the lower level 
> dbus interfaces in my thinking (as are most of the other .Device.* ones). I 
> want to use this from the PIM agent, but not from any app.

Aaah, yes the Device namespace. Makes sense.
But why not cut the intermediate layer? the pim agent will most likely 
be not the only app which needs wakeup times.

But i guess we have the same idea about how it sould be.


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: fso bug/oddity

[Tilman Baumann]

Michael 'Mickey' Lauer wrote:

> It's important though that people 
> understand why we need all these abstractions. It's not because we love high 
> level interfaces, it's because we need to prepare for application 
> _integration_.

Yea, but there are things which are already solved and people are used 
to work with them. Integration could well go over the top.
As i probably already said. I like the effort, but some things are 
better left alone. :)
Not that i have some spcific critique right now, but i could easyly see 
fso going in that direction. That's why i reacted this way in this case, 
i thought it had happened. *g*

I see fso walking a fine line between genius and insanity. :)
settingsd vs. gconf would be one of these cases. I just refused to 
really think about it yet, so i don't really know how much sense it 
makes. I think i would not like the outcome... (gconf is horrible, but 
it was there long enough to be considered a standard...)
pimd vs. eds the same...

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: fso bug/oddity

[Tilman Baumann]

Michael 'Mickey' Lauer wrote:

>>> I felt a dbus interface for that would be nice. It's not in use
>>> yet, but we need something like that anyways when we want to support
>>> waking up arbitrary dbus clients for PIM events.
>> What about a interface where a process can register a timer event for  a
>> callback/dbus signal?
>> Getting and setting stuff to the clock does not sound to me like
>> something  that needs to be exposed as a interface.
> 
> Ok, how would you design it then? Lets say we have a couple of clients who 
> know about certain appointments and every time you go into suspend, you need 
> to find out which client knows about the soonest appointment and have the RTC 
> programmed accordingly.

The back end only needs to keep the soonest timer in the clock and 
change to the next if the time passed.
And emit messages when a timer is passed.

> How do these programs know each other? Are all supposed to concurrently 
> program the RTC? => Boom.

That's why i'm suggesting this abstraction.
Programms should never set the rtc. They should just tell the backend 
that they need a timer for a specific time, and the backend can then 
make sure the system is running at this time and inform the client about 
the event.



-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: fso bug/oddity

[Tilman Baumann]

Michael 'Mickey' Lauer wrote:
> Am Wednesday 17 September 2008 17:54:54 schrieb Tilman Baumann:
>> Michael 'Mickey' Lauer wrote:
>>> Am Wednesday 17 September 2008 16:16:43 schrieb Tilman Baumann:
>>>> Tilman Baumann wrote:
>>>>> dbus is getting flodded by org.freedesktop.Gypsy.Time.TimeChanged,
>>>>> org.freedesktop.Gypsy.Satellite.SatellitesChanged and
>>>>> org.freedesktop.Gypsy.Time.TimeChanged signals.
>>>>> But GPS is off.
>>>>>
>>>>> I think neither of the events makes sense in this case and wastes
>>>>> cycles. Probably not good for battery life.
>>>> I just had a look at the fso apis again. And i almost fell of my chair.
>>>> I just found org.freesmartphone.Device.RealtimeClock
>>>> What is wrong with gettimeofday anc co with all it's beauty?
>>> Last time I checked gettimeofday reads from system time.
>>> org.freesmartphone.Device.RealtimeClock is a dbus interface to program
>>> the RealtimeClock (sic!).
>> My mistake. But what about /dev/rtc and the hwclock command?
> 
> programming /dev/rtc works fine from C and asm, much less so for higher level 
> languages. 
But they will however probably never be in a position where they need to.
Keeping the rtc in sync sounds to me like a framework job.

I don't know, the system clock should probably be stored in rtc before 
going to sleep and saved back afterwards.
And the usual stuff, shutdown and booting.

> I felt a dbus interface for that would be nice. It's not in use 
> yet, but we need something like that anyways when we want to support waking 
> up arbitrary dbus clients for PIM events.

What about a interface where a process can register a timer event for  a 
callback/dbus signal?
Getting and setting stuff to the clock does not sound to me like 
something  that needs to be exposed as a interface.

Sorry if my sarcasm sounded too harsh. It isn't all that bad. ;)

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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