Install latest navit on qtmoko without gpsd / GTA02

[robin]

#Maybe this is of interest to some of you. If you want a more recent version of
#navit you may do the following. The QtMoko QX b) solution removes the needs for
#gpsd as the serial output can be used by navit directly. It only worked with 
#one baudrate though and I don't know if or how this would influence the max 
# speed at which navit would process nmea.

SOLVED for SHR / QtMoko QX
UNSOLVED for QtMoko without QX
thanks for all your answers, here is my summary

SHR (not tested):
get the latest package and install with opkg 
http://download.navit-project.org/navit/openmoko/svn/
(maybe you have to backup your navit.xml beforehand?)


QtMoko (QX only):
a) via navit from wheezy instead of squeeze  (not tested)

echo "deb-src http://ftp.debian.org/debian wheezy main" >>  
/etc/apt/sources.list 
sudo apt-get update
sudo apt-get build-dep navit
apt-get --build source navit
(maybe you have to backup your navit.xml beforehand?)


b) by building navit from source without gpsd (tested, works)

### ASSUMPTIONS:
## your map is in /media/card/Maps/Navit/
## in the end you have to UNCHECK THE ENABLE GPS TOGGLE in the QX ... 
## ... Settings for Navit!!! < I don't know how this is done automatically
## Please read through the script before just copy and pasting!
## exectute PARTS I - III one after the other
## INITIAL SETUP ##
### PART I
## backup your old navit.xml 
cp /usr/share/navit/navit.xml /media/card/Maps/Navit

## uninstall gpsd
apt-get purge gpsd espeak
apt-get autoremove

## create new navit launcher script
cat > /usr/bin/navit.custom.sh << EOF
#!/bin/bash
xset -dpms
xset s off

/opt/qtmoko/bin/gps-poweron.sh

navit

/opt/qtmoko/bin/gps-poweroff.sh

xset +dpms
xset s on

EOF

## make it execuatable
chmod a+x /usr/bin/navit.custom.sh

## create desktop entry for new navit
cat > /usr/share/applications/navit.desktop << EOF
[Desktop Entry]
Version=1.0
Name=Navit
Name[de]=Navit
Name[fr]=Navit
Comment=The open source vector based navigation program with routing engine
Comment[de]=Ein vektorbasiertes Navigationsprogramm
Comment[fr]=Le logiciel opensource de navigation vectorielle
Exec=navit.custom.sh
Icon=navit
StartupNotify=true
Terminal=false
Type=Application
Categories=GTK;Utility;Geography;
GenericName=Navit
GenericName[de]=Navit

EOF

## install newest navit
rm /media/card/Maps/Navit/navit-current.tar.gz
cd /media/card/Maps/Navit
wget http://download.navit-project.org/navit/openmoko/svn/navit-current.tar.gz
cd /
tar -xzvf /media/card/Maps/Navit/navit-current.tar.gz
rm /media/card/Maps/Navit/navit-current.tar.gz

## backup the newest original navit file for comparison /merging
cp /usr/share/navit/navit.xml /media/card/Maps/Navit/navit.xml.orig 

### PART II
### EDIT the /media/card/Maps/Navit/navit.xml to your needs as this one 
### will be used later on
## you can use diffuse to compare the files locally and then copy the 
## merged file back 

### PART III
## restore your navit.xml
cp /media/card/Maps/Navit/navit.xml /usr/share/navit/navit.xml

## make sure your vehicle uses the serial:
sed -e 's/source="gpsd://localhost" gpsd_query="w+xj"/source="file:
/dev/ttySAC1" baudrate="9600" follow="1" >/g' /usr/share/navit/navit.xml >> 
/usr/share/navit/navit.xml

## update the map to your map which can have any name but must lie in
/media/card/Maps/Navit/
echo '' >
/usr/share/navit/maps/osm_bbox_11.3,47.9,11.7,48.2.xml

## UNCHECK THE ENABLE GPS TOGGLE in the QX Settings for Navit!!! < I don't 
## know how this is done automatically



 if the inital setup worked and you just want to update 
