Re: tangogps 0.9.8
On Mon, Nov 2, 2009 at 8:06 AM, Marcus Bauer marcus.ba...@gmail.com wrote: Hello, a new version of tangoGPS is out. Most notably are: * a fix for a potential segfault in the overzoom code (spotted by Joshua Judson Rosen) * if started in landscape mode the layout is optimized (toolbar vertical) which is nice both on the neo as well as on a laptop * you can send messages to other users if the have 0.9.8 too - if you are on GPRS that's a lot cheaper than SMS. In any case it is a fun little feature and can be quite handy at times As always, find it a http://tangogps.org/ Have fun! Marcus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community super! will test it as soon as i find some time ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps 0.9.8
Hi Markus, Thanks for the update. Do you have an ipk/opk file yet? On your website it says version 0.9.5. On my moko though, I got 0.9.7-r2 installed. Someone for SHR-u should update the repo to 0.9.8 asap? Thanks :) Pieter On Mon, 2009-11-02 at 08:06 +0100, Marcus Bauer wrote: Hello, a new version of tangoGPS is out. Most notably are: * a fix for a potential segfault in the overzoom code (spotted by Joshua Judson Rosen) * if started in landscape mode the layout is optimized (toolbar vertical) which is nice both on the neo as well as on a laptop * you can send messages to other users if the have 0.9.8 too - if you are on GPRS that's a lot cheaper than SMS. In any case it is a fun little feature and can be quite handy at times As always, find it a http://tangogps.org/ Have fun! Marcus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps 0.9.8
On Mon, 02 Nov 2009 10:41:22 +0100 Pieter Colpaert freep...@gmail.com wrote: Hi Markus, Thanks for the update. Do you have an ipk/opk file yet? On your website it says version 0.9.5. I have currently no working OE here and there are now too many distribs. However, you can try the armel.deb. Just extract the tangogps binary from the .deb (do it on your desktop/laptop) and copy it to your Neo. The necessary steps are: cd /tmp wget http://www.tangogps.org/downloads/tangogps_0.9.8-1_armel.deb ar -x tangogps_0.9.8-1_armel.deb tar xfvz data.tar.gz scp /tmp/usr/bin/tangogps to_your_phone Marcus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: [Shr-User] What's going on in SHR land
Thanks for the update! Ever since I saw that the SHR feeds didn't get updated for a while I compiled SHR myself from the shr/import branch, so I already knew that there was a lot of activity going on under the radar. For me the usage of opimd for contacts is the nicest new feature. It has a VCF backend, so I could just scp my Kaddressbook contacts over to the FR and have all my contacts available. nice! Graphic speed felt a little slower though, and the interfacing with FSO was broken in some places, like the power management. Also the power button didn't bring up the popup menu. But these are all findings of a few weeks back, so most will probably be long fixed already. Thanks again, looking forward to the next stable unstable release of SHR! grtz, Sander On Sunday 01 November 2009 17:04:30 Thomas Zimmermann wrote: For the SHR users that aren't reading the SHR mailing lists i'm forwarding this message from spaetz: Betreff: [Shr-User] What's going on in SHR land Datum: Sonntag 01 November 2009 Von: Sebastian Spaeth sebast...@sspaeth.de An: shr-de...@lists.shr-project.org, shr-u...@lists.shr-project.org Hi all, for those of you few that do not live 24/7 in IRC land, here is a not-so-brief update on what is happening in SHR land. No, we are not all dead :). There are a couple of major transitions that have slowed down new images or indeed any updates in the SHR feed. Let me try to sum up a few and I am sure others will chime in and list whatever I have forgotten: - Transition from the obsolete kdrive-glamo driver to a proper xorg server infrastructure. This took some time, but it appears that it is working fine now. Don't expect any (initial) performance boosts, but being on a regular xorg server and having a driver that is actually being developed and maintained is a good thing for the future (thanks to Weiss and others for some really hard work here). - More fso...d goodness. Rather than having Mickey Lauer's python prototyped phone backend, we are starting to his re-written bits and pieces (coded in vala, which should give us a nice performance boost over python). For the beginning we have the resource handling (fsoresourced) on board and look forward to the next bits and pieces. I know very little about the state of things here, so others might have more information. -New phone apps: As if that were not enough changes, the core team (mrmoku, tasn, dos1, and others?) has started to redevelop the frontend applications for SHR. the old ophonekitd was initially developed by a guy called quickev who has been missing in action since quite some months now. Don't ask ME why, but apparently the now design allows for better/quicker/whatnot development. I'll let one of them speak out for themselves about the motivations. Besides lots of work,this gives us also a chance to redesign the screens and make the UI better. So goodbuy ophonekitd and libphone-efl, welcome phoneui, and libphoneui-shr. -Bernd Prünzler(spelling?) is kind enough to help out with some theme development (BTW, you did know there is a theme contest going on, do you? So, go and design and submit something already!). The default theme has been designed for powerful desktops, and is using more transparency and other fancy stuff than the slow graphics can do. He is developing a theme that should be much faster on the Freerunner (but don't expect miracles, the hardware will still be barely able to drive a full VGA-resolution screen). So expect a big fight between dos1 (niebee theme) and bernd (gry theme) for the fastest performance (while retaining good looks). Last but not least: what we had done the last few months, is basically taking a fork of OpenEmbedded and developing from that. While this gave us the stability to code apps without having others break our stuff (we are quite capabable of doing that ourselves it seems :-) ), this led to a quickly diverging SHR and OE tree. It was decided that we really should include our stuff into OpenEmbedded proper, rather than just doing our stuff in parallel. So we had first put all the stuff into an SHR/import git tree which is in the openembedded code repository. Next, mrmoku created the shr/merge tree which is kept in sync with the OpenEmbedded tree and we ported all our enhancements there. The plan is to take our bits and pieces from here and merge them into OE over time. This is where we currently stand, we want to keep using the shr/merge tree which gives us a current OE tree, but of courseby using more updated components, lots of stuff was broken. The guys have fought really hard in the last days (and weeks) to overcome compilation errors, nonbooting phones, and crashing components. It seems we are now really close. The new images compile fine (yay!), the phone actually boots, and many of the crashes have been eliminated. AFAIK, we are currently still stuck with a segfaulting dbus. As soon as these
[WikiReader] Hardware
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. Regards AstHrO. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps 0.9.8
2009/11/2 Marcus Bauer marcus.ba...@gmail.com I have currently no working OE here and there are now too many distribs. However, you can try the armel.deb. Just extract the tangogps binary from the .deb (do it on your desktop/laptop) and copy it to your Neo. The necessary steps are: cd /tmp wget http://www.tangogps.org/downloads/tangogps_0.9.8-1_armel.deb ar -x tangogps_0.9.8-1_armel.deb tar xfvz data.tar.gz scp /tmp/usr/bin/tangogps to_your_phone Marcus I tried the above and get this error. Do you know where to find that lib? r...@om-gta02 ~ $ tangogps tangogps: error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps 0.9.8
On Mon, 2 Nov 2009 12:49:43 +0100 Michal Brzozowski ruso...@poczta.fm wrote: 2009/11/2 Marcus Bauer marcus.ba...@gmail.com I have currently no working OE here and there are now too many distribs. However, you can try the armel.deb. Just extract the tangogps binary from the .deb (do it on your desktop/laptop) and copy it to your Neo. The necessary steps are: cd /tmp wget http://www.tangogps.org/downloads/tangogps_0.9.8-1_armel.deb ar -x tangogps_0.9.8-1_armel.deb tar xfvz data.tar.gz scp /tmp/usr/bin/tangogps to_your_phone Marcus I tried the above and get this error. Do you know where to find that lib? r...@om-gta02 ~ $ tangogps tangogps: error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory In Debian it is libcurl3-gnutls. But tangoGPS does not use any TLS functions, thus as a hacky quick fix I guess you could even set a symbolic link to to libcurl.so.4 or maybe even libcurl.so.3 in /usr/lib. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: [Shr-User] What's going on in SHR land
Great news! I'll wait next release, then I want to help in building extra ipk packages... d On Mon, Nov 2, 2009 at 10:59 AM, Sander van Grieken san...@3v8.net wrote: Thanks for the update! Ever since I saw that the SHR feeds didn't get updated for a while I compiled SHR myself from the shr/import branch, so I already knew that there was a lot of activity going on under the radar. For me the usage of opimd for contacts is the nicest new feature. It has a VCF backend, so I could just scp my Kaddressbook contacts over to the FR and have all my contacts available. nice! Graphic speed felt a little slower though, and the interfacing with FSO was broken in some places, like the power management. Also the power button didn't bring up the popup menu. But these are all findings of a few weeks back, so most will probably be long fixed already. Thanks again, looking forward to the next stable unstable release of SHR! grtz, Sander On Sunday 01 November 2009 17:04:30 Thomas Zimmermann wrote: For the SHR users that aren't reading the SHR mailing lists i'm forwarding this message from spaetz: Betreff: [Shr-User] What's going on in SHR land Datum: Sonntag 01 November 2009 Von: Sebastian Spaeth sebast...@sspaeth.de An: shr-de...@lists.shr-project.org, shr-u...@lists.shr-project.org Hi all, for those of you few that do not live 24/7 in IRC land, here is a not-so-brief update on what is happening in SHR land. No, we are not all dead :). There are a couple of major transitions that have slowed down new images or indeed any updates in the SHR feed. Let me try to sum up a few and I am sure others will chime in and list whatever I have forgotten: - Transition from the obsolete kdrive-glamo driver to a proper xorg server infrastructure. This took some time, but it appears that it is working fine now. Don't expect any (initial) performance boosts, but being on a regular xorg server and having a driver that is actually being developed and maintained is a good thing for the future (thanks to Weiss and others for some really hard work here). - More fso...d goodness. Rather than having Mickey Lauer's python prototyped phone backend, we are starting to his re-written bits and pieces (coded in vala, which should give us a nice performance boost over python). For the beginning we have the resource handling (fsoresourced) on board and look forward to the next bits and pieces. I know very little about the state of things here, so others might have more information. -New phone apps: As if that were not enough changes, the core team (mrmoku, tasn, dos1, and others?) has started to redevelop the frontend applications for SHR. the old ophonekitd was initially developed by a guy called quickev who has been missing in action since quite some months now. Don't ask ME why, but apparently the now design allows for better/quicker/whatnot development. I'll let one of them speak out for themselves about the motivations. Besides lots of work,this gives us also a chance to redesign the screens and make the UI better. So goodbuy ophonekitd and libphone-efl, welcome phoneui, and libphoneui-shr. -Bernd Prünzler(spelling?) is kind enough to help out with some theme development (BTW, you did know there is a theme contest going on, do you? So, go and design and submit something already!). The default theme has been designed for powerful desktops, and is using more transparency and other fancy stuff than the slow graphics can do. He is developing a theme that should be much faster on the Freerunner (but don't expect miracles, the hardware will still be barely able to drive a full VGA-resolution screen). So expect a big fight between dos1 (niebee theme) and bernd (gry theme) for the fastest performance (while retaining good looks). Last but not least: what we had done the last few months, is basically taking a fork of OpenEmbedded and developing from that. While this gave us the stability to code apps without having others break our stuff (we are quite capabable of doing that ourselves it seems :-) ), this led to a quickly diverging SHR and OE tree. It was decided that we really should include our stuff into OpenEmbedded proper, rather than just doing our stuff in parallel. So we had first put all the stuff into an SHR/import git tree which is in the openembedded code repository. Next, mrmoku created the shr/merge tree which is kept in sync with the OpenEmbedded tree and we ported all our enhancements there. The plan is to take our bits and pieces from here and merge them into OE over time. This is where we currently stand, we want to keep using the shr/merge tree which gives us a current OE tree, but of courseby using more updated components, lots of stuff was broken. The guys have fought really hard in the last days (and weeks) to overcome compilation errors, nonbooting phones, and
Re: Centralization of graphical awesomeness
Evgeniy Karyakin wrote: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of data flowing through it? Sure you can lower the amount of data flowing through it. Lowering the resolution is one option that several has mentioned. Another way is to draw less stuff overall: * Don't draw anything that need several passes, i.e. transparency * Don't draw anything unnecessary, i.e. cute animations * Don't ecen think of 3D. * Optimize the user interface. Never redraw the screen when drawing a smaller portion will suffice. Don't highlight an icon by changing the background color. (Lots of pixels).- Just draw a 1-pixel wide square around it, for example. (And make sure your drawing library doesn't do anything excessive behind your back, such as drawing the entire icon with that border - because that was simpler to implement. The situation is not hopeless. The entire 640x480 16-bit display is 614400 byte, or 0.6MB. 7MB/s means the entire display can be updated 11 times per second if need be. In theory, anyway. Anything updating a smaller portion of the screen could be even more responsive. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Mon, 02 Nov 2009 14:26:24 +0100 Helge Hafting helge.haft...@hist.no said: Evgeniy Karyakin wrote: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of data flowing through it? Sure you can lower the amount of data flowing through it. Lowering the resolution is one option that several has mentioned. Another way is to draw less stuff overall: * Don't draw anything that need several passes, i.e. transparency * Don't draw anything unnecessary, i.e. cute animations * Don't ecen think of 3D. * Optimize the user interface. Never redraw the screen when drawing a smaller portion will suffice. Don't highlight an icon by changing the background color. (Lots of pixels).- Just draw a 1-pixel wide square around it, for example. (And make sure your drawing library doesn't do anything excessive behind your back, such as drawing the entire icon with that border - because that was simpler to implement. The situation is not hopeless. The entire 640x480 16-bit display is 614400 byte, or 0.6MB. 7MB/s means the entire display can be updated 11 times per second if need be. In theory, anyway. Anything updating a smaller portion of the screen could be even more responsive. 11 fps assumes zero cpu left to actually do the drawing. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
(patch) new feature for tangoGPS: detail-scaling
Hi everybody,
I've added a feature to my copy of tangoGPS, and thought that others
might be interested: it allows the *details* in the map (e.g.: text,
icons) to be scaled up (to show fewer details, but make the shown
details bigger) or scaled down (to render the details smaller, but
show more of them).
This has made tangoGPS *much* more usable for me on my FreeRunner,
because I can actually read the labels for streets, etc. without
holding the screen very close to my face :)
(I guess that the OpenStreetMap tiles are rasterised expecting
something like 96 DPI, but the FreeRunner's display runs at ~280 DPI,
so text and icons used in OSM tiles is *very* small when displayed on
the FreeRunner without any upsampling; `zooming the details' by 1
level makes everything legible at arm's length, and zooming the
details by 2 levels makes the text easy to read even at a glance while
driving).
I've attached 2 separate patches: one patch that adds the `back end'
of the feature (a new `global_detail_zoom' variable with the
corresponding gconf hooks, and some minor-changes to the tile-loading
code), and another patch that adds the front-end GUI for the feature
(an additional submenu in the map screen, and a couple of new
callbacks to accompany the new menu-items).
I added the submenu and menu-items manually in interface.c--it looks
like Marcus is using Glade to maintain the GUI, but I'm not entirely
sure (I didn't see glade-file in the tarball...); if he still *is*
using Glade, then it may make more sense to defined these submenus via
Glade.
--
Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr.
=== modified file 'src/globals.c'
--- src/globals.c 2009-09-26 02:35:15 +
+++ src/globals.c 2009-10-24 19:13:54 +
@@ -22,6 +22,7 @@ int global_x = 890;
int global_y = 515;
int global_zoom = 3;
int global_zoom_max = 20;
+int global_detail_zoom = 0;
int mouse_dx = 0;
int mouse_dy = 0;
=== modified file 'src/globals.h'
--- src/globals.h 2009-09-26 02:35:15 +
+++ src/globals.h 2009-10-24 19:13:54 +
@@ -104,6 +104,7 @@ extern int global_x;
extern int global_y;
extern int global_zoom;
extern int global_zoom_max;
+extern int global_detail_zoom;
extern int mouse_dx; // for mouse move pixmap
extern int mouse_dy;
=== modified file 'src/init.c'
--- src/init.c 2009-09-26 02:35:15 +
+++ src/init.c 2009-10-24 19:13:54 +
@@ -686,7 +686,10 @@ pre_init()
global_gconfclient,
GCONF/global_zoom,
err);
-
+ global_detail_zoom = gconf_client_get_int (
+global_gconfclient,
+GCONF/global_detail_zoom,
+err);
=== modified file 'src/map_management.c'
--- src/map_management.c 2009-10-04 17:46:35 +
+++ src/map_management.c 2009-10-26 01:07:04 +
@@ -35,6 +35,8 @@ load_tile( gchar *dir,
int offset_x,
int offset_y)
{
+ int detail_zoom=global_detail_zoom; /* round (dpi/96.0)? */
+ int detail_scale=(int) pow (2.0, (float) detail_zoom);
int overzoom=0;
int upscale=1;
gboolean tile_found = FALSE;
@@ -55,7 +57,10 @@ load_tile( gchar *dir,
}
else printf(no drawable - NULL\n);
-
+
+ upscale = detail_scale;
+ zoom -= detail_zoom;
+
for(overzoom=0; overzoom=3; overzoom++)
{
g_sprintf(filename, %s/%u/%u/%u.png, dir, zoom-overzoom, x/upscale, y/upscale);
@@ -72,7 +77,7 @@ load_tile( gchar *dir,
upscale *= 2;
}
- if(pixbuf overzoom)
+ if(pixbuf upscale 1)
{
GdkPixbuf *pixbuf_scaled = NULL;
@@ -154,7 +159,7 @@ load_tile( gchar *dir,
if (global_auto_download)
{
repo = global_curr_repo-data;
- download_tile(repo,zoom,x,y);
+ download_tile(repo,zoom,x/detail_scale,y/detail_scale);
}
else
{
=== modified file 'src/callbacks.c'
--- src/callbacks.c 2009-09-26 02:35:15 +
+++ src/callbacks.c 2009-10-25 23:52:52 +
@@ -3910,3 +3910,52 @@ on_item18_button_release_event (
repaint_all();
return FALSE;
}
+
+void
+activate_more_map_details (GtkMenuItem *menu_item, gpointer user_data)
+{
+ GError *error = NULL;
+ gboolean success = FALSE;
+
+ printf (enlarge details\n);
+
+ if (global_detail_zoom 0) {
+ global_detail_zoom--;
+
+ }
+
+ if (global_detail_zoom == 0) {
+ gtk_widget_set_sensitive (GTK_WIDGET (menu_item), FALSE);
+ }
+
+ success = gconf_client_set_int(
+global_gconfclient,
+GCONF/global_detail_zoom,
+global_detail_zoom,
+error);
+
+ repaint_all ();
+}
+
+void
+activate_larger_map_details (GtkMenuItem *larger_item, GtkMenuItem *more_item)
+{
+ GError *error = NULL;
+ gboolean success = FALSE;
+
+ printf (shrink details\n);
+
+ global_detail_zoom++;
+
+ if (global_detail_zoom 0) {
+ gtk_widget_set_sensitive (GTK_WIDGET (more_item), TRUE);
+ }
+
+ success = gconf_client_set_int(
+global_gconfclient,
+GCONF/global_detail_zoom,
+global_detail_zoom,
+error);
+
+ repaint_all ();
+}
=== modified file 'src/callbacks.h'
--- src/callbacks.h 2009-09-26 02:35:15 +
+++ src/callbacks.h 2009-10-25 23:53:55 +
@@ -774,3 +774,9 @@ gboolean
on_item18_button_release_event
[wikireader]Different images of the wikireader
The hidden menus http://www.tuxbrain.com/en/content/wikireader-los-menus-ocultos-del-wikireader Spanish wikipedia work in progress http://www.tuxbrain.com/en/content/wikireader-wikipedia-en-espa%C3%B1ol-en-progreso 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
Re: (patch) new feature for tangoGPS: detail-scaling
please also sent your patches to Marcus Bauer (the author of TangoGPS) On Mon, Nov 2, 2009 at 4:18 PM, Joshua Judson Rosen roz...@geekspace.comwrote: Hi everybody, I've added a feature to my copy of tangoGPS, and thought that others might be interested: it allows the *details* in the map (e.g.: text, icons) to be scaled up (to show fewer details, but make the shown details bigger) or scaled down (to render the details smaller, but show more of them). This has made tangoGPS *much* more usable for me on my FreeRunner, because I can actually read the labels for streets, etc. without holding the screen very close to my face :) (I guess that the OpenStreetMap tiles are rasterised expecting something like 96 DPI, but the FreeRunner's display runs at ~280 DPI, so text and icons used in OSM tiles is *very* small when displayed on the FreeRunner without any upsampling; `zooming the details' by 1 level makes everything legible at arm's length, and zooming the details by 2 levels makes the text easy to read even at a glance while driving). I've attached 2 separate patches: one patch that adds the `back end' of the feature (a new `global_detail_zoom' variable with the corresponding gconf hooks, and some minor-changes to the tile-loading code), and another patch that adds the front-end GUI for the feature (an additional submenu in the map screen, and a couple of new callbacks to accompany the new menu-items). I added the submenu and menu-items manually in interface.c--it looks like Marcus is using Glade to maintain the GUI, but I'm not entirely sure (I didn't see glade-file in the tarball...); if he still *is* using Glade, then it may make more sense to defined these submenus via Glade. -- Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr. ___ 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: (patch) new feature for tangoGPS: detail-scaling
On Mon, 2 Nov 2009 16:30:02 +0100 Yorick Moko yorickm...@gmail.com wrote: please also sent your patches to Marcus Bauer (the author of TangoGPS) Joshua did already - I am just sitting on a big pile of backlog email. Regards, Marcus On Mon, Nov 2, 2009 at 4:18 PM, Joshua Judson Rosen roz...@geekspace.comwrote: Hi everybody, I've added a feature to my copy of tangoGPS, and thought that others might be interested: it allows the *details* in the map (e.g.: text, icons) to be scaled up (to show fewer details, but make the shown details bigger) or scaled down (to render the details smaller, but show more of them). This has made tangoGPS *much* more usable for me on my FreeRunner, because I can actually read the labels for streets, etc. without holding the screen very close to my face :) (I guess that the OpenStreetMap tiles are rasterised expecting something like 96 DPI, but the FreeRunner's display runs at ~280 DPI, so text and icons used in OSM tiles is *very* small when displayed on the FreeRunner without any upsampling; `zooming the details' by 1 level makes everything legible at arm's length, and zooming the details by 2 levels makes the text easy to read even at a glance while driving). I've attached 2 separate patches: one patch that adds the `back end' of the feature (a new `global_detail_zoom' variable with the corresponding gconf hooks, and some minor-changes to the tile-loading code), and another patch that adds the front-end GUI for the feature (an additional submenu in the map screen, and a couple of new callbacks to accompany the new menu-items). I added the submenu and menu-items manually in interface.c--it looks like Marcus is using Glade to maintain the GUI, but I'm not entirely sure (I didn't see glade-file in the tarball...); if he still *is* using Glade, then it may make more sense to defined these submenus via Glade. -- Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr. ___ 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
zzz Freerunner headphones and screen protector - free to a good home!
Hi all, As the subject says: I have a set of Freerunner headphones and an Invisible Shield screen protector (screen only) available to anyone who wants them. I don't have a use for either - they've been cluttering up my bookshelf for over a year now - so I've decided to pass them on to someone who might use them. If you want either or both of these items then send me an email with your address and I'll send them out. Australians will get preference, to keep down postage costs, but the offer is open worldwide (If the recipient wants to cover the cost of postage I'd appreciate it, but it's up to them). The screen protector is still in the box unused. The headphones I think I used once, to see if they worked. I'll try them again before I send them off, to make sure they still work. Thank you! Chris. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Debian cannot start wicd
Hi I cannot start wicd when I say wicd in command prompt I get : File /usr/share/wicd/wicd-daemon.py, line 44, in module import gobject ImportError: No module named gobject what do I need to install ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debian cannot start wicd
what do I need to install python-gobject i'd say ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] Hardware
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: Debian cannot start wicd
Yes already have it, I think it is because I updated to python2.5 On Mon, Nov 2, 2009 at 10:48 PM, arne anka openm...@ginguppin.de wrote: what do I need to install python-gobject i'd say ___ 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: Debian cannot start wicd
is wicd running with python2.5? what's the shebang? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debian cannot start wicd
no wicd isn't running with python2.5 i installed python2.5 i did a dpkg-reconfigure python-gtk2 now i get some syntax error now i get the error On Mon, Nov 2, 2009 at 11:43 PM, arne anka openm...@ginguppin.de wrote: is wicd running with python2.5? what's the shebang? ___ 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: Debian cannot start wicd
the error is : Traceback (most recent call last): File /usr/share/wicd/wicd-daemon.py, line 45, in module import dbus File /usr/lib/pymodules/python2.5/dbus/__init__.py, line 73, in module from dbus._version import version, __version__ File /usr/lib/pymodules/python2.5/dbus/_version.py, line 1 /usr/lib/pymodules/python2.5 ^ SyntaxError: invalid syntax On Mon, Nov 2, 2009 at 11:50 PM, Aditya Gandhi aditya...@gmail.com wrote: no wicd isn't running with python2.5 i installed python2.5 i did a dpkg-reconfigure python-gtk2 now i get some syntax error now i get the error On Mon, Nov 2, 2009 at 11:43 PM, arne anka openm...@ginguppin.de wrote: is wicd running with python2.5? what's the shebang? ___ 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: QtMoko - /opt/qtmoko/bin/lan-network
On Friday 30 of October 2009 18:33:35 Torfinn Ingolfsen wrote: Hello, On Wed, Sep 23, 2009 at 11:10 PM, Torfinn Ingolfsen tin...@gmail.comwrote: Here is another: If you runt WPA-PSK with AES you will get this output from the script: + . /root/Settings/Network/wireless/eth0 + WIRELESS_ESSID=kg4 + WIRELESS_AUTH_MODE=WPA-PSK + WIRELESS_WPA_PSK=j85first + WIRELESS_PAIRWISE=CCMP TKIP /root/Settings/Network/wireless/eth0: 1: TKIP: not found + WIRELESS_GROUP=CCMP TKIP /root/Settings/Network/wireless/eth0: 1: TKIP: not found To fix that, change lines 277 and 278 into: echo WIRELESS_PAIRWISE=\CCMP TKIP\ $TMP_FILE; echo WIRELESS_GROUP=\CCMP TKIP\ $TMP_FILE; It seems these two fixes aren't in the lan-network script used in QtMoko v14. Perhaps it should be fixed? Hi Torfinn, sorry for delay - i have missed the patch. It's now in my git (although not tested yet, because i am quite busy with other stuff). Thanks Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] Black Screen of Death - Won't resume from standby
There could also be an other explanation. In cases that you're not killing and starting special processes in the pre- and post- suspend event, and it freezes anyway, the following reasons could be used as explanation: * It dies at suspend time: Sometimes the underlying hardware-near controller layer aka. BIOS missunderstands S3 as S0. (Case with my old Phoenix-BIOS on my very very old laptop until upgrade) * Sometimes it dies on writing the staging and going to sleep * Sometimes it has corruption in staged data stored in RAM, but it doesnt remark it and dies on resuming. * Sometimes it resumes, but the ACPI controll is not given back to the OS, and its still in sleep mode, meaning: ** nearly black screen (You can see images, if you look from near, but it doesnt habe illumination in the background lights) ** Wifi is down and wont come up unless you reboot ** Same as for wifi for sound - As often as you suspend and resume, as higher is the posibility of getting corrupted RAM content == Black screen == RESET greatings leviathan signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: zzz Freerunner headphones and screen protector - free to a good home!
Hi Chris, Thank you for your generous offer - I have sent you an email with my details. On Tue, Nov 3, 2009 at 2:07 AM, Chris Hogan hodgin...@gmail.com wrote: Hi all, As the subject says: I have a set of Freerunner headphones and an Invisible Shield screen protector (screen only) available to anyone who wants them. I don't have a use for either - they've been cluttering up my bookshelf for over a year now - so I've decided to pass them on to someone who might use them. If you want either or both of these items then send me an email with your address and I'll send them out. Australians will get preference, to keep down postage costs, but the offer is open worldwide (If the recipient wants to cover the cost of postage I'd appreciate it, but it's up to them). The screen protector is still in the box unused. The headphones I think I used once, to see if they worked. I'll try them again before I send them off, to make sure they still work. Thank you! Chris. ___ 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: [All] Black Screen of Death - Won't resume from standby
That sounds quite reasonable - I wasn't trying to point fingers - just describing the experience I had. yesterday I had my FR die with a BSOD 4 times - before I installed omnewrotate on this install I hadn't seen a BSOD at all. I've just changed the default behavior for omnewrotate to 'Off' an hour or two ago, I'm going to run for a few days and see if that impacts things... Warren On Sun, Nov 1, 2009 at 9:29 AM, Rui Miguel Silva Seabra r...@1407.orgwrote: Hi, As you go into suspend, a script is called that *stops* (kills the process) omnewrotate. As you resume, a script is called that starts omnewrotate. So: 1) as you suspend, omnewrotate is *not* even working. 2) only after resume is completed does omnewrotate get started Conclusion: omnewrotate doesn't affect suspend/resume cycles. :) This scripts were place early on in it's development as after resuming omnewrotate couldn't get any data from the accelerometers (let alone my fears that keeping the device open could affect resume). Rui On Sat, Oct 31, 2009 at 01:03:29PM -0400, Warren Baird wrote: I just started noticing this on an shr-u build updated in early sept. The only thing I've changed lately is installing omnewrotate. I also noticed it on an install of the shr-testing candidate, that also had omnewrotate installed. I'm going to keep omnewrotate installed for a while and see how often I get the BSOD. Then I'll uninstall or disable omnewrotate and see what happens. Warren On Sat, Oct 31, 2009 at 4:27 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: Steven ** schrieb: I've seen this several times with SHR-Unstable and now with Android. So, I'd say it's something that is common among these distro's. Is it seen on all distros? Is it the kernel? Hardware bug? Bootloader issue? Any clues how to debug this or what might cause it? I know I'm not the only one that sees it. How are others dealing with these random lock-ups? i have this too with my system gta02v6 latest shr-u. sometimes i thought, it has to do with gps, but i am not sure about. sometimes i think, problem it is changing cell while sleeping. ___ 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 -- ___ 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
Oh you were lucky! v0.01
Hi, I made a small (demo) script which asks for a string on a commandline, matches that string with a youtube video, and will play that video using mplayer. Framerate is not that high, but both video and sound are comprehensible. Please take a look here: http://code.google.com/p/oywl/ Please email me when you want to be added to the list of commiters and help out. I want to write a GUI for it that should become as usable as eldentica (maybe we should steal some code). When I got a little spare time this week I'll add this project to opkg. If someone else is into packaging, feel free to do so. Pieter ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps 0.9.8
2009/11/2 Marcus Bauer marcus.ba...@gmail.com: I have currently no working OE here and there are now too many distribs. However, you can try the armel.deb. Just extract the tangogps binary from the .deb (do it on your desktop/laptop) and copy it to your Neo. .deb packages can be installed natively with opkg. you'll need to edit /etc/opkg/arch.conf, and add 'arch armel 36' (without the quotes) to the bottom then do wget http://www.tangogps.org/downloads/tangogps_0.9.8-1_armel.deb and opkg install tangogps_0.9.8-1_armel.deb ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[wikireader] Images on the WR not so imposible :P [was [wikireader]Error on parsing the spanish wikipedia]
2009/10/31 Sean Moss-Pultz s...@openmoko.com: On Fri, Oct 30, 2009 at 11:29 PM, Laszlo KREKACS laszlo.krekacs.l...@gmail.com wrote: On Fri, Oct 30, 2009 at 4:22 PM, David Reyes Samblas Martinez da...@tuxbrain.com wrote: Are you uploading this changes to git? can I take a look? Btw is there any plan to implement images rendering? Math (images) are on our roadmap. Hopefully before the end of this year. The screen is only 1bit. So anything else would look kinda funny. -Sean Well due I have clear than Internationalization and running other apps are totally posible and in fact it can be done without much hacking, I have spend some time investigating the posibility of include image other than maths on the device and I think is at least more closer than it can seems. I have find a process[1] I think it can be industrialized to transform any image of the wikipedia to one more or less good to the device is clear than we can expect a real time 3D zoomable render on the WR but I think results are quite promising Just some questions, is hard to do a image viewer able to scroll vertically as we do in text? Any good tutorial of scripting using gimp? An now some numbers the average image are 10kb so with the hypotesis than there are one image per article (yes I know there articles with more than a image but there a lot of articles without images) there will be about 3.000.000 images so 30Gb of images :P there are any 32Gb uSD cards out there? I have to do a more in depth analisis on how many images(meaningful) are there using the data on the dumps of wikipedia so we will see. [1]http://www.tuxbrain.com/en/content/images-wikireader-posible ___ 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]
2009/11/3 David Reyes Samblas Martinez da...@tuxbrain.com: 2009/10/31 Sean Moss-Pultz s...@openmoko.com: On Fri, Oct 30, 2009 at 11:29 PM, Laszlo KREKACS laszlo.krekacs.l...@gmail.com wrote: On Fri, Oct 30, 2009 at 4:22 PM, David Reyes Samblas Martinez da...@tuxbrain.com wrote: Are you uploading this changes to git? can I take a look? Btw is there any plan to implement images rendering? Math (images) are on our roadmap. Hopefully before the end of this year. The screen is only 1bit. So anything else would look kinda funny. -Sean Well due I have clear than Internationalization and running other apps are totally posible and in fact it can be done without much hacking, I have spend some time investigating the posibility of include image other than maths on the device and I think is at least more closer than it can seems. I have find a process[1] I think it can be industrialized to transform any image of the wikipedia to one more or less good to the device is clear than we can expect a real time 3D zoomable render on the WR but I think results are quite promising Just some questions, is hard to do a image viewer able to scroll vertically as we do in text? Any good tutorial of scripting using gimp? An now some numbers the average image are 10kb so with the hypotesis than there are one image per article (yes I know there articles with more than a image but there a lot of articles without images) there will be about 3.000.000 images so 30Gb of images :P there are any 32Gb uSD cards out there? I have to do a more in depth analisis on how many images(meaningful) are there using the data on the dumps of wikipedia so we will see. [1]http://www.tuxbrain.com/en/content/images-wikireader-posible ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community [...]It's clear we can NOT expect 3D render[...] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: zzz Freerunner headphones and screen protector - free to a good home!
Hi all, The screen protector and headphones have been claimed, so this offer is now closed. Apologies to everyone who missed out! Chris. On Mon, Nov 2, 2009 at 4:07 PM, Chris Hogan hodgin...@gmail.com wrote: Hi all, As the subject says: I have a set of Freerunner headphones and an Invisible Shield screen protector (screen only) available to anyone who wants them. I don't have a use for either - they've been cluttering up my bookshelf for over a year now - so I've decided to pass them on to someone who might use them. If you want either or both of these items then send me an email with your address and I'll send them out. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ericsson releases free cell-id lookup API
Is it very much different than the Google location API? Definately - It only gives you 1 cell position (latitude/longitude, is this the position of the cell tower?), a locality name and an accuracy measure in meters per API call. This is unlike the Google API where the whole locating operation can be considered server side and other attributes such as rxlevel and timing advance can be considered. So you would have to develop your own application to combine results from both serving and neighbour cells in a meaningful way (their example only tells you the serving cell location) and you still would not have rxlevel/timing advance information. All cell-id based positioning is done server side (unless you have the whole database in your device) Do you have any indication that Google is using rxlevels and timing advance? Are there any devices that supports access to these measures? To do any kind of combination you still need to extract all of the data from the device and send to the server. Google doesn't have access to any kind of data from the network. Would be interesting with some more information around this if you have. -- View this message in context: http://n2.nabble.com/Ericsson-releases-free-cell-id-lookup-API-tp3869908p3936976.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
