Re: Tasks Client for FR
Hi, try the apps by knj - there's a google calendar app (should be adding other backends later), and an e-mail client, with support for imap Thanks - will try those. -- View this message in context: http://n2.nabble.com/Tasks-Client-for-FR-tp2609094p2609563.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
Re: Problems in openmoko-messages
Hello list! I still have an error Generating locales... en_US.UTF-8...cannot map archive header: Invalid argument postinst script returned status 1 Collected errors: * ERROR: shr-utf8.postinst returned 1 but after installing xmodmap package from http://lucky.awardspace.co.uk/openmoko I can type and send SMS messages on Russian language without any problem. I have by the way another problem with localisation - cannot add new contact with russian name to the sim card... 2009/4/9 Ingvaldur Sigurjonsson > Paul Fertser wrote: > >> On Tue, Apr 07, 2009 at 09:57:21AM +0400, forin...@gmail.com wrote: >> >>> Hello, Paul! >>> I've tried to install your package - >>> [1]http://www.stosb.com/openmoko/shr-utf8_0.1_armv4t.ipk >>> but had some problems. Here is the output from the opkg installer: >>> >> >> Not my package, btw. It's TAsn who investigated and mostly solved the >> issue. >> >> Fix is already in shr-unstable, feel free to update. >> >> And btw, next time you top-post, i won't even read your mail, sorry to say >> that. >> >> I too is having the same problem with locale-gen, after having installed > the shr-utf8*-packages. > The locale-gen is run by shr-utf8.postinst but it failes with the same > message as mentioned above. > > I modified /usr/sbin/locale-gen and added '-v' to to parameterlist for > 'localedef' and re-ran it manually. > > r...@om-gta02 ~ $ /usr/sbin/locale-gen > > Generating locales... > en_US.UTF-8.../usr/share/i18n/locales/en_US:7: non-symbolic character > value should not be used > /usr/share/i18n/locales/en_US:8: non-symbolic character value should not be > used > /usr/share/i18n/locales/en_US:9: non-symbolic character value should not be > used > /usr/share/i18n/locales/en_US:11: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:14: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:15: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:16: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:17: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:19: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:20: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:21: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:22: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:23: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:24: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:25: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:26: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:27: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:28: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:29: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:34: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_GB:50: non-symbolic character value should not > be used > /usr/share/i18n/locales/i18n:1328: non-symbolic character value should not > be used > /usr/share/i18n/locales/i18n:1575: non-symbolic character value should not > be used > /usr/share/i18n/locales/i18n:1615: non-symbolic character value should not > be used > /usr/share/i18n/locales/i18n:1647: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_GB:53: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_GB:59: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_GB:149: non-symbolic character value should not > be used > /usr/share/i18n/locales/en_US:40: non-symbolic character value should not > be used > /usr/share/i18n/locales/iso14651_t1:3: non-symbolic character value should > not be used > /usr/share/i18n/locales/translit_neutral:10: non-symbolic character value > should not be used > /usr/share/i18n/locales/translit_neutral:11: non-symbolic character value > should not be used > /usr/share/i18n/locales/translit_neutral:12: non-symbolic character value > should not be used > /usr/share/i18n/locales/translit_neutral:13: non-symbolic character value > should not be used > /usr/share/i18n/locales/translit_neutral:14: non-symbolic character value > should not be used > /usr/share/i18n/locales/translit_neutral:15: non-symbolic character value > should not be used > /usr/share/i18n/locales/translit_neutral:16: non-symbolic character value > should not be used > /usr/share/i18n/locales/translit_neutral:17: non-symbolic character value > should not be used > LC_NAME: field `name_gen' not defined > LC_IDENTIFICATION: field `audience' not defined > LC_IDENTIFICATION: field `application' not defined > LC_IDENTIFICATION: field `abbreviation' not
Re: Tasks Client for FR
2009/4/9 c_c : > there are a couple already in the om repos (one by qtopia, on be om), but > there's no way of getting data from an external source > > Well, the qtopia one can't run on FSO easily. The OM one was the gtk one (I > think hackable has it too) - don't know what the current status is - but that > should be ok. > > IMO the ability to sync is something that is desperately needed. > > I am actually looking at doing something with opensync - but haven't found > the time yet. Anyhow - with most of the code bits needed already done for > intone - let me see what I can come up with. I think an elementary based > implementation, with a sqlite backend and the ability to sync with a desktop > will be really handy. > > Then of course - going ahead - we need an email client and a calendar app > (with the ability to sync to a desktop). Ubuntu 9.04 is doing some nice > things with notification. Maybe everything can be put together. Will be > plenty of work though! > -- try the apps by knj - there's a google calendar app (should be adding other backends later), and an e-mail client, with support for imap http://wiki.openmoko.org/wiki/Knjrepository ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Upadated - Intone (0.22) Elementary based mplayer frontend
Hi, ERROR The latest version has an error with the timer. The slider runs at 2x and the next song gets played after half the time. Will post a fix soon. -- View this message in context: http://n2.nabble.com/Intone-%280.20---alpha-release%29-Elementary-based-mplayer-frontend-tp2587826p2609410.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
Re: Tasks Client for FR
Hi, there are a couple already in the om repos (one by qtopia, on be om), but there's no way of getting data from an external source Well, the qtopia one can't run on FSO easily. The OM one was the gtk one (I think hackable has it too) - don't know what the current status is - but that should be ok. IMO the ability to sync is something that is desperately needed. I am actually looking at doing something with opensync - but haven't found the time yet. Anyhow - with most of the code bits needed already done for intone - let me see what I can come up with. I think an elementary based implementation, with a sqlite backend and the ability to sync with a desktop will be really handy. Then of course - going ahead - we need an email client and a calendar app (with the ability to sync to a desktop). Ubuntu 9.04 is doing some nice things with notification. Maybe everything can be put together. Will be plenty of work though! -- View this message in context: http://n2.nabble.com/Tasks-Client-for-FR-tp2609094p2609376.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
Re: Tasks Client for FR
2009/4/9 c_c : > Hi, > I'm really missing a good tasks client for the FR. Coming from a Palm > background, I find the absence of good 'smart'phone components a serious > drawback. > So - I think I might as well code one myself. But before I do that - does > anyone know of a good client I might have overlooked? > I did see Fido - but it didn't really meet my requirements. Any ideas > whether it's being developed or not - or is there something better? > -- there are a couple already in the om repos (one by qtopia, on be om), but there's no way of getting data from an external source imo, tasque would be great, if only it cached data locally. failing that, i'd be tempted to use rtm, and get my tasks as an rss feed, cached locally in a feed reader ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Tasks Client for FR
Hi, I'm really missing a good tasks client for the FR. Coming from a Palm background, I find the absence of good 'smart'phone components a serious drawback. So - I think I might as well code one myself. But before I do that - does anyone know of a good client I might have overlooked? I did see Fido - but it didn't really meet my requirements. Any ideas whether it's being developed or not - or is there something better? -- View this message in context: http://n2.nabble.com/Tasks-Client-for-FR-tp2609094p2609094.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
Re: Upadated - Intone (0.22) Elementary based mplayer frontend
Hi, To follow up my own e-mail (again), this seems to be a ogg issue. mp3s have a proper counter pace, though the value is in s, not m:ss All minor points welcome too. :-) I just tried randomly pressing buttons and changing playlists, and I could see the counter go to 2x after changing the selected playlist and pressing the next button. Must have missed setting up the timer on playlist change. Will sort it out today. I'm aware of the m:s and not m:ss issue. Will fix that one today too - I think it slipped my mind when I was working on the .22 release. Really miss a good tasks client for the FR. Thanks for pointing that out. -- View this message in context: http://n2.nabble.com/Intone-%280.20---alpha-release%29-Elementary-based-mplayer-frontend-tp2587826p2609085.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
Re: Upadated - Intone (0.22) Elementary based mplayer frontend
Interesting thing. When I'm playing songs, the slider move and the counter increments, though faster then the song, with little relevance to the track time/position. The counter seems to go up to the mid 200s (244, 266, etc) and when it ends, the track changes, regardless of the actual some position. Is this a known issue? Or a local one to my FR? Kind regards, Cameron On Wed, Apr 8, 2009 at 9:45 PM, Cameron Frazier wrote: > Very slick. Nice work c_c. > > Question for the group though. > > I have mp3 files driving mplayer to about 10%, while ogg files come in > about 45% of cpu. Is there way to reduce this, or is it simply a > function of the format? I seem to remember some talk about a lack of > an integer decoder for ogg, but frankly, the understandings audio > codecs elude me. > > Kind regards, > > Cameron > > On Wed, Apr 8, 2009 at 12:19 PM, c_c wrote: >> >> Hi, >> >> However if you want to test it with Om2008, use this [1] e17 version >> (following the instruciton I posted at [2]) to run it. >> >> Will try that and see what gives. >> >> Also, here is the latest version. Now, if you exit after pausing a playing >> file - intone will start with that song and position selected. >> >> intone_0.22_arm.ipk >> -- >> View this message in context: >> http://n2.nabble.com/Intone-%280.20---alpha-release%29-Elementary-based-mplayer-frontend-tp2587826p2606320.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 >> > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Upadated - Intone (0.22) Elementary based mplayer frontend
To follow up my own e-mail (again), this seems to be a ogg issue. mp3s have a proper counter pace, though the value is in s, not m:ss (minor point really, I shouldn't complain) Kind regards, Cameron On Wed, Apr 8, 2009 at 10:02 PM, Cameron Frazier wrote: > Interesting thing. When I'm playing songs, the slider move and the > counter increments, though faster then the song, with little relevance > to the track time/position. The counter seems to go up to the mid > 200s (244, 266, etc) and when it ends, the track changes, regardless > of the actual some position. > > Is this a known issue? Or a local one to my FR? > > Kind regards, > > Cameron > > On Wed, Apr 8, 2009 at 9:45 PM, Cameron Frazier > wrote: >> Very slick. Nice work c_c. >> >> Question for the group though. >> >> I have mp3 files driving mplayer to about 10%, while ogg files come in >> about 45% of cpu. Is there way to reduce this, or is it simply a >> function of the format? I seem to remember some talk about a lack of >> an integer decoder for ogg, but frankly, the understandings audio >> codecs elude me. >> >> Kind regards, >> >> Cameron >> >> On Wed, Apr 8, 2009 at 12:19 PM, c_c wrote: >>> >>> Hi, >>> >>> However if you want to test it with Om2008, use this [1] e17 version >>> (following the instruciton I posted at [2]) to run it. >>> >>> Will try that and see what gives. >>> >>> Also, here is the latest version. Now, if you exit after pausing a playing >>> file - intone will start with that song and position selected. >>> >>> intone_0.22_arm.ipk >>> -- >>> View this message in context: >>> http://n2.nabble.com/Intone-%280.20---alpha-release%29-Elementary-based-mplayer-frontend-tp2587826p2606320.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 >>> >> > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Upadated - Intone (0.22) Elementary based mplayer frontend
Hi, Very slick. Nice work c_c. Thanks! Glad you liked it. Let me know what you didn't like too. I have mp3 files driving mplayer to about 10%, while ogg files come in about 45% of cpu. mplayer builds are generally compiled to use libvorbis which is a floating point implementation. Its easy enough to compile tremor - which is an integer library (provides libidecvorbis IIRC) and is a drop in replacement. I have tried tremor and here's the CPU usage ogg 44100 2 channel enc208 mplayer tremor 47.6% - 52.7% 18.5% - 20% Unfortunately, I haven't been able to patch mplayer build to use tremor since I don't really know how the entire bitbake process works. BTW, mplayer has a built-in option to use tremor in its ./configure file. If someone could point me in a direction that tells me how to go about changing the library being used for the build - or do it him/her self - that'll just be great and should bring down CPU usage to more acceptable levels. *** Also, I'm thinking of forking intone to handle videos as well. Mostly same code - but with a gui optimised for videos (I'm thinking Landscape mode). But apparently I'll need another version of mplayer-glamo. Things would get simpler if the standard mplayer ipk could come with the glamo patches and linked to tremor. Any Ideas? -- View this message in context: http://n2.nabble.com/Intone-%280.20---alpha-release%29-Elementary-based-mplayer-frontend-tp2587826p2609019.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
Re: Upadated - Intone (0.22) Elementary based mplayer frontend
Very slick. Nice work c_c. Question for the group though. I have mp3 files driving mplayer to about 10%, while ogg files come in about 45% of cpu. Is there way to reduce this, or is it simply a function of the format? I seem to remember some talk about a lack of an integer decoder for ogg, but frankly, the understandings audio codecs elude me. Kind regards, Cameron On Wed, Apr 8, 2009 at 12:19 PM, c_c wrote: > > Hi, > > However if you want to test it with Om2008, use this [1] e17 version > (following the instruciton I posted at [2]) to run it. > > Will try that and see what gives. > > Also, here is the latest version. Now, if you exit after pausing a playing > file - intone will start with that song and position selected. > > intone_0.22_arm.ipk > -- > View this message in context: > http://n2.nabble.com/Intone-%280.20---alpha-release%29-Elementary-based-mplayer-frontend-tp2587826p2606320.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 > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone OGG Support
Hi, Could you check the output of mplayer when loading an ogg file? Mine (a very recent svn build) crashes saying that it has been called an unknown CPU call... :o There's another issue. mplayer builds are generally compiled to use libvorbis which is a floating point implementation. Its easy enough to compile tremor - which is an integer library (provides libidecvorbis IIRC) and is a drop in replacement. I have tried tremor and here's the CPU usage ogg 44100 2 channel enc208 mplayer tremor 47.6% - 52.7% 18.5% - 20% Unfortunately, I haven't been able to patch mplayer build to use intone since I don't really know how the entire bitbake process works. BTW, mplayer has a built-in option to use tremor in its ./configure file. Could you take a look at this - or point me in a direction that tells me how to go about changing the library being used. This will really help. Thanks. -- View this message in context: http://n2.nabble.com/Intone-OGG-Support-tp2608553p2608935.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
Re: Intone OGG Support
Hi, Hi. It would seem, since I can't get Intone to actually handle any individual songs, that it lacks support for OGG. What's up with that?! And more importantly, how do I get OGG support? :) Ha! That was my oversight with release 0.20. I was only scanning for .oga files. Try the newer version .22. That scans for .ogg as well. And, as I've asked before - I am only scanning for .ogg, .oga, .mp3, .m4a and .wma files as of now. Any other types I should be looking at? -- View this message in context: http://n2.nabble.com/Intone-OGG-Support-tp2608553p2608877.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
Re: Autorun for SD card mechanism?
Yes, I agree with that when data should be used from sdcard, if there are these files. That would be the quick hack in my mind. But I brought up my points in case if there are applications for specific distros and versions that may be incompatible to each other? I don't know if the issue will make the whole thing too complex, but I thought to discuss about it. I have had a case where I gone back to an older version, but it didn't worked any more and I didn't know, wich versions do fit together. Am 09.04.2009 um 01:02 schrieb Pander: > A directory called > /media/card/post/linked > with e.g. files like > /media/card/post/linked/root/.cellhunter > /media/card/post/linked/root/Maps/ > the original /root/.cellhunter file and /root/Maps directory will be > deleted and a soft link will be created to the ones in linked > directory. > > Lothar Behrens wrote: >> Ok, as the idea was good, more thoughts: >> >> 1.) Using the sd card to store jet installed application information >> is not good. Then it would only run the first distro switch. >> 2.) Keep in mind, that packages from the usual opkg may be installed >> in later releases. And it may or may not reinstalled. >> 3.) Using a database repository in the net to update a local database >> of applications that may installable without problems >> per distro. >> 4.) If a user add's an application with opkg, a choice could be made >> to activate autoinstall for later switches. >> 5.) If the application isn't in the database on the net, or the local >> copy, add it but mark it as untested. >> 6.) The database could be used for a hitlist of installed >> applications >> that would really used, because a reinstall could be counted. >> 7.) Untested applications that should be installed, could be >> complained about and a choice could be made. >> 8.) Feedback if successfully installed application makes problems. >> The >> user should be asked some time later and he/she may make choices >> as of like this: 'App1 is usable', 'App2 has problems on this >> distro' >> and so forth. >> >> That way, we get feedback of the most used applications, we see the >> quality in the installability and we may spot conflicts. >> >> Next, if a distro decides to add an application as default, it could >> be marked as installed by that distro. This leads propably to an >> update process >> per distro and thus a local copy (if there will be really some for >> offline installations) could either removed any time - by asking or >> the app on the >> card could also get updated. >> >> Keep in mind that there are issues with the applications data. If >> this >> data is not at least backed up to sd card, a distro switch may kill >> your data :-) >> >> Also keep in mind, that users don't want to give that feedback. We >> don't do it like some companies do collect their statistical :-) >> >> It is not easy and I don't like to only create a quick hack, that >> would not work at all. >> >> Lothar >> >> Am 08.04.2009 um 16:28 schrieb Pander: >> >>> in the first boot, also make the most default choices of all when >>> /media/card/post directory is found. e.g. English, Illume SHR theme, >>> ..., next, next, next, finish ;) >>> >>> Johny Tenfinger wrote: Hmm... Maybe there is a place for some app... "shr-firstboot" :) It could also replace first boot creator from e17, which isn't very useful on Neos... 2009/4/8, Pander : > good idea. I already have all those files on SD but after each > upgrade > have to install them manually, which is annoying. > > I would suggest something like: > > 1) notify user to do an opkg update and opkg upgrade first > > 2) change to post installation directory > cd /media/card/post > > 3) change to package directory and install all that is in there > cd packages > opkg install *.ipk *.opk > cd .. > > 4) override files > cd override > [[copy all files to root of system, e.g. override/etc/blabla to > /etc/blabla]] > cd .. > > 5) path files > cd patches > [[apply all patchers to root of system]] > cd .. > > off course documenting your changes via patches/diffs is preferred > over > overriding, allowing improvements in other parts of the files via > opkg > upgrade before you start. > > Johny Tenfinger wrote: >> Shortly: Let's write it ;) >> >> 2009/4/8, Lothar Behrens : >>> There is an idea rattling in my head about the following issue: >>> >>> Given I have a micro SD card and that would have all here, >>> what is >>> about a bootstrap mechanism to >>> post install packages that are laying on that card to be >>> installed, >>> when a new image is started at first time? >>> >>> Like the autorun of a CD, this would help to ease the distro >>> switch >>> but keep my usual applications that otherwise >>> have to be installed ma
Intone OGG Support
Hi. It would seem, since I can't get Intone to actually handle any individual songs, that it lacks support for OGG. What's up with that?! And more importantly, how do I get OGG support? :) -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone OGG Support
The Digital Pioneer wrote: > Hi. It would seem, since I can't get Intone to actually handle any > individual songs, that it lacks support for OGG. What's up with that?! > And more importantly, how do I get OGG support? :) It should manage it, but I've some problems with recent mplayer builds and ogg files. Could you check the output of mplayer when loading an ogg file? Mine (a very recent svn build) crashes saying that it has been called an unknown CPU call... :o -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer wiki page erroneous axes ?
Le 14342ième jour après Epoch, ri...@happyleptic.org écrivait: > Well, some confusion here. Yes, probably because of mixing gravity, force, acceleration, inertia, etc... :) > OK, let's imagine a _perfect_ accelerometer. > This device would report only acceleration. So, when the phone lies on the > table, it would report 0 (neglecting the rotation of earth here > :-)). Please, don't stop earth rotation, because my weight will increase too much :( The _perfect_ accelerometer is measuring 2 forces: The gravity, and the table reaction against the phone fall. These 2 forces are in opposite directions, then accel value is 0. If you shift left (or right) your _perfect_ accelerometer, it will (probably) indicate a X acceleration value. But only if it has no mass so no inertia :) The Freerunner accelerometers are able to compare these 2 forces, and so it compares gravity vs reaction, or force vs inertia. > Now, lets suppose that this perfect accelerometer is not calibrated correctly, > and offset every values by 900. It will then report first a value >900, > then 900, then a value <900. Your idea works only for the accelerometer Z, in case of the phone is left horizontaly, screen up. X and Y accelerometers don't have the "calibration error" in this case. And if your phone is falling, the accel values will turn to zero, even in the earth gravity field. If you will try this, please consider using a pillow (for example) to avoid crash ;) > (*): our accelerometer is not perfect, but not because of a random > offset. It is not perfect because it has no mean to distinguish between > an actual acceleration from the effect of gravity. > This is not a > defect and there is no need to send the phone back to OpenMoko :-) I agree ;) > because > it is just how nature work > (http://en.wikipedia.org/wiki/File:Elevator_gravity.svg) > The effect of gravity (downwards) is the same as an acceleration > (upwards!!) Not the same, but we can't make any differences just looking at the trajectory. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Autorun for SD card mechanism?
A directory called /media/card/post/linked with e.g. files like /media/card/post/linked/root/.cellhunter /media/card/post/linked/root/Maps/ the original /root/.cellhunter file and /root/Maps directory will be deleted and a soft link will be created to the ones in linked directory. Lothar Behrens wrote: > Ok, as the idea was good, more thoughts: > > 1.) Using the sd card to store jet installed application information > is not good. Then it would only run the first distro switch. > 2.) Keep in mind, that packages from the usual opkg may be installed > in later releases. And it may or may not reinstalled. > 3.) Using a database repository in the net to update a local database > of applications that may installable without problems > per distro. > 4.) If a user add's an application with opkg, a choice could be made > to activate autoinstall for later switches. > 5.) If the application isn't in the database on the net, or the local > copy, add it but mark it as untested. > 6.) The database could be used for a hitlist of installed applications > that would really used, because a reinstall could be counted. > 7.) Untested applications that should be installed, could be > complained about and a choice could be made. > 8.) Feedback if successfully installed application makes problems. The > user should be asked some time later and he/she may make choices > as of like this: 'App1 is usable', 'App2 has problems on this distro' > and so forth. > > That way, we get feedback of the most used applications, we see the > quality in the installability and we may spot conflicts. > > Next, if a distro decides to add an application as default, it could > be marked as installed by that distro. This leads propably to an > update process > per distro and thus a local copy (if there will be really some for > offline installations) could either removed any time - by asking or > the app on the > card could also get updated. > > Keep in mind that there are issues with the applications data. If this > data is not at least backed up to sd card, a distro switch may kill > your data :-) > > Also keep in mind, that users don't want to give that feedback. We > don't do it like some companies do collect their statistical :-) > > It is not easy and I don't like to only create a quick hack, that > would not work at all. > > Lothar > > Am 08.04.2009 um 16:28 schrieb Pander: > >> in the first boot, also make the most default choices of all when >> /media/card/post directory is found. e.g. English, Illume SHR theme, >> ..., next, next, next, finish ;) >> >> Johny Tenfinger wrote: >>> Hmm... Maybe there is a place for some app... "shr-firstboot" :) It >>> could also replace first boot creator from e17, which isn't very >>> useful on Neos... >>> >>> 2009/4/8, Pander : good idea. I already have all those files on SD but after each upgrade have to install them manually, which is annoying. I would suggest something like: 1) notify user to do an opkg update and opkg upgrade first 2) change to post installation directory cd /media/card/post 3) change to package directory and install all that is in there cd packages opkg install *.ipk *.opk cd .. 4) override files cd override [[copy all files to root of system, e.g. override/etc/blabla to /etc/blabla]] cd .. 5) path files cd patches [[apply all patchers to root of system]] cd .. off course documenting your changes via patches/diffs is preferred over overriding, allowing improvements in other parts of the files via opkg upgrade before you start. Johny Tenfinger wrote: > Shortly: Let's write it ;) > > 2009/4/8, Lothar Behrens : >> There is an idea rattling in my head about the following issue: >> >> Given I have a micro SD card and that would have all here, what is >> about a bootstrap mechanism to >> post install packages that are laying on that card to be >> installed, >> when a new image is started at first time? >> >> Like the autorun of a CD, this would help to ease the distro >> switch >> but keep my usual applications that otherwise >> have to be installed manually. >> >> This would include SSH settings, WLAN settings, look and feel, and >> what ever may possible. >> >> What about it? >> >> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de >> Lothar Behrens >> Heinrich-Scheufelen-Platz 2 >> 73252 Lenningen >> >> >> >> >> >> >> >> >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > ___ > Openmoko c
Re: [Debian] How to get elementary?
Marcel, you can install e17 using this script: http://omicron.homeip.net/projects/ It will install e17 to /opt/e17 Then just adjust PKG_CONFIG_PATH , so system would find the libraries and include files/ Then you get Elementary from svn: svn co http://svn.enlightenment.org/svn/e/trunk/TMP/st/elementary When configuring don't forget to put --prefix=/opt/e17 option, so Elementary would be installed in /opt directory Hope this helps On Wed, Apr 8, 2009 at 6:35 PM, Patrick Beck wrote: > Hi, > > i' am interested, too. Perhaps anybody has a python-elementary-package > as well? > > with kind regards > > Patrick > > Am Sonntag, den 05.04.2009, 12:45 +0200 schrieb Marcel: >> Hello, >> >> Is there a elementary package for Debian yet? I've not yet gotten round >> crosscompiling anything (thanks to python...) and fear adding a selfcompiled >> elementary (in case I get that to work) to an E17 from the Debian repos, >> running into conflicts when that actually contains elementary. >> >> -- >> Marcel >> >> ___ >> 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
[SHR-Unstable] opkg upgrade fail
Hi. I'm trying to opkg upgrade on my SHR-unstable, and it refuses to work. It goes for a very long time, downloading packages, before finally crashing and burning with this: [Massive Snip] Downloading http://shr.bearstech.com/shr-unstable/ipk//armv4t/frameworkd_0.8.5.1+gitr1251+98cb27d2829179ccab6e520546de5d3b9b6104c3-r0_armv4t.ipk opkg: fork failed Segmentation fault How do I get it to upgrade? :\ -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problems in openmoko-messages
Paul Fertser wrote: > On Tue, Apr 07, 2009 at 09:57:21AM +0400, forin...@gmail.com wrote: >> Hello, Paul! >> I've tried to install your package - >> [1]http://www.stosb.com/openmoko/shr-utf8_0.1_armv4t.ipk >> but had some problems. Here is the output from the opkg installer: > > Not my package, btw. It's TAsn who investigated and mostly solved the > issue. > > Fix is already in shr-unstable, feel free to update. > > And btw, next time you top-post, i won't even read your mail, sorry to say > that. > I too is having the same problem with locale-gen, after having installed the shr-utf8*-packages. The locale-gen is run by shr-utf8.postinst but it failes with the same message as mentioned above. I modified /usr/sbin/locale-gen and added '-v' to to parameterlist for 'localedef' and re-ran it manually. r...@om-gta02 ~ $ /usr/sbin/locale-gen Generating locales... en_US.UTF-8.../usr/share/i18n/locales/en_US:7: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:8: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:9: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:11: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:14: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:15: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:16: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:17: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:19: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:20: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:21: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:22: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:23: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:24: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:25: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:26: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:27: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:28: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:29: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:34: non-symbolic character value should not be used /usr/share/i18n/locales/en_GB:50: non-symbolic character value should not be used /usr/share/i18n/locales/i18n:1328: non-symbolic character value should not be used /usr/share/i18n/locales/i18n:1575: non-symbolic character value should not be used /usr/share/i18n/locales/i18n:1615: non-symbolic character value should not be used /usr/share/i18n/locales/i18n:1647: non-symbolic character value should not be used /usr/share/i18n/locales/en_GB:53: non-symbolic character value should not be used /usr/share/i18n/locales/en_GB:59: non-symbolic character value should not be used /usr/share/i18n/locales/en_GB:149: non-symbolic character value should not be used /usr/share/i18n/locales/en_US:40: non-symbolic character value should not be used /usr/share/i18n/locales/iso14651_t1:3: non-symbolic character value should not be used /usr/share/i18n/locales/translit_neutral:10: non-symbolic character value should not be used /usr/share/i18n/locales/translit_neutral:11: non-symbolic character value should not be used /usr/share/i18n/locales/translit_neutral:12: non-symbolic character value should not be used /usr/share/i18n/locales/translit_neutral:13: non-symbolic character value should not be used /usr/share/i18n/locales/translit_neutral:14: non-symbolic character value should not be used /usr/share/i18n/locales/translit_neutral:15: non-symbolic character value should not be used /usr/share/i18n/locales/translit_neutral:16: non-symbolic character value should not be used /usr/share/i18n/locales/translit_neutral:17: non-symbolic character value should not be used LC_NAME: field `name_gen' not defined LC_IDENTIFICATION: field `audience' not defined LC_IDENTIFICATION: field `application' not defined LC_IDENTIFICATION: field `abbreviation' not defined LC_IDENTIFICATION: no identification for category `LC_MEASUREMENT' LC_CTYPE: table for class "upper": 1692 bytes LC_CTYPE: table for class "lower": 1692 bytes LC_CTYPE: table for class "alpha": 4256 bytes LC_CTYPE: table for class "digit": 600 bytes LC_CTYPE: table for class "xdigit": 600 bytes LC_CTYPE: table for class "space": 856 bytes LC_CTYPE: table for class "print": 5848 bytes LC_CTYPE: table for class "graph": 5848 bytes LC_CTYPE: table for class "blank": 856 bytes LC_CTYPE: table for class "cntrl": 664 bytes LC_CTYPE: table for class "punct": 4888 bytes LC_CTYPE: table for class "alnum": 4256 bytes LC_CTYPE: table for class "combining": 3024 bytes
Re: [0M2008.12] qtopia theme
Carlo Minucci wrote:
> Marco Trevisan (Treviño) ha scritto:
>
>> However theming qtopia is quite easy, I've re-themed all mine with tango
>> icons (and elementary-like buttons) :P
>
> how?
You've simply to add the icons you want to use in the
/opt/Qtopia/pics/themes/${theme} path. This is explained also in docs [1].
To give an idea here you are the list of the icons I've added (they can
be in various formats like svg, png, pic...):
/opt/Qtopia/pics/themes/tango/pics/datebook/icons/readonly.svg
/opt/Qtopia/pics/themes/tango/pics/datebook/icons/birthday.svg
/opt/Qtopia/pics/themes/tango/pics/datebook/icons/duedate.svg
/opt/Qtopia/pics/themes/tango/pics/datebook/icons/silent.svg
/opt/Qtopia/pics/themes/tango/pics/datebook/icons/noalarm.svg
/opt/Qtopia/pics/themes/tango/pics/datebook/icons/anniversary.svg
/opt/Qtopia/pics/themes/tango/pics/datebook/icons/audible.svg
/opt/Qtopia/pics/themes/tango/pics/datebook/DateBook.svg
/opt/Qtopia/pics/themes/tango/pics/icons/day.svg
/opt/Qtopia/pics/themes/tango/pics/icons/new-mail.svg
/opt/Qtopia/pics/themes/tango/pics/icons/account.svg
/opt/Qtopia/pics/themes/tango/pics/icons/find1.svg
/opt/Qtopia/pics/themes/tango/pics/icons/find2.svg
/opt/Qtopia/pics/themes/tango/pics/icons/find.svg
/opt/Qtopia/pics/themes/tango/pics/icons/home.svg
/opt/Qtopia/pics/themes/tango/pics/icons/txt.svg
/opt/Qtopia/pics/themes/tango/pics/icons/globe.svg
/opt/Qtopia/pics/themes/tango/pics/icons/Note.svg
/opt/Qtopia/pics/themes/tango/pics/icons/right.svg
/opt/Qtopia/pics/themes/tango/pics/icons/left.svg
/opt/Qtopia/pics/themes/tango/pics/icons/email.svg
/opt/Qtopia/pics/themes/tango/pics/icons/details.svg
/opt/Qtopia/pics/themes/tango/pics/icons/new.svg
/opt/Qtopia/pics/themes/tango/pics/icons/repeat.svg
/opt/Qtopia/pics/themes/tango/pics/icons/alarmbell.svg
/opt/Qtopia/pics/themes/tango/pics/phone/icons/hangup.svg
/opt/Qtopia/pics/themes/tango/pics/phone/icons/calls.svg
/opt/Qtopia/pics/themes/tango/pics/phone/icons/missedcall.svg
/opt/Qtopia/pics/themes/tango/pics/phone/icons/incomingcall.svg
/opt/Qtopia/pics/themes/tango/pics/phone/icons/outgoingcall.svg
/opt/Qtopia/pics/themes/tango/pics/textedit/TextEditor.svg
/opt/Qtopia/pics/themes/tango/pics/alert_warning.svg
/opt/Qtopia/pics/themes/tango/pics/callhistory/CallHistory.svg
/opt/Qtopia/pics/themes/tango/pics/profileedit/Note.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/AddressBook.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/AddressBook.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/online.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/offline.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/businessmessage.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/homephone.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/homefax.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/homemobile.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/homevoip.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/contactdetails.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/homemessage.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/business.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/notes.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/businessvoip.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/businesspager.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/businessfax.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/businessmobile.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/icons/businessphone.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/contactgroups.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/generic-contact.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/home.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/contactgroup.svg
/opt/Qtopia/pics/themes/tango/pics/addressbook/generic-personal-contact.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/outbox.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/trash.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/account.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/sendmail.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/getmail.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/sent.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/attach.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/sent-1.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/sent-2.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/outbox-1.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/trash-1.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/inbox.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/icons/drafts.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/flag_toget.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/flag_removed.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/flag_normal.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/flag_unread.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/flag_tosend.svg
/opt/Qtopia/pics/themes/tango/pics/qtmail/flag
Re: Tichy now hosted on google code + release 1.0.0
On Thu, Apr 9, 2009 at 12:00 AM, Leonti Bielski wrote: > So after using it for a while I can say that I'm impressed. > > When I first saw tichy on FSO distribution it was slow and I thought > nothing would come out of it. > Thanks for proving me wrong! > I like it's distribution independent approach - It has it's own > keyboard and graphical toolkit - must be a lot of work! > > The only thing is that while in fullscreen mode you can run nothing > except for tichy. I didn't find a way to switch between full screen > mode and normal one. > > Also, can you add easier case change for the keyboard? Ruight now if I > wan to write uppercase I have to go through all keyboard to get back > to small letters. > > But in overall I like it, and I see that it has made a lot of progress. Thanks ! you just encouraged me to work on the next release of tichy. Starting other applications from tichy is indeed a problem, but there is an experimental applet -contribution from Michael "Goodwill"- that allow to do that. I want to improve this for the next release. There is currently no way to switch between fullscreen and normal mode, I will try to implement this, shouldn't be a problem. The keyboard needs a lot of work too, it is still too slow (I have some idea why), and as you say, not very good for switching modes. btw : for some reason, tichy is faster on debian. I think this is because the ipkg I did didn't compile the C file with optimisation on. I will also try to solve this. All in all, that would roughly be my TODO list for next release : * Redo the Service system (it is too slow and complicated right now.) * Improve the user interface code (too slow as well, and a little bit messy.) * Add a GTK backend (that is working already, I just need to make it easy to configure) * If possible, improve the keyboard. * Being able to start external applications. * Start to work on tests suits, using py.test [0] module. As I said, I can't really predict how much time I will have to work on it, so I prefer not to give any date for the next release. Thanks again for your inputs ! cheers, Guillaume [0] http://codespeak.net/py/dist/test.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner buzz-fix party in Braunschweig
Hi, Am Mittwoch, 8. April 2009 schrieb arne anka: > i don't have a wiki account (and consideriung the number of unsued > accounts i was forced to create in the past simply to get an answer > somewhere i am not inclined, to create one). you just have to share your OpenMoko knowlegde and write/extend/correct/... some wiki pages (besides the BuzzFixParty one) - in this case the wiki account is not unused... On the other hand less people might read your BuzzFixParty statements then and therefore your mailing list approach is probably superior in this case anyway... Regards, Martin Bernreuther ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [0M2008.12] qtopia theme
Marco Trevisan (Treviño) ha scritto: > However theming qtopia is quite easy, I've re-themed all mine with tango > icons (and elementary-like buttons) :P how? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [0M2008.12] qtopia theme
Bernd (Jesus McCloud) Prünster wrote: > who made it [1] and where to get? > > [1] http://scap.linuxtogo.org/files/2abc691f82a2b2ea05789b960fb5f6c4.png I guess an Italian user nicknamed PaulTT (you can find him at [1])... However theming qtopia is quite easy, I've re-themed all mine with tango icons (and elementary-like buttons) :P [1] http://www.paultt.org/ -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [0M2008.12] qtopia theme
Bernd (Jesus McCloud) Prünster ha scritto: > who made it [1] and where to get? > > [1] http://scap.linuxtogo.org/files/2abc691f82a2b2ea05789b960fb5f6c4.png > > thx in advance i want it too :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 release plan
On Wed, 2009-04-08 at 13:48 -0400, Mark Shewmaker wrote: > Great to hear that. > > I'm sending this question privately only because I don't want it to > sound negative in any sense by sending it publicly, but..do you know if > there is a release goal for this release for opkg update and upgrades to > be able to complete without the infamous "Signature check failed" > errors? As it's not really negative and other people might have the same question, I'm bouncing it back to the list. > > (The claim in http://docs.openmoko.org/trac/ticket/1870 that this is > fixed notwithstanding, that's not the case now.) > If you try either the unstable or experimental images you will see that it is already fixed for Om2009. > Since the fundamental problem has to do with how the repository is set > up, and you are your coworkers are setting that up for this testing > image this week, I figure this is probably the best time to ask. > Asking questions anytime should provoke thought. Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[0M2008.12] qtopia theme
who made it [1] and where to get? [1] http://scap.linuxtogo.org/files/2abc691f82a2b2ea05789b960fb5f6c4.png thx in advance ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Watching videos on neo freerunner (openmoko 2008.12) mplayer-glamo
nope. I still see something like this in console r...@om-gta02:~# ./vidplay /media/card/film01-FR.avi > [AO OSS] audio_setup: Can't open audio device /dev/dsp: No such file or > directory > DVB card number must be between 1 and 4 > > > > Your system is too SLOW to play this! > > > Possible reasons, problems, workarounds: > - Most common: broken/buggy _audio_ driver > - Try -ao sdl or use the OSS emulation of ALSA. > - Experiment with different values for -autosync, 30 is a good start. > - Slow video output > - Try a different -vo driver (-vo help for a list) or try -framedrop! > - Slow CPU > - Don't try to play a big DVD/DivX on a slow CPU! Try some of the > lavdopts, > e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all. > - Broken file > - Try various combinations of -nobps -ni -forceidx -mc 0. > - Slow media (NFS/SMB mounts, DVD, VCD etc) > - Try -cache 8192. > - Are you using -cache to play a non-interleaved AVI file? > - Try -nocache. > Read DOCS/HTML/en/video.html for tuning/speedup tips. > If none of this helps you, read DOCS/HTML/en/bugreports.html. And some kind of noise on the FR screen. I think it can be caused by wrong file converting. Or maybe I should try OM2008.12 instead of SFO. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Frameworkd supports many modems? (Was : auimd-0.2, a user interface for mobile devices (and especially the FreeRunner !))
Daniel Willmann wrote: > > Actually with my Thinkpad X200s I am running frameworkd to control the > built in Ericsson WWAN modem. :-) > I was wondering how good is the framework at driving other modems out of GTA02 and 3 ones? Does it support USB 3G modems, for example? I would like to be able to turn my FR into multiple SIM enabled logger for openBmap :-) Thanks, Onen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] How to get elementary?
Hi, i' am interested, too. Perhaps anybody has a python-elementary-package as well? with kind regards Patrick Am Sonntag, den 05.04.2009, 12:45 +0200 schrieb Marcel: > Hello, > > Is there a elementary package for Debian yet? I've not yet gotten round > crosscompiling anything (thanks to python...) and fear adding a selfcompiled > elementary (in case I get that to work) to an E17 from the Debian repos, > running into conflicts when that actually contains elementary. > > -- > Marcel > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer wiki page erroneous axes ?
On Wed, Apr 08, 2009 at 06:10:03PM +0200, ri...@happyleptic.org wrote: > -[ Wed, Apr 08, 2009 at 04:26:02PM +0200, giacomo giotti mariani ] > > If you accelerate upwards your phone (with the screen pointing up) with > > an acceleration a you see a greater acceleration a_tot (along the z > > direction) that is the sum of gravity acceleration g and your imposed > > acceleration a (a_tot=a+g). > > Well, some confusion here. > > OK, let's imagine a _perfect_ accelerometer. > This device would report only acceleration. So, when the phone lies on the > table, it would report 0 (neglecting the rotation of earth here :-)). It does report zero (well, in the vicinity of zero), you just have to calculate it's difference towards the gravity vector (which is in the vicinity of zero). Rui -- Fnord. Today is Pungenday, the 25th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Upadated - Intone (0.22) Elementary based mplayer frontend
Hi, However if you want to test it with Om2008, use this [1] e17 version (following the instruciton I posted at [2]) to run it. Will try that and see what gives. Also, here is the latest version. Now, if you exit after pausing a playing file - intone will start with that song and position selected. intone_0.22_arm.ipk -- View this message in context: http://n2.nabble.com/Intone-%280.20---alpha-release%29-Elementary-based-mplayer-frontend-tp2587826p2606320.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
Re: Accelerometer wiki page erroneous axes ?
-[ Wed, Apr 08, 2009 at 04:26:02PM +0200, giacomo giotti mariani ] > If you accelerate upwards your phone (with the screen pointing up) with > an acceleration a you see a greater acceleration a_tot (along the z > direction) that is the sum of gravity acceleration g and your imposed > acceleration a (a_tot=a+g). Well, some confusion here. OK, let's imagine a _perfect_ accelerometer. This device would report only acceleration. So, when the phone lies on the table, it would report 0 (neglecting the rotation of earth here :-)). Then, to take your phone up to your ear, you first accelerate it upward, then downward (to stop the movement). If this perfect accelerometer were reporting accelerations along a Z axis pointing up, it would thus report first a positive value, then 0, then a negative value (the other way around if the other convention is used). Now, lets suppose that this perfect accelerometer is not calibrated correctly, and offset every values by 900. It will then report first a value >900, then 900, then a value <900. This is what you get with the actual accelerometer (*). So, Z is actually pointing Up. (*): our accelerometer is not perfect, but not because of a random offset. It is not perfect because it has no mean to distinguish between an actual acceleration from the effect of gravity. This is not a defect and there is no need to send the phone back to OpenMoko :-) because it is just how nature work (http://en.wikipedia.org/wiki/File:Elevator_gravity.svg) The effect of gravity (downwards) is the same as an acceleration (upwards!!) The freerunner is really a great thing. First it remembers me the good old days when I was hacking open all the guts of my 8bits computer ; then it remembers me the good old physic classes ! :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tichy now hosted on google code + release 1.0.0
So after using it for a while I can say that I'm impressed. When I first saw tichy on FSO distribution it was slow and I thought nothing would come out of it. Thanks for proving me wrong! I like it's distribution independent approach - It has it's own keyboard and graphical toolkit - must be a lot of work! The only thing is that while in fullscreen mode you can run nothing except for tichy. I didn't find a way to switch between full screen mode and normal one. Also, can you add easier case change for the keyboard? Ruight now if I wan to write uppercase I have to go through all keyboard to get back to small letters. But in overall I like it, and I see that it has made a lot of progress. Leonti On Tue, Apr 7, 2009 at 2:47 PM, Leonti Bielski wrote: > Thanks, it's working now! > > Leonti > > On Tue, Apr 7, 2009 at 2:32 PM, arne anka wrote: >> seems pretty clear to me: >> >> pygame.error: Failed loading libpng.so.3: libpng.so.3: cannot open shared >> object file: No such file or directory >> >> look for a package providing libpng.so.3 and install it. >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Autorun for SD card mechanism?
Ok, as the idea was good, more thoughts: 1.) Using the sd card to store jet installed application information is not good. Then it would only run the first distro switch. 2.) Keep in mind, that packages from the usual opkg may be installed in later releases. And it may or may not reinstalled. 3.) Using a database repository in the net to update a local database of applications that may installable without problems per distro. 4.) If a user add's an application with opkg, a choice could be made to activate autoinstall for later switches. 5.) If the application isn't in the database on the net, or the local copy, add it but mark it as untested. 6.) The database could be used for a hitlist of installed applications that would really used, because a reinstall could be counted. 7.) Untested applications that should be installed, could be complained about and a choice could be made. 8.) Feedback if successfully installed application makes problems. The user should be asked some time later and he/she may make choices as of like this: 'App1 is usable', 'App2 has problems on this distro' and so forth. That way, we get feedback of the most used applications, we see the quality in the installability and we may spot conflicts. Next, if a distro decides to add an application as default, it could be marked as installed by that distro. This leads propably to an update process per distro and thus a local copy (if there will be really some for offline installations) could either removed any time - by asking or the app on the card could also get updated. Keep in mind that there are issues with the applications data. If this data is not at least backed up to sd card, a distro switch may kill your data :-) Also keep in mind, that users don't want to give that feedback. We don't do it like some companies do collect their statistical :-) It is not easy and I don't like to only create a quick hack, that would not work at all. Lothar Am 08.04.2009 um 16:28 schrieb Pander: > in the first boot, also make the most default choices of all when > /media/card/post directory is found. e.g. English, Illume SHR theme, > ..., next, next, next, finish ;) > > Johny Tenfinger wrote: >> Hmm... Maybe there is a place for some app... "shr-firstboot" :) It >> could also replace first boot creator from e17, which isn't very >> useful on Neos... >> >> 2009/4/8, Pander : >>> good idea. I already have all those files on SD but after each >>> upgrade >>> have to install them manually, which is annoying. >>> >>> I would suggest something like: >>> >>> 1) notify user to do an opkg update and opkg upgrade first >>> >>> 2) change to post installation directory >>> cd /media/card/post >>> >>> 3) change to package directory and install all that is in there >>> cd packages >>> opkg install *.ipk *.opk >>> cd .. >>> >>> 4) override files >>> cd override >>> [[copy all files to root of system, e.g. override/etc/blabla to >>> /etc/blabla]] >>> cd .. >>> >>> 5) path files >>> cd patches >>> [[apply all patchers to root of system]] >>> cd .. >>> >>> off course documenting your changes via patches/diffs is preferred >>> over >>> overriding, allowing improvements in other parts of the files via >>> opkg >>> upgrade before you start. >>> >>> Johny Tenfinger wrote: Shortly: Let's write it ;) 2009/4/8, Lothar Behrens : > There is an idea rattling in my head about the following issue: > > Given I have a micro SD card and that would have all here, what is > about a bootstrap mechanism to > post install packages that are laying on that card to be > installed, > when a new image is started at first time? > > Like the autorun of a CD, this would help to ease the distro > switch > but keep my usual applications that otherwise > have to be installed manually. > > This would include SSH settings, WLAN settings, look and feel, and > what ever may possible. > > What about it? > > -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de > Lothar Behrens > Heinrich-Scheufelen-Platz 2 > 73252 Lenningen > > > > > > > > > > ___ > 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/listin
Re: graphical nethack for freerunner (alpha version released)
>>> http://cc.oulu.fi/~rantalai/freerunner/nethack/ >>> Warnign: Not yet playable! >>> http://img183.imageshack.us/img183/5662/mynethack.png >>> http://img118.imageshack.us/img118/5608/mynethackwithmenu.png >> Thanks for images. This will be my first target when I have time to >> implement it. (If somebody want code this ready, please just do it) >> A) If there are full keyboard in visible, do we need menus at all? Menus are usefull for inventory, help file and so on. >> B) How this menu is accessible? Via the keyboard, for example: h->help i->inventory ... #->extended commands like pray or engrave >> C) In this tilesize, there are ~15x20 grid in visible. (this is not >> question, just mentioned it) It an approximate dimension, but we can use the zoom buttons on the left-down corner to change it (and text with in the dialog box) >> D) How about pop-up windows (inventory etc.)? Just fullscreen list? They must fit the right way...full screen may be a good solution. >> E) I planned if that keyboard can be changed to corresponding >> command-icons, but there are couple times, when player needs full >> keyboard (naming objects, calling monsters, playing instruments, when >> asked name/wishes/genociding). ?So is there reason to have icons when >> playing and keyboard when needed? (It might be technically handled >> someway) >> It can be usefully and we can use the standard keyboard to type long words as stated by Yorick: > why do you need that full kb? wouldn't menu's be more finger friendly > and faster? use the kb space for "most used actions" or something similar I thought to put that keybord on screen because we need at list directional keys and some other one so the occupatet space looked me the same, but I've not tryed it. -- /_\ The ASCII Per comunicare in modo riservato: \_/ Ribbon Campaign gpg --keyserver pool.sks-keyservers.net \ X Against HTML--recv-keys 20611EAD /_\ Email! -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Packaging extra fonts
Olof Sjobergh wrote: > On Mon, Apr 6, 2009 at 10:56 AM, Pander wrote: >> Hi all, >> >> I need some extra fonts to display kanji. I have manged to copy some >> .ttf files manually and that works. Now, I would like to package these >> fonts in an .opkg file. do I need to call some executables to properly >> register the ttf files or is putting the files in the correct directory >> suffiecient? > > Hi, > > If you want Japanese fonts, the following two fonts are already > available and packaged for SHR: > > ttf-sazanami-mincho > ttf-sazanami-gothic > > You can just install them with opkg. Thanks I've added ttf-arabeyes: http://www.opkg.org/package_197.html which also supports Japanese glyphs. I think an automated repackaging by SHR can be done for most of the Ubuntu font packages. > > Best regards, > > Olof Sjöbergh > > ___ > 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: Autorun for SD card mechanism?
in the first boot, also make the most default choices of all when /media/card/post directory is found. e.g. English, Illume SHR theme, ..., next, next, next, finish ;) Johny Tenfinger wrote: > Hmm... Maybe there is a place for some app... "shr-firstboot" :) It > could also replace first boot creator from e17, which isn't very > useful on Neos... > > 2009/4/8, Pander : >> good idea. I already have all those files on SD but after each upgrade >> have to install them manually, which is annoying. >> >> I would suggest something like: >> >> 1) notify user to do an opkg update and opkg upgrade first >> >> 2) change to post installation directory >> cd /media/card/post >> >> 3) change to package directory and install all that is in there >> cd packages >> opkg install *.ipk *.opk >> cd .. >> >> 4) override files >> cd override >> [[copy all files to root of system, e.g. override/etc/blabla to >> /etc/blabla]] >> cd .. >> >> 5) path files >> cd patches >> [[apply all patchers to root of system]] >> cd .. >> >> off course documenting your changes via patches/diffs is preferred over >> overriding, allowing improvements in other parts of the files via opkg >> upgrade before you start. >> >> Johny Tenfinger wrote: >>> Shortly: Let's write it ;) >>> >>> 2009/4/8, Lothar Behrens : There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer wiki page erroneous axes ?
>> > I beg to disagree. If you are talking about acceleration of the sensor >> > itself then you'll see that: 1. it's not actually accelerating if you >> > attach a reference frame to the Earth (the freerunner is laying >> > still). 2. The gravitational force applied to the sensor is directed >> > to the center of the Earth, >> > > OK untill here. > > OK >> > so the reported "acceleration" should be positive too. >> > > The reported acceleration is positive, this is a fact (cat /dev/input/event3). > The question is : is a positive acceleration accelerating downward or upward ? > > The wiki tells that a positive acceleration is downward (Z axe pointing down). > This is not true, in my opinion. > > When standing still, the accelerometer must report an acceleration directed > in the > _oposite_ direction the the gravitational force. As it is reporting a positive > acceleration, then the Z axe goes up. > > And I believe the other axes are inverted as well (which, as suggested by > Michael, > is easily provable by turning the FR around so that each axes points down). > > What is drawn in the wiki is a reference system; in that reference system the gravity acceleration take the right sign, being in the same direction as the z axis. If you accelerate upwards your phone (with the screen pointing up) with an acceleration a you see a greater acceleration a_tot (along the z direction) that is the sum of gravity acceleration g and your imposed acceleration a (a_tot=a+g). That means that the force acting on the phone is equal to the mass of the mobile m time the total acceleration and you can verify it with a dynamometer. Giacomo -- /_\ The ASCII Per comunicare in modo riservato: \_/ Ribbon Campaign gpg --keyserver pool.sks-keyservers.net \ X Against HTML--recv-keys 20611EAD /_\ Email! -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Autorun for SD card mechanism?
Hmm... Maybe there is a place for some app... "shr-firstboot" :) It could also replace first boot creator from e17, which isn't very useful on Neos... 2009/4/8, Pander : > good idea. I already have all those files on SD but after each upgrade > have to install them manually, which is annoying. > > I would suggest something like: > > 1) notify user to do an opkg update and opkg upgrade first > > 2) change to post installation directory > cd /media/card/post > > 3) change to package directory and install all that is in there > cd packages > opkg install *.ipk *.opk > cd .. > > 4) override files > cd override > [[copy all files to root of system, e.g. override/etc/blabla to > /etc/blabla]] > cd .. > > 5) path files > cd patches > [[apply all patchers to root of system]] > cd .. > > off course documenting your changes via patches/diffs is preferred over > overriding, allowing improvements in other parts of the files via opkg > upgrade before you start. > > Johny Tenfinger wrote: >> Shortly: Let's write it ;) >> >> 2009/4/8, Lothar Behrens : >>> There is an idea rattling in my head about the following issue: >>> >>> Given I have a micro SD card and that would have all here, what is >>> about a bootstrap mechanism to >>> post install packages that are laying on that card to be installed, >>> when a new image is started at first time? >>> >>> Like the autorun of a CD, this would help to ease the distro switch >>> but keep my usual applications that otherwise >>> have to be installed manually. >>> >>> This would include SSH settings, WLAN settings, look and feel, and >>> what ever may possible. >>> >>> What about it? >>> >>> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de >>> Lothar Behrens >>> Heinrich-Scheufelen-Platz 2 >>> 73252 Lenningen >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ___ >>> 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: Autorun for SD card mechanism?
good idea. I already have all those files on SD but after each upgrade have to install them manually, which is annoying. I would suggest something like: 1) notify user to do an opkg update and opkg upgrade first 2) change to post installation directory cd /media/card/post 3) change to package directory and install all that is in there cd packages opkg install *.ipk *.opk cd .. 4) override files cd override [[copy all files to root of system, e.g. override/etc/blabla to /etc/blabla]] cd .. 5) path files cd patches [[apply all patchers to root of system]] cd .. off course documenting your changes via patches/diffs is preferred over overriding, allowing improvements in other parts of the files via opkg upgrade before you start. Johny Tenfinger wrote: > Shortly: Let's write it ;) > > 2009/4/8, Lothar Behrens : >> There is an idea rattling in my head about the following issue: >> >> Given I have a micro SD card and that would have all here, what is >> about a bootstrap mechanism to >> post install packages that are laying on that card to be installed, >> when a new image is started at first time? >> >> Like the autorun of a CD, this would help to ease the distro switch >> but keep my usual applications that otherwise >> have to be installed manually. >> >> This would include SSH settings, WLAN settings, look and feel, and >> what ever may possible. >> >> What about it? >> >> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de >> Lothar Behrens >> Heinrich-Scheufelen-Platz 2 >> 73252 Lenningen >> >> >> >> >> >> >> >> >> >> ___ >> 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: Om2009 release plan
On Tue, 2009-04-07 at 22:53 +0200, Ed Kapitein wrote: > Hi, > > With the remainder of march being behind us, can you give an update on > the release plan? > > Kind regards, > Ed > Hi Ed, We are going to put a testing image together for the end of this week. Because of OM reduced staffing levels some other dates mentioned in the Release Plan will probably slide a bit. Most of the features mentioned in the release plan have been implemented. A few still need some work and hopefully we can get those finished in short order. Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Autorun for SD card mechanism?
Shortly: Let's write it ;) 2009/4/8, Lothar Behrens : > There is an idea rattling in my head about the following issue: > > Given I have a micro SD card and that would have all here, what is > about a bootstrap mechanism to > post install packages that are laying on that card to be installed, > when a new image is started at first time? > > Like the autorun of a CD, this would help to ease the distro switch > but keep my usual applications that otherwise > have to be installed manually. > > This would include SSH settings, WLAN settings, look and feel, and > what ever may possible. > > What about it? > > -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de > Lothar Behrens > Heinrich-Scheufelen-Platz 2 > 73252 Lenningen > > > > > > > > > > ___ > 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
Autorun for SD card mechanism?
There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Watching videos on neo freerunner (openmoko 2008.12) mplayer-glamo (Was Re: Jabra BT3030 experience anywhere ?)
Here it is, what I have published that time: Searching for 'Jabra' on the wiki gave no result and searching for 'Bluetooth' gave no headline regarding to Jabra, but I know, there is a A2DP page (http://wiki.openmoko.org/wiki/A2DP). The Jabra 3030 BT isn't reported there to work. So before I do, has it been put by someone at the wiki or anywhere? Lothar Am 19.01.2009 um 14:34 schrieb Lothar Behrens: > Hi, > > now I have got the Jabra BT3030 working. Excelent sound, no crushing > noices as experienced with my Mac OS X :-) > > I also have successfully tested connection with a second phone to > test incoming calls. I'll hear a ring and I could accept > and speak. > > Once the mplayer didn't come back with sound. I'll figure out the > cause if I have time. Restarting helped to solve. > > The installation steps, Steven has explained, are correct, but on > the 2008.12 are some packages not installed. > > I am using mplayer. And there is a working description as of post > from Glen at 29. Dezember 2008 04:27:48 MEZ. > There was only an issue with the libgcc library that was too old, > thus sdl couldn't be installed, what mplayer caused to > be not startable. (At least today) > > After installing the following package, sdl was installable and > mplayer would work. > > http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libgcc1_4.2.4-r5.1_armv4t.ipk > > Also missing is the bluez-utils-alsa package. Mplayer couldn't find > > These are my packets: > > r...@om-gta02:~# opkg list_installed | grep blue > bluez-audio - 3.33-r3 - > bluez-hcidump - 1.42-r0 - > bluez-utils - 3.33-r3 - > bluez-utils-alsa - 3.33-r3 - > bluez-utils-compat - 3.33-r3 - > kernel-module-bluetooth - > 3:2.6.24+gitr76014+fb42ce6724576fc173faf8abfb04aa2c36d213b7-r2.01 - > libbluetooth2 - 3.33-r0 - > > The other packages are as reported from Glen. > > Here is my script to use the headset. (The bluetooth device must be > activated, or added as a line): > > #!/bin/sh > > export DEVICE=XX:XX:XX:XX:XX:XX > > /etc/init.d/bluetooth stop > /etc/init.d/bluetooth start > > sleep 1 > passkey-agent --default & > > sleep 1 > echo Create bonding > dbus-send --system --type=method_call --print-reply -- > dest=org.bluez /org/bluez/hci0 org.bluez.Adapter.CreateBonding > string:$DEVICE > > sleep 1 > echo Activating service audio > dbus-send --system --print-reply --dest=org.bluez /org/bluez > org.bluez.Manager.ActivateService string:audio > > sleep 1 > echo Creating device > dbus-send --system --type=method_call --print-reply -- > dest=org.bluez /org/bluez/audio org.bluez.audio.Manager.CreateDevice > string:$DEVICE > > sleep 1 > echo Connecting sink > dbus-send --system --type=method_call --print-reply --dest=org.bluez > "/org/bluez/audio/device0" org.bluez.audio.Sink.Connect > > > To use the bluetooth audio device, the player has to started with > the correct parameters. > > Have fun - I have :-) > > Lothar > > -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de > Lothar Behrens > Heinrich-Scheufelen-Platz 2 > 73252 Lenningen > > > > > > > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer wiki page erroneous axes ?
-[ Wed, Apr 08, 2009 at 04:32:41PM +0400, Paul Fertser ] > I beg to disagree. If you are talking about acceleration of the sensor > itself then you'll see that: 1. it's not actually accelerating if you > attach a reference frame to the Earth (the freerunner is laying > still). 2. The gravitational force applied to the sensor is directed > to the center of the Earth, OK untill here. > so the reported "acceleration" should be positive too. The reported acceleration is positive, this is a fact (cat /dev/input/event3). The question is : is a positive acceleration accelerating downward or upward ? The wiki tells that a positive acceleration is downward (Z axe pointing down). This is not true, in my opinion. When standing still, the accelerometer must report an acceleration directed in the _oposite_ direction the the gravitational force. As it is reporting a positive acceleration, then the Z axe goes up. And I believe the other axes are inverted as well (which, as suggested by Michael, is easily provable by turning the FR around so that each axes points down). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer wiki page erroneous axes ?
Paul Fertser writes: ?> Michael Tansella writes: >>> So, the fact that when idle the accelerometers report a positive Z value >>> implies that the Z axe is actually upward. >>> >>> Agree ? >> >> Yes I think that's right. If you hold the Freerunner that any arrow of an >> axis >> points to the earth middlepoint then the sown value must be >> negative. > > I beg to disagree. If you are talking about acceleration of the sensor > itself then you'll see that: 1. it's not actually accelerating if you > attach a reference frame to the Earth (the freerunner is laying > still). 2. The gravitational force applied to the sensor is directed > to the center of the Earth, so the reported "acceleration" should be > positive too. Thinking about it a bit more, i now understand that if you insist on talking about accelerations, the Z axis should point upwards. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Watching videos on neo freerunner (openmoko 2008.12) mplayer-glamo
Not yet. I have grabbed the information from what was available. So maybe I seek the places and think about these descriptions to concentrate it or simply link them as the steps to do. Thus I have to backup my settings, grab those needed for the functionality and replay the setup procedure to approve it before writing from my stuff in brain. I vagually remember a mail I have sent about the Jabra BT issue here. I must search for it :-) Lothar Am 08.04.2009 um 14:10 schrieb Risto H. Kurppa: > On Wed, Apr 8, 2009 at 2:40 PM, Lothar Behrens > wrote: >> Hey and when you use vdr (http://de.wikipedia.org/wiki/Video_Disk_Recorder >> ) and a plugin to transcode it for small screens, you could watch tv >> live! >> >> I have tried that and it works very well. Now I have made a small >> video, recording the Neo and in paralell my Mac with sound. >> Indeed my sound on the neo is routed to my Jabra 3030 BT device, so >> it >> is a nice TV for looking in bed, before giong to sleep. > > Have you documented the setup somewhere (openmoko wiki?) , I'd like to > see how do you do it.. > > r > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer wiki page erroneous axes ?
Michael Tansella writes: >> So, the fact that when idle the accelerometers report a positive Z value >> implies that the Z axe is actually upward. >> >> Agree ? > > Yes I think that's right. If you hold the Freerunner that any arrow of an > axis > points to the earth middlepoint then the sown value must be > negative. I beg to disagree. If you are talking about acceleration of the sensor itself then you'll see that: 1. it's not actually accelerating if you attach a reference frame to the Earth (the freerunner is laying still). 2. The gravitational force applied to the sensor is directed to the center of the Earth, so the reported "acceleration" should be positive too. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Upadated - Intone (0.21 - alpha release) Elementary based mplayer frontend
c_c wrote: > @ Treviño - Well, I don't have OM 2008 to test this on - but that is strange. > Can you confirm the newer version also does this? I guess I'll have to > download OM2008 now! Yes... New version does it too (I've not the needed oss module [I've it built-in in my kernel], and I get an error, but this shouldn't be the cause, isn't it?!). However if you want to test it with Om2008, use this [1] e17 version (following the instruciton I posted at [2]) to run it. [1] http://downloads.tuxfamily.org/3v1deb/openmoko/e17-illume-elementary%2bsvn20090402.tar.bz2 [2] http://n2.nabble.com/On-the-Enlightenment-Bleeding-Edge-tp2131838p2131838.html -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Watching videos on neo freerunner (openmoko 2008.12) mplayer-glamo
On Wed, Apr 8, 2009 at 2:40 PM, Lothar Behrens wrote: > Hey and when you use vdr (http://de.wikipedia.org/wiki/Video_Disk_Recorder > ) and a plugin to transcode it for small screens, you could watch tv > live! > > I have tried that and it works very well. Now I have made a small > video, recording the Neo and in paralell my Mac with sound. > Indeed my sound on the neo is routed to my Jabra 3030 BT device, so it > is a nice TV for looking in bed, before giong to sleep. Have you documented the setup somewhere (openmoko wiki?) , I'd like to see how do you do it.. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Recommended GTA01 images?
which shr-unstable image are you referring to? ( http://build.shr-project.org/shr-unstable/images/om-gta01/ ) I tried shr-image-om-gta01.jffs2 with the 2.4.24 kernel there but it had no GSM. Ben. Johny Tenfinger wrote: > You can use GPRS without scripts ;) Use shr-unstable (which is stable > enough again ;D) and use SHR Settings to connect ;) > > 2009/4/5, Ben Wilson : > >> try shr-lite-image-om-gta01.jffs2 from >> http://shr.bearstech.com/shr-testing/images/om-gta01/ >> >> Seems to work great on my gta01, dialling / suspend / sms etc.. >> By default it won't suspend automatically after x seconds, but this >> might be easy to change. >> I just suspend it myself before putting it in my pocket every time >> (click X at homescreen for shutdown/suspend options). >> It has always woken up from suspend when calls or txt arrive. so yeah, >> seems perfectly stable to me for everyday use. >> >> There's some shr tweaks here >> (some may already have been done to the image, ie, i didn't have to do >> fast suspend and no echo) >> http://shr-project.org/trac/wiki/Tweaks >> >> The GPRS scripts here also work for me >> http://wiki.openmoko.org/wiki/GPRS_FSO >> It doesn't have a browser in the image however you can opkg install one >> >> Ben >> >> Mikko Rauhala wrote: >> >>> Hi >>> >>> It seems that my FRs are suffering from additional HW woes to the usual >>> ones, and I just contacted my vendor with warranty questions. >>> >>> Meanwhile, what's hot nowadays for a GTA01 if one wants the phone >>> functions to somewhat work, and yeah, suspend too preferrably? >>> >>> >>> >> ___ >> 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: Watching videos on neo freerunner (openmoko 2008.12) mplayer-glamo
This is really good news! I have measured about 70% to 80% with mplayer. Hey and when you use vdr (http://de.wikipedia.org/wiki/Video_Disk_Recorder ) and a plugin to transcode it for small screens, you could watch tv live! I have tried that and it works very well. Now I have made a small video, recording the Neo and in paralell my Mac with sound. Indeed my sound on the neo is routed to my Jabra 3030 BT device, so it is a nice TV for looking in bed, before giong to sleep. What about the law to publish the video? How small should it be - 1 minute? It's german news from today at about 13:15 from ZDF. We could do such stuff - right and legal to demonstrate the features and try to bring such presentations to the press. As I read an article, most companies would be likely show only the positive things in their advertisement and wrap the not so good features with long technical specifications. This is a marketing trick. Here, the heise publisher reports about the tricks: http://www.heise.de/ct/Spar-Schweinereien--/artikel/135132 I don't know, if this article is also published in english. So keep on going to produce 'good' press materal and find sponsors to publish them! Or even simply keep staying legal with the content. What do you think? The video that is recorded is about 1GB. I can try to work on it, but I need some ideas about the length the TV recordings must be at maximum. Lothar Am 08.04.2009 um 11:50 schrieb Leonti Bielski: > Denis, thanks a lot! > I've put your config file on wiki. > > Now I can play video from memory card using only 15% of CPU! > > Leonti > > On Tue, Apr 7, 2009 at 11:50 PM, Denis Shulyaka > wrote: >> 2009/4/8 Ivan Shirokov : >>> Does it work for FSO? Somehow it hangs up my FR. And there's >>> something like >>> "Your system is too slow" in the console =( >> >> Actually, the mplayer build that is suggested in the wiki uses mp3lib >> for decoding mp3 audio tracks by default. I suggest you adding >> afm=ffmpeg line to ~/.mplayer/config file to force using ffmpeg's >> internal mp3 decoder, or use a build without mp3lib support. It >> appears to be more than 3 times faster on my FR! >> Here is my ~/.mplayer/config file: >> >> vo=xover:glamo,x11 >> display=:0 >> afm=ffmpeg >> fs=1 >> quiet=1 >> osdlevel=0 >> noautosub=1 >> stop-xscreensaver=1 >> >> Hope it helps. >> >> ___ >> 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 > -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Leather case for Neo freeruner now 29 Euros - sample unit shown at "Munich Stammtisch"
On Wed, Apr 8, 2009 at 1:13 PM, Dr. H. Nikolaus Schaller wrote: > > Am 08.04.2009 um 12:52 schrieb Matthias Apitz: >>> FYI, there is a "Stammtisch" soon where you can share the fun you >>> have: >>> >>> http://freeyourphone.de/portal_v1/viewtopic.php?f=13&t=1107&sid=9dc4cd9320b3fca17f4519f1ed022dd4 >> >> I have put my availability into http://www.doodle.com/ezrymw66khm4xvzb > > Great (it is difficult to judge who is behind the user ids). > > So, everyone else who is living in or near Munich, Germany is invited > to join! > >> and by the way: I've shared already my fun with the FR in Havana in >> the >> Local Linux User Group: >> http://www.unixarea.de/OpenMokoLiaHab/ > > Looks like a really good presentation (I have no specific training in > Spanish - just some French&Latin...). I recommend you that send this link to the Openmoko-spanish ml, some people there could be interested :) > > Nikolaus > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- ___ Rafael Campos o0 Methril 0o http://openblog.methril.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Leather case for Neo freeruner now 29 Euros - sample unit shown at "Munich Stammtisch"
Am 08.04.2009 um 12:52 schrieb Matthias Apitz: >> FYI, there is a "Stammtisch" soon where you can share the fun you >> have: >> >> http://freeyourphone.de/portal_v1/viewtopic.php?f=13&t=1107&sid=9dc4cd9320b3fca17f4519f1ed022dd4 > > I have put my availability into http://www.doodle.com/ezrymw66khm4xvzb Great (it is difficult to judge who is behind the user ids). So, everyone else who is living in or near Munich, Germany is invited to join! > and by the way: I've shared already my fun with the FR in Havana in > the > Local Linux User Group: > http://www.unixarea.de/OpenMokoLiaHab/ Looks like a really good presentation (I have no specific training in Spanish - just some French&Latin...). Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ePDFView package on opkg.org
On Wed, Apr 8, 2009 at 1:35 PM, roby wrote: > On Wed, Apr 8, 2009 at 12:08 PM, Risto H. Kurppa wrote: >> Can't test right now but does the full screen mode already have a way >> to come away from there? At some point I tried it and it required one >> to press ESC to end the fullscreen mode.. Keyboard toggle button >> behind the presentation - you had to turn off the phone or SSH & kill >> to be able to close it... > > I know, that's a problem.. i was thinking to something as a double > click to leave fullscreen mode. Someone - somewhere - wrote a script that one can use to run a program. The script changes the behavious of AUX button, in this case it's used as ESC (or F11 or something, can't remember) and would allow you to change between normal/full screen mode. Can't remember where was it, someone else maybe? But the idea was to map the in put of AUX to F11/ESC as long as the app runs. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Leather case for Neo freeruner now 29 Euros
El día Wednesday, April 08, 2009 a las 12:23:22PM +0200, Dr. H. Nikolaus Schaller escribió: > >>HI > >>well topic says all > >>Now the Openmoko leather case is at 29 Euros Vat included + > >>Shipping costs > >>at www.truxbrain.com/shop > > BTW: if you haven't one yet, I have a sample that you can look at (see > below) I have one which my wife bought in Bogotá exactly for the size of the FR; mine one has a loop to be attached to the belt; works fine; > FYI, there is a "Stammtisch" soon where you can share the fun you have: > > http://freeyourphone.de/portal_v1/viewtopic.php?f=13&t=1107&sid=9dc4cd9320b3fca17f4519f1ed022dd4 I have put my availability into http://www.doodle.com/ezrymw66khm4xvzb and by the way: I've shared already my fun with the FR in Havana in the Local Linux User Group: http://www.unixarea.de/OpenMokoLiaHab/ matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ePDFView package on opkg.org
On Wed, Apr 8, 2009 at 11:05 AM, Denis Shulyaka wrote: > And some kind of zoom in full screen would be nice! How could i code it? maybe some spiral like qwo? Umm maybe it's a bit too much for me now :) I will go to the close full screen issue first, cause it seems more critical.. roby ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ePDFView package on opkg.org
On Wed, Apr 8, 2009 at 12:08 PM, Risto H. Kurppa wrote: > Can't test right now but does the full screen mode already have a way > to come away from there? At some point I tried it and it required one > to press ESC to end the fullscreen mode.. Keyboard toggle button > behind the presentation - you had to turn off the phone or SSH & kill > to be able to close it... I know, that's a problem.. i was thinking to something as a double click to leave fullscreen mode. roby ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Leather case for Neo freeruner now 29 Euros
Am 07.04.2009 um 13:29 schrieb Matthias Apitz: > El día Tuesday, April 07, 2009 a las 01:15:52PM +0200, David Reyes > Samblas Martinez escribió: > >> HI >> well topic says all >> Now the Openmoko leather case is at 29 Euros Vat included + >> Shipping costs >> at www.truxbrain.com/shop BTW: if you haven't one yet, I have a sample that you can look at (see below) >> Yes, the topic says at all: NOW for 29 Euros (and maybe tomorrow for > 1 Euro); it sounds that folks are leaving a sinking ship :-( > I have encountered in the FR the toy I was always looking for: a UNIX > server with X11 for my pocket or belt which also can make phone calls, > Internet, Wifi, GPS, ... FYI, there is a "Stammtisch" soon where you can share the fun you have: http://freeyourphone.de/portal_v1/viewtopic.php?f=13&t=1107&sid=9dc4cd9320b3fca17f4519f1ed022dd4 > I'm one of those using it as their only and daily phone device... but, > where to go now in the future? well, the device will continue > serving some time, > maybe even years as it is, but after that? We can discuss that as well... Nikolaus > > > Thx > > matthias > -- > Matthias Apitz > Manager Technical Support - OCLC GmbH > Gruenwalder Weg 28g - 82041 Oberhaching - Germany > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.oclc.org/ http://www.UnixArea.de/ > People who hate Microsoft Windows use Linux but people who love UNIX > use FreeBSD. > > ___ > 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: ePDFView package on opkg.org
On Wed, Apr 8, 2009 at 12:05 PM, Denis Shulyaka wrote: > And some kind of zoom in full screen would be nice! Can't test right now but does the full screen mode already have a way to come away from there? At some point I tried it and it required one to press ESC to end the fullscreen mode.. Keyboard toggle button behind the presentation - you had to turn off the phone or SSH & kill to be able to close it... r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The future of the Neo Freerunner
2009/4/8 Juergen Schinker > Nicola Mfb wrote: > my vodafone card was not > > recognized before the latest gsm firmware updates, and many others that > > did not let me use the freerunner as a daily phone. > > oh interresting how can you update the gsm firmware? > > is this a special process or just a package? > you may read this: http://wiki.openmoko.org/wiki/GSM/Flashing Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Watching videos on neo freerunner (openmoko 2008.12) mplayer-glamo
Denis, thanks a lot! I've put your config file on wiki. Now I can play video from memory card using only 15% of CPU! Leonti On Tue, Apr 7, 2009 at 11:50 PM, Denis Shulyaka wrote: > 2009/4/8 Ivan Shirokov : >> Does it work for FSO? Somehow it hangs up my FR. And there's something like >> "Your system is too slow" in the console =( > > Actually, the mplayer build that is suggested in the wiki uses mp3lib > for decoding mp3 audio tracks by default. I suggest you adding > afm=ffmpeg line to ~/.mplayer/config file to force using ffmpeg's > internal mp3 decoder, or use a build without mp3lib support. It > appears to be more than 3 times faster on my FR! > Here is my ~/.mplayer/config file: > > vo=xover:glamo,x11 > display=:0 > afm=ffmpeg > fs=1 > quiet=1 > osdlevel=0 > noautosub=1 > stop-xscreensaver=1 > > Hope it helps. > > ___ > 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: The future of the Neo Freerunner
Nicola Mfb wrote: my vodafone card was not > recognized before the latest gsm firmware updates, and many others that > did not let me use the freerunner as a daily phone. oh interresting how can you update the gsm firmware? is this a special process or just a package? Thanks Juergen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner buzz-fix party in Braunschweig
> there is now a date set for the buzz-fix party in Braunschweig > (May 1st - May 3rd). Please put your names on the wikipage > http://wiki.openmoko.org/wiki/BuzzFixParty#Braunschweig if you are > planning to attend. Any other infos, location, etc. will be updated > there. i don't have a wiki account (and consideriung the number of unsued accounts i was forced to create in the past simply to get an answer somewhere i am not inclined, to create one). but i want to come -- if braunschweig is not flooded by the working masses, demonstrating, drinking and fighting for their rights, i'd prefer the 1th. if the participation is too uneven, i'm ok even with the 2nd or 3d. so far i bring one freerunner, but i offered a while ago to take some with me and there was one response. so if someone in the hamburg area wnats to get his/her freerunner fixed but can't come, drop a mail. be sure, though, tzo back up your device and mark all parts (battery, back, main part). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelerometer wiki page erroneous axes ?
> So, the fact that when idle the accelerometers report a positive Z value > implies that the Z axe is actually upward. > > Agree ? Yes I think that's right. If you hold the Freerunner that any arrow of an axis points to the earth middlepoint then the sown value must be negative. Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ePDFView package on opkg.org
And some kind of zoom in full screen would be nice! 2009/4/8, David Garabana Barro : > On Tuesday 07 April 2009 17:38:13 Previdi Roberto wrote: > >> To scroll the pages you can just scroll "out of" the actual page. I'm >> sorry for my english :) >> Let me know of any questions. > > It is a huge improvement! > The only problem I see is that if you rotate view to read lanscape it > doesn't > scroll if you reach the end of page. > > Would it be possible to add some "gesture" or similar to leave full screen? > Now you can only leave it closing application. > > Thank you very much! > > ___ > 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
Accelerometer wiki page erroneous axes ?
Please have a look at the "accelerometer data retrieval" wiki page at http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval . It is said that "the Z axis is pointing from the display downwards to to the back of the openmoko". In my opinion this is false and all other axes my be inverted as well. The confusion seams to originates from the Z value you read from the accelerometer which is positive when the phone lies horizontally. But the fact that the gravitation vector G points downward means that the acceleration measured by the sensor is actually upward : gravitationnal force is equivalent to an acceleration in the other direction (remember the elevator analogy : beeing pulled down toward the ground by gravity is equivalent to standing in an elevator that continuously accelerate _upward_ in the absence of gravity). So, the fact that when idle the accelerometers report a positive Z value implies that the Z axe is actually upward. Agree ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The future of the Neo Freerunner
2009/4/8 Daniel Willmann > On Sat, 4 Apr 2009 12:57:30 +0200 > Nicola Mfb wrote: > [...] > > And what's about Openmoko new software stack roadmap? > > If it will not fund FSO, those developers may decide to stay a bit > > relaxed. > > Let me assure you I'm not even close to anything resembling relaxed. :-) I'm very happy in reading this! FSO actually is the only real thingh that lets survive the idea of open phones. With a rock solid framework taking care of all the underlying dirty work, writing some GUI interfaces is only a matter of time and may be done by community. About hardware, to have an usable phone we need a well supported hardware with a good kernel and good chip's firmwares (e.g. gsm). In my experience was that the problem with the freerunner, in one year I spent huge time on the device and encountered a lot of problems, sd card partition table corruption, problems with suspend/resume, WSOD, NSOD, glamo mci spare problems, gsm hopping, my vodafone card was not recognized before the latest gsm firmware updates, and many others that did not let me use the freerunner as a daily phone. That's the reason I really HOPE that OM will continue at least in kernel and low-level firmware developing, after all a stable Freerunner may be not so bad, and may be selled for a long time, funding OM and growing the community, and this is very important! Thanks for your effort! Best Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ePDFView package on opkg.org
On Tuesday 07 April 2009 17:38:13 Previdi Roberto wrote: > To scroll the pages you can just scroll "out of" the actual page. I'm > sorry for my english :) > Let me know of any questions. It is a huge improvement! The only problem I see is that if you rotate view to read lanscape it doesn't scroll if you reach the end of page. Would it be possible to add some "gesture" or similar to leave full screen? Now you can only leave it closing application. Thank you very much! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The future of the Neo Freerunner
On Sat, 4 Apr 2009 12:57:30 +0200 Nicola Mfb wrote: > 2009/4/3 Marcel > [...] > > > 2. These devs don't belong to Openmoko Inc. anymore, but they still > > contribute > > heavily to one or another aspect of the OM world. Afaik. > > > > And what's about Openmoko new software stack roadmap? > If it will not fund FSO, those developers may decide to stay a bit > relaxed. Let me assure you I'm not even close to anything resembling relaxed. :-) Not coding much at the moment, but trying to disprove the myths that seem to surround GTA02 like a foul stench. If you look at where the FSO team came from it should be clear that FSO will continue. I personally couldn't really imaging going back from my Freerunner to a non-open phone. Crappy as it may be in terms of usability I can do stuff on it that just wont happen anywhere else. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Leather case for Neo freeruner now 29 Euros
El día martes, abril 07, 2009 a las 08:00:25 +0200, Juan Lucas Dominguez Rubio escribió: > >> it sounds that folks are leaving a sinking ship :-( > > > WoW Wow, Matthias brakes on please... > > Fortunately, he didnt use the metaphor in its original form: > "RATS are leaving the sinking ship" > ;-) No, no ha sido fortuna, sino con intención no he usado esa palabra. No, it wasn't fortunately, but with intention that I didn't use the word. matthias ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Upadated - Intone (0.21 - alpha release) Elementary based mplayer frontend
Hi, ...but /home/root/.intone/intone_songs.db was one of the files in the package (as shown by "opkg files intone") so the songs db was overwritten on the install with the one from the package. Actually, the db file was in /usr/share/intone in version .20. I changed the location to ~/.intone only in version .21 But point taken - will cater for such situations. Some guys might have custom playlists which could be cumbersome to recreate. By the way when adding files it would be nice to have (if not a progress bar) a message of the form "Adding directory %s, %d files scanned" Will try to fit that in too! Have already added a feature where if you exit when paused, the next run will automatically start from the song at its paused position. -- View this message in context: http://n2.nabble.com/Intone-%280.20---alpha-release%29-Elementary-based-mplayer-frontend-tp2587826p2603566.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