## UPDATING SETUP ##
## backup your old navit.xml 
### PART I
cp /usr/share/navit/navit.xml /media/card/Maps/Navit

## install newest navit
rm /media/card/Maps/Navit/navit-current.tar.gz
cd /media/card/Maps/Navit
wget http://download.navit-project.org/navit/openmoko/svn/navit-current.tar.gz
cd /
tar -xzvf /media/card/Maps/Navit/navit-current.tar.gz
rm /media/card/Maps/Navit/navit-current.tar.gz

## backup the newest original navit file for comparison /merging
cp /usr/share/navit/navit.xml /media/card/Maps/Navit/navit.xml.orig 

### PART II
### EDIT the /media/card/Maps/Navit/navit.xml to your needs as this one 
### will be used later on

### PART III
## restore your navit.xml
cp /media/card/Maps/Navit/navit.xml /usr/share/navit/navit.xml

## update the map to your map
echo '' >
/usr/share/navit/maps/osm_bbox_11.3,47.9,11.7,48.2.xml

## update the desktop file
sed -e 's/Exec=navit/Exec=navit.custom.sh/g' /usr/share/applications
/navit.desktop >> /usr/share/applications/navit.desktop









br robin


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

Re: OpenMoko wiki needs to be set to read-only due to spam

[Dr. H. Nikolaus Schaller]

Am 28.01.2013 um 03:06 schrieb Harry Prevor:

> On 11/10/12, Liz  wrote:
>> On Sat, 10 Nov 2012 18:57:39 -0500
>> Harry Prevor  wrote:
>> 
>>> On 10/31/12, Harald Welte  wrote:
 Hi Paul,
 
 I put it on my TODO list and will hopefully be able to do it still
 today.
 
 Thanks for pointing it out.
 
 On Wed, Oct 31, 2012 at 04:50:46PM +0800, Paul Wise wrote:
> Hi Harald, all,
> 
> To whoever is able to make the OpenMoko wiki read-only, please do
> so since no-one is monitoring it for spam and removing that:
> 
> http://wiki.openmoko.org/wiki/Special:RecentChanges
>>> 
>>> Sorry for bringing this somewhat old topic up, but why did this have
>>> to be done? I can understand restricting editing to registered users
>>> only or adding CAPTCHAs to prevent spam, but isn't making the (still
>>> very important) wiki entirely read only very exccessive? I've found a
>>> few pages with errors but I'm now unable to edit them, seemingly
>>> forever. Please reconsider this.
>>> 
>> 
>> Neither of the two methods you mention actually stop spam being posted.
>> Humans register and then post the spam.
>> I'm sure that a few persons could have write access, and that the wiki
>> owner could consider your request.
> 
> Well, it's been over two months and the wiki is still read-only. I was
> under the impression this was supposed to be temporary; when will this
> be fixed? I often find incorrect information in wiki articles and I'm
> all-too-frequently frustrated by the fact that I can't fix it.

Openmoko is dead - long live OpenPhoenux :)

-- hns

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

Re: [QtMoko] Mokofaen red signal strength icon

[francesco . devita]

Il 28/01/2013 01:32, Neil Jerram ha scritto:


Do you have the .svg source for the signal strength icons?  There's a
signal.svg in the QtMoko repository but it doesn't match the
signal.png.  I had a go myself at changing the colour of the .png
(attached), but it wasn't a very nice job.

Regards,
 Neil

What a coincidence, just yesterday I started to work to update MokoFaen
And here it is the reworked signal icon.

Regards
Joif



signal.tar.gz
Description: GNU Zip compressed data
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Install latest navit on qtmoko without gpsd / GTA02

[Davide Scaini]

Thanks! I'll try this on SHR ;)
d

On Mon, Jan 28, 2013 at 9:05 AM, robin  wrote:

> #Maybe this is of interest to some of you. If you want a more recent
> version of
> #navit you may do the following. The QtMoko QX b) solution removes the
> needs for
> #gpsd as the serial output can be used by navit directly. It only worked
> with
> #one baudrate though and I don't know if or how this would influence the
> max
> # speed at which navit would process nmea.
>
> SOLVED for SHR / QtMoko QX
> UNSOLVED for QtMoko without QX
> thanks for all your answers, here is my summary
>
> SHR (not tested):
> get the latest package and install with opkg
> http://download.navit-project.org/navit/openmoko/svn/
> (maybe you have to backup your navit.xml beforehand?)
>
>
> QtMoko (QX only):
> a) via navit from wheezy instead of squeeze  (not tested)
>
> echo "deb-src http://ftp.debian.org/debian wheezy main" >>
>  /etc/apt/sources.list
> sudo apt-get update
> sudo apt-get build-dep navit
> apt-get --build source navit
> (maybe you have to backup your navit.xml beforehand?)
>
>
> b) by building navit from source without gpsd (tested, works)
>
> ### ASSUMPTIONS:
> ## your map is in /media/card/Maps/Navit/
> ## in the end you have to UNCHECK THE ENABLE GPS TOGGLE in the QX ...
> ## ... Settings for Navit!!! < I don't know how this is done automatically
> ## Please read through the script before just copy and pasting!
> ## exectute PARTS I - III one after the other
> ## INITIAL SETUP ##
> ### PART I
> ## backup your old navit.xml
> cp /usr/share/navit/navit.xml /media/card/Maps/Navit
>
> ## uninstall gpsd
> apt-get purge gpsd espeak
> apt-get autoremove
>
> ## create new navit launcher script
> cat > /usr/bin/navit.custom.sh << EOF
> #!/bin/bash
> xset -dpms
> xset s off
>
> /opt/qtmoko/bin/gps-poweron.sh
>
> navit
>
> /opt/qtmoko/bin/gps-poweroff.sh
>
> xset +dpms
> xset s on
>
> EOF
>
> ## make it execuatable
> chmod a+x /usr/bin/navit.custom.sh
>
> ## create desktop entry for new navit
> cat > /usr/share/applications/navit.desktop << EOF
> [Desktop Entry]
> Version=1.0
> Name=Navit
> Name[de]=Navit
> Name[fr]=Navit
> Comment=The open source vector based navigation program with routing engine
> Comment[de]=Ein vektorbasiertes Navigationsprogramm
> Comment[fr]=Le logiciel opensource de navigation vectorielle
> Exec=navit.custom.sh
> Icon=navit
> StartupNotify=true
> Terminal=false
> Type=Application
> Categories=GTK;Utility;Geography;
> GenericName=Navit
> GenericName[de]=Navit
>
> EOF
>
> ## install newest navit
> rm /media/card/Maps/Navit/navit-current.tar.gz
> cd /media/card/Maps/Navit
> wget
> http://download.navit-project.org/navit/openmoko/svn/navit-current.tar.gz
> cd /
> tar -xzvf /media/card/Maps/Navit/navit-current.tar.gz
> rm /media/card/Maps/Navit/navit-current.tar.gz
>
> ## backup the newest original navit file for comparison /merging
> cp /usr/share/navit/navit.xml /media/card/Maps/Navit/navit.xml.orig
>
> ### PART II
> ### EDIT the /media/card/Maps/Navit/navit.xml to your needs as this one
> ### will be used later on
> ## you can use diffuse to compare the files locally and then copy the
> ## merged file back
>
> ### PART III
> ## restore your navit.xml
> cp /media/card/Maps/Navit/navit.xml /usr/share/navit/navit.xml
>
> ## make sure your vehicle uses the serial:
> sed -e 's/source="gpsd://localhost" gpsd_query="w+xj"/source="file:
> /dev/ttySAC1" baudrate="9600" follow="1" >/g' /usr/share/navit/navit.xml >>
> /usr/share/navit/navit.xml
>
> ## update the map to your map which can have any name but must lie in
> /media/card/Maps/Navit/
> echo ' data="/media/card/Maps/Navit/*.bin"/>' >
> /usr/share/navit/maps/osm_bbox_11.3,47.9,11.7,48.2.xml
>
> ## UNCHECK THE ENABLE GPS TOGGLE in the QX Settings for Navit!!! < I don't
> ## know how this is done automatically
>
>
>
>  if the inital setup worked and you just want to update
> 
> ## UPDATING SETUP ##
> ## backup your old navit.xml
> ### PART I
> cp /usr/share/navit/navit.xml /media/card/Maps/Navit
>
> ## install newest navit
> rm /media/card/Maps/Navit/navit-current.tar.gz
> cd /media/card/Maps/Navit
> wget
> http://download.navit-project.org/navit/openmoko/svn/navit-current.tar.gz
> cd /
> tar -xzvf /media/card/Maps/Navit/navit-current.tar.gz
> rm /media/card/Maps/Navit/navit-current.tar.gz
>
> ## backup the newest original navit file for comparison /merging
> cp /usr/share/navit/navit.xml /media/card/Maps/Navit/navit.xml.orig
>
> ### PART II
> ### EDIT the /media/card/Maps/Navit/navit.xml to your needs as this one
> ### will be used later on
>
> ### PART III
> ## restore your navit.xml
> cp /media/card/Maps/Navit/navit.xml /usr/share/navit/navit.xml
>
> ## update the map to your map
> echo ' data="/media/card/Maps/Navit/*.bin"/>' >
> /usr/share/navit/maps/osm_bbox_11.3,47.9,11.7,48.2.xml
>
> ## update the desktop file
> sed -e 's/Exec=navit/Exec=navit.custom.sh/g' /usr/sh

Re: Install latest navit on qtmoko without gpsd / GTA02

[Radek Polak]

On Monday, January 28, 2013 11:29:03 AM Davide Scaini wrote:

> Thanks! I'll try this on SHR ;)

Hi,
i have locally updated also navit package for QtMoko - but there is a nasty 
regression - when you search for a town it takes forever. So i think i'll not 
upload the package until this is fixed.

Regards

Radek

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

Re: Install latest navit on qtmoko without gpsd / GTA02

[robin]

hi Radek,

could you quickly explain how your qtmoko-native navit differs from navit
which runs under qtmoko-qx. in the end it would be much nicer, if one can 
update the sources but not have to use qx to run it. with the current setup
under qx I can at least make use of your agps scripts, which is nice for
getting a fast fix!

br

robin



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

World of OpenPhoenux @ FOSDEM

[Dr. H. Nikolaus Schaller]

There is a new WIki Page for the FOSDEM stand



Please feel free to add any content that you think is important for FOSDEM 2013.

And we invite everyone who has origins in Openmoko, Zaurus, Nanonote etc. to 
come and join us.

Have fun!
Nikolaus


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

Mobile schedule apps -- ConfClerk for SHR (OpenPhoenux/Openmoko)

[Lukas Märdian]

Hi FOSDEM team,

the ConfClerk mobile schedule app is now also ported to the SHR
distribution (OpenEmbedded) for OpenPhoenux (GTA04) and Openmoko
(GTA01/GTA02) devices.

The ipk and a screenshot can be found here:
  http://slyon.de/shr/confclerk/

Soon it will be in SHR's official feeds!

Cheers,
  Lukas

 Von: gregor herrmann 
 Datum: 20. Januar 2013 21:21:41 MEZ
 An: fos...@lists.fosdem.org
 Betreff: Re: [FOSDEM] Mobile schedule apps

 On Sun, 20 Jan 2013 18:21:56 +0100, Tias Guns wrote:

> We love the mobile schedule apps!
> You can find a list of apps we know about here:
> https://fosdem.org/2013/schedule/mobile/
> Do you know about more apps? More platforms? Tell us about it!

 Please add ConfClerk to the list:
 - homepage, source, svn repo:
 http://www.toastfreeware.priv.at/confclerk
 - packaged for Debian, Ubuntu, and Maemo5

 (It's the successor of (fosdem-schedule/)fosdem-maemo which can be
 removed from the list.)

 ConfClerk is a Qt application that works for all conferences that use
 Pentabarf (or frab) for their schedule. 

 Incidentally I've confirmed earlier today that FOSDEM 2013's XML
 schedule imports fine :)


 Cheers,
 gregor



signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko wiki needs to be set to read-only due to spam

[robin]

true, but there are a lot of GTA02 users and there is stuff on the wiki which
is important to GTA02 and GTA04. I wouldn't mind, if it was hosted at gta04.org
but if I remember correctly gta04.org was only supposed to contain information 
on openphoenux

robin


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

Re: [QtMoko] Mokofaen red signal strength icon

[Neil Jerram]

francesco.dev...@mailoo.org writes:

> Il 28/01/2013 01:32, Neil Jerram ha scritto:
>>
>> Do you have the .svg source for the signal strength icons?  There's a
>> signal.svg in the QtMoko repository but it doesn't match the
>> signal.png.  I had a go myself at changing the colour of the .png
>> (attached), but it wasn't a very nice job.
>>
>> Regards,
>>  Neil
> What a coincidence, just yesterday I started to work to update MokoFaen
> And here it is the reworked signal icon.

That's great, thanks!

There are also a few Mokofaen fixes that have gone recently into the
QtMoko repository; please see
https://github.com/radekp/qtmoko/commits/master/etc/themes/mokofaen.

And then there is one more that I haven't sent anywhere yet, but which
you may like to consider, attached.

>From dcee42a5186e87ff54d0e48ccc32acc9da1a2287 Mon Sep 17 00:00:00 2001
From: Neil Jerram 
Date: Tue, 20 Nov 2012 22:53:00 +
Subject: [PATCH 1/2] Avoid "QString::arg: Argument missing" logs

Specifically these:
Nov 20 22:09:04 neo Qtopia: QString::arg: Argument missing: "1 missed", @/Communications/Calls/MissedCalls
Nov 20 22:09:04 neo Qtopia: QString::arg: Argument missing: "1 new", @/Communications/Messages/NewMessages

These arise because the "faen"-derived themes have special cases for 1
missed call and 1 new message - presumably for translation into
languages where the 1 case is different from N != 1.  All those places
have an unnecessary , which causes the logs, and which this
commit removes.
---
 etc/themes/faenqo/home.xml   |2 +-
 etc/themes/faenqomod/home.xml|2 +-
 etc/themes/mokofaen/home.xml |2 +-
 etc/themes/mokofaen/home_classic.xml |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/etc/themes/faenqo/home.xml b/etc/themes/faenqo/home.xml
index 1be7db7..a511d48 100644
--- a/etc/themes/faenqo/home.xml
+++ b/etc/themes/faenqo/home.xml
@@ -60,7 +60,7 @@
 		
 		
 			
-1 new@/Communications/Messages/NewMessages
+1 new
 			
 			
 %1 new@/Communications/Messages/NewMessages
diff --git a/etc/themes/faenqomod/home.xml b/etc/themes/faenqomod/home.xml
index 68d4dab..8590b3b 100644
--- a/etc/themes/faenqomod/home.xml
+++ b/etc/themes/faenqomod/home.xml
@@ -95,7 +95,7 @@
 		
 		
 			
-1 new@/Communications/Messages/NewMessages
+1 new
 			
 			
 %1 new@/Communications/Messages/NewMessages
diff --git a/etc/themes/mokofaen/home.xml b/etc/themes/mokofaen/home.xml
index 1380bc2..6fd654f 100755
--- a/etc/themes/mokofaen/home.xml
+++ b/etc/themes/mokofaen/home.xml
@@ -85,7 +85,7 @@
 		
 		
 			
-1 new@/Communications/Messages/NewMessages
+1 new
 			
 			
 %1 new@/Communications/Messages/NewMessages
diff --git a/etc/themes/mokofaen/home_classic.xml b/etc/themes/mokofaen/home_classic.xml
index 5f4eaaf..439771a 100755
--- a/etc/themes/mokofaen/home_classic.xml
+++ b/etc/themes/mokofaen/home_classic.xml
@@ -98,7 +98,7 @@
 		
 		
 			
-1 new@/Communications/Messages/NewMessages
+1 new
 			
 			
 %1 new@/Communications/Messages/NewMessages
-- 
1.7.10.4


This is a simple bug fix and, I believe, uncontroversial.

Sorry for making your release work a bit bigger.  Mokofaen for me is
part of the everyday happiness of using a free phone.

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

Re: QtMoko audio state work

[Neil Jerram]

Neil Jerram  writes:

> I had an unsuccessful call this evening; it was an incoming one.  The
> gsm-voice-routing log for it is below; I plan to analyse this more
> myself to see if there's a repeating pattern of overruns and underruns,
> but thought it worth posting in case someone else sees and understands
> the pattern first.

Well the pattern is clear enough, and persists in exactly the same form
throughout the whole call.  r_mod (capture from the modem) gets an
overrun every 4 loop iterations.  p_ear and p_mod (playback to the
earpiece and to the modem) get an underrun every 8 iterations.  r_mic
(capture from the microphone) doesn't get any overruns at all.

For context, here's a representation of the gsm-voice-routing main loop.

  +---+ +---+ +---+ +---+
   .->| Read  |--+->| Read  |--+->| Write |>| Write |--.
  /   | r_mic |  |  | r_mod |  |  | p_ear | | p_mod |   \
 /+---+  |  +---+  |  +---+ +---+\
 \ (if overrun)  (if overrun)/
  \ / / /
   '-<-'---<-'---<-<---'

I had two ideas for explaining the observed over/underruns, but neither
of them makes complete sense when we look at the full detail.

#1 was that the modem sound card was running slightly faster than the
main sound card.  (In theory they should both be at 8kHz.)  However I
think that is disproved by the fact that I got _exactly_ the same
underrun pattern for p_ear and p_mod.  I think that means that the rates
of the two sound cards must differ by less than 1 period over the 16s
duration of the call that I logged, i.e. by less than 0.2%.

(The period - i.e. how much audio data is read or written in each block
shown above - is 32ms.)

#2 was that gsm-voice-routing might not be getting enough CPU.  The
period time is 32ms; let's call that P.  Also note that
gsm-voice-routing uses hardware buffers that have room for 4P.

Now suppose that the average time for gsm-voice-routing to iterate round
its main loop is more than P, say 1.9P.  After 4 iterations, the capture
devices have captured 7.6P, but gsm-voice-routing has only read 4P from
them - so they have 3.6P still available and are close to overrunning.

The loop always reads r_mic first, so manages to do that before r_mic
overruns, reducing its remaining data to 2.6P.  But that took a bit of
time, and that was long enough for r_mod to fill from 3.6P to 4P, so
that 'Read r_mod' reports an overrun.

r_mod's buffer is now reset to empty and the main loop does a
'continue', which means that it skips the 'Write's and loops back to
reading r_mic again.

For p_ear and p_mod, the underrun every 8 iterations is roughly
explained by the fact that they have a start threshold of 4 periods.
Hence, after an underrun, it takes some iterations for the playback
buffers to fill up to their start threshold, then 4 and a bit iterations
at 1.9P each for them to be emptied (faster than the loop can keep them
filled) and eventually see another underrun.

But there are several problems with this explanation.

- It doesn't actually explain why we never see r_mic overruns.  After an
  r_mod overrun, r_mod's buffer is reset to 0 but r_mic's buffer is left
  unchanged.  So now r_mic is ahead of r_mod, and we ought to see an
  r_mic overrun before the next r_mod overrun...

- If the loop time was nearly 2P, it should take only 2 and a bit
  iterations for p_ear and p_mod to fill to their start threshold.  Plus
  4 iterations to empty again, and that only makes 6 (and a bit), not 8.

- The log shows 519 loop iterations, and QtMoko recorded the call
  duration as 17s, so the average loop iteration time was 32.8ms,
  i.e. almost exactly P as it should be, and nowhere near 2P.

So the head scratching continues.  Any ideas?

 Neil

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

Re: [QtMoko] Mokofaen red signal strength icon

[francesco . devita]

Il 28/01/2013 21:04, Neil Jerram ha scritto:


That's great, thanks!

There are also a few Mokofaen fixes that have gone recently into the
QtMoko repository; please see
https://github.com/radekp/qtmoko/commits/master/etc/themes/mokofaen.

And then there is one more that I haven't sent anywhere yet, but which
you may like to consider, attached.

Thank you Neil, I'll look at the patches tomorrow



Sorry for making your release work a bit bigger.  Mokofaen for me is
part of the everyday happiness of using a free phone.
I'm happy you like it, I'm working on an update of the theme so if you 
have suggestions or requests please tell me.

If you're curious, here are two screenshots of the work-in-progress [1] [2].

Regards
Joif

[1] http://img341.imageshack.us/img341/1005/mokofaen22homescreenwip.png
[2] http://img267.imageshack.us/img267/2113/mokofaen22callscreenwip.png

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

Re: OpenMoko wiki needs to be set to read-only due to spam

[Dr. H. Nikolaus Schaller]

Am 28.01.2013 um 16:12 schrieb robin:

> true, but there are a lot of GTA02 users and there is stuff on the wiki which
> is important to GTA02 and GTA04. I wouldn't mind, if it was hosted at 
> gta04.org
> but if I remember correctly gta04.org was only supposed to contain 
> information 
> on openphoenux

gta04.org is intended for information on GTA04 only,

while

openphoenux.org is intended for and open for any GTA0x.

I am not sure if it is possible to copy the MediaWiki from wiki.openmoko.org
to openphoenux.org (is there read access to the database? does it break links?).

And an important question is to find a handful of volunteers to moderate and 
clean it up.

Nikolaus



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

Re: Install latest navit on qtmoko without gpsd / GTA02

[Radek Polak]

On Monday, January 28, 2013 01:32:26 PM robin wrote:

> hi Radek,
> 
> could you quickly explain how your qtmoko-native navit differs from navit
> which runs under qtmoko-qx. 

Hi,
navit under qtmoko-qx uses SDL or gtk or Qt/X11. Native QtMoko navit uses 
QtEmbedded.

> in the end it would be much nicer, if one can
> update the sources but not have to use qx to run it. with the current setup
> under qx I can at least make use of your agps scripts, which is nice for
> getting a fast fix!

I am building it in qemu. First you need to compile qtmoko there (which takes 
a few days ;-)

Then just checkout my branch:   

https://github.com/radekp/navit/tree/qtmoko_hack2

and dpkg-buildpackage will build the package for you. Maybe i could upload my 
whole qemu buildhost, but it's quite big - a few GB with qtmoko and kernel 
sources.

Regards

Radek

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

Re: OpenMoko wiki needs to be set to read-only due to spam

[robin]

if the wiki can indeed be transferred, maybe you can do an official posting on
who would like to apply for write access. I would certainly like to tidy up
a couple of pages and add more recent information, but reading the gmane list
there are many others willing to do so as well.

br

robin



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

Re: Install latest navit on qtmoko without gpsd / GTA02

[robin]

which version of qtmoko will one be building if one clones your git tree? always
the latest one (no matter if latest is stable or experimental) depending on the 
device? I would guess eg as GTA02 and GTA04 builds are at the moment quite 
different that this would affect the building of the navit package as well. So
if this correct will we have separate packages of navit for GTA02/GTA04?

Where do you configure it that if you use dpkg-buildpackage to build navit 
that navit automatically gets the latest svn version to build?

regarding uploding qemu buildhost, would it then be easy to keep that one in 
sync with your git tree? If yes, this is a good idea for entry level people 
like me, if not, I  would rather try to build it from scratch once my wife has
cleaned our harddrive to allow debian squeeze to reside in a virtual box.


best regards

robin





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