Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, 28 Oct 2009 20:42:16 +1100 Carsten Haitzler (The Rasterman) (CH(R) wrote: >On Wed, 28 Oct 2009 11:27:03 +0200 "Michael 'Mickey' Lauer" > said: > >> >The problem is : on the freerunner we merely need something to >> >display some simple widgets, scroll the screen smoothly (because on >> >a small display you always need to scroll) >> >> Why do all of you insist on using scrolling as the only metaphor to >> present excerpts of large content? Given the physical size of the >> display and the hardware constraints (touchscreen jitter, for a >> start... not going to comment on the Glamo) I think this is very >> questionable. There are other metaphors available that would fit the >> device's strengths much better. What about paging? > >good words mickey. good words. :) (i have a todo item for the scrole >rto have a page mode. it already has a page mode actually - but its a >scrolling one much like iphone's N pages of icons - but it's infra to >simple provide some theme elements that you press and they jump >up/down/left/right a page and then do the jump - so it's mostly there. >it just hasn't been any priority for me - am working on an oldie >request to get rotatable objects.. which now works. under flux.. but >works and renders... image and text objects so far are working. in >theory all other basic object types too, but smart objects - not yet). While i agree i still wonder. i tried latest android on freerunner yesterday - most scrolling nice and smooth. had qtmoko on last week - the same (yes, i read the explanation why it works, but it works). now, in order not to put anybody down, i must say that for example scrolling in shr contact list IS smooth. so my question is: where exactly do we have scrolling issues? think about it. Then i tend to think about the Illume desktop, that is so much unfriendly to scrolling. Raster, i meant to ask before but had no time: if we take etk toolkit and E window manager as for granted for SHR (hopefully with some choices, but still), is there any other desktop module we could use instead of Illume? In your no-speak project, is there anything being developed? What do you use on small device? Illume was ditched long time ago, is there not a replacement with attention? Anything you could recommend? Thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 08:16:22 +0100 Petr Vanek said: > On Wed, 28 Oct 2009 20:42:16 +1100 > Carsten Haitzler (The Rasterman) (CH(R) wrote: > > >On Wed, 28 Oct 2009 11:27:03 +0200 "Michael 'Mickey' Lauer" > > said: > > > >> >The problem is : on the freerunner we merely need something to > >> >display some simple widgets, scroll the screen smoothly (because on > >> >a small display you always need to scroll) > >> > >> Why do all of you insist on using scrolling as the only metaphor to > >> present excerpts of large content? Given the physical size of the > >> display and the hardware constraints (touchscreen jitter, for a > >> start... not going to comment on the Glamo) I think this is very > >> questionable. There are other metaphors available that would fit the > >> device's strengths much better. What about paging? > > > >good words mickey. good words. :) (i have a todo item for the scrole > >rto have a page mode. it already has a page mode actually - but its a > >scrolling one much like iphone's N pages of icons - but it's infra to > >simple provide some theme elements that you press and they jump > >up/down/left/right a page and then do the jump - so it's mostly there. > >it just hasn't been any priority for me - am working on an oldie > >request to get rotatable objects.. which now works. under flux.. but > >works and renders... image and text objects so far are working. in > >theory all other basic object types too, but smart objects - not yet). > > While i agree i still wonder. i tried latest android on freerunner > yesterday - most scrolling nice and smooth. had qtmoko on last week - > the same (yes, i read the explanation why it works, but it works). now, > in order not to put anybody down, i must say that for example scrolling > in shr contact list IS smooth. so my question is: where exactly do we > have scrolling issues? think about it. Then i tend to think about the > Illume desktop, that is so much unfriendly to scrolling. lots of alpha blending - if you have the 16bit engine you get no scale cache (thats 32bit engine only). but worst.. is the font style. check carefully. text has a soft dropshadow. that is drawn by 1. drawing the shadow first and that draw 25 copies of the text with very faint alpha. THEN draw the text on top. that is a pretty big expense. there is no text effect cache in evas at the moment, so this really hits you. turn off the soft dropshadow effect in the theme.. and watch it get 3 or 4 times faster (expedite has a test just for this - on a desktop (in fps) i get 128 and 489 fps respectively just by having no soft shadow on the text). thats pushing on close to 4 times faster. it's an effect - that doesn't come cheaply. the alternative (an actual blur filter) isn't too cheap either. but it's something that can be improved for sure. you want it fast? turn it off. :) > Raster, i meant to ask before but had no time: if we take etk toolkit > and E window manager as for granted for SHR (hopefully with some > choices, but still), is there any other desktop module we could use > instead of Illume? In your no-speak project, is there anything being no. illume is the only thign usable that will give u a fullscreen windowing policy in e at the moment. as i said before. i started a rewrite- illume2 is in svn. its much cleaner and leaner designed to allow for replacable home screens (ie a home window provides by either another e module or another process). as well as "top shelf" (inf act any corner/region of the screen) can also be a window provided by.. another module... or another process etc. its much more like the kbd code. it's started. it's not usable. it's on the backburner until a bunch of other tasks are done that are much higher priority. > developed? What do you use on small device? Illume was ditched long time > ago, is there not a replacement with attention? Anything you could > recommend? can't talk about it :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Community update 2009-10-28
Hello all New CU released [0], there was not too much news in last two weeks, but here we are. Some applications and distributions updated, there is new keyboard app - Kbosd. Take a look at Community and Events section. As usual, draft for the next CU [1] made. For all developers and community members. Please do add information to community update draft pages when you have made something new, or want to do it. It's one of the best ways to spread the word about you work. [0] http://wiki.openmoko.org/wiki/Community_Updates/2009-10-28 [1] http://wiki.openmoko.org/wiki/Community_Updates/Draft_2009-11-11 P.S sorry for my ugly English. -- So long, and thanks for all the fish. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QtMoko] Call quality
Just made my first QtMoko V14 based call, FR A5 with buzzfix -> IPhone and the other party struggled to understand me, they said somewhat faint and very crackly/broken up. I heard the other party clearly although I think I would have preferred a little more volume. I'm not sure if this is characteristic of QtMoko or just bad luck call quality, however my previous experience with SHRU was fine. Anyone else can report their call quality with QtMoko ? Denis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] glamo mplayer
On Thu, Oct 29, 2009 at 4:02 AM, Matthias Huber wrote: > did someone already try to port vlc media player ? +1 I have asked this months ago and got no replies, I hope the answer has changed as vlc works fine enough for playback on my desktop and was my first thought. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] glamo mplayer
On Thu, Oct 29, 2009 at 2:55 AM, Dan Staley wrote: > I was thinking about this the other day. There are arm4 ports of > myth-frontendso I wonder how well the frontend would run on the > freerunner. > It is designed to look good on low res screens > I may try installing the front-end after I get my new myth system migrated. I'd love to hear how you go. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] glamo mplayer
On Thu, Oct 29, 2009 at 1:02 AM, Radek Polak wrote: > Yes, the binary that QMplayer downloads from internet is using glamo > acceleration. > > Btw QMplayer has also PC version [1]. On your PC you can scan for media and > start http server which will offer videos encoded for Freerunner for streaming > or downloading. QMplayer in QtMoko can talk with the PC version from it's GUI. > > [1] http://activationrecord.net/radekp/qmplayer/ nice to know thanks. At the risk of being slammed for being OT discussion, does anyone know if there is a player for the IPhone which can play http stream ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] mediaplayer issue
On Thu, Oct 29, 2009 at 1:07 AM, Radek Polak wrote: > On Wednesday 28 of October 2009 03:37:34 Denis Johnson wrote: > >> How does one play a mpeg stream uing a link from qmplayer such as >> http://192.168.0.105//mythweb/pl/stream/1003/1256644800 > > You can try the "sharing" option. But the http parser in QMplayer is very > simple - so it will most probably wont work, but the source code is out there > and everyone can improve it ;) > > Another option is starting mplayer from command line or download the file via > web browser or wget and play it locally. I specifically want to try streaming as opposed to download as many recordings are large like 2gb or more apart form not wanting to wait for download, the FR may not have that much available unless using SD and then we hit other performance issue afaik (See glamo SDIO performance thread) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Call quality
-[ Thu, Oct 29, 2009 at 05:52:00PM +1000, Denis Johnson ] > I'm not sure if this is characteristic of QtMoko or just bad luck call > quality, however my previous experience with SHRU was fine. You should probably copy your mixer settings from SHR to QtMoko if it was better under SHR. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Call quality
On Thu, Oct 29, 2009 at 6:04 PM, wrote: > -[ Thu, Oct 29, 2009 at 05:52:00PM +1000, Denis Johnson ] >> I'm not sure if this is characteristic of QtMoko or just bad luck call >> quality, however my previous experience with SHRU was fine. > > You should probably copy your mixer settings from SHR to QtMoko > if it was better under SHR. Oops, already blown away :-( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
On Thu, Oct 29, 2009 at 01:20:44AM +0100, Thomas Otterbein wrote: > On Wednesday 28 October 2009 22:08:00 Rui Miguel Silva Seabra wrote: > > http://www.amazon.com/gp/bestsellers/electronics/172594/ref=pd_zg_hrsr_e_1_ > >3_last > > > > Wow, just wow! > > > > It's an interesting device, not for me, but quite interesting. > > > > What I never expected is such a success. > > > > Quite a comparison to the Freerunner's success :) > > > > Congratulations, guys! > > > > Rui > > Hmm, a lot of devices made by Palm, some of them already stone old, are the > Bestsellers at Amazon? Where is their own Kindle? Or devices from HTC? Does > HP > still procude Handhelds at all? Maybe the Kindle is too big for their category of "PDA & Handhelds" or maybe they don't include it as it's their own product, I don't know. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
On Thu, Oct 29, 2009 at 02:01:58PM +0800, Sean Moss-Pultz wrote: > On Thu, Oct 29, 2009 at 6:23 AM, Rui Miguel Silva Seabra > wrote: > > > > On Wed, Oct 28, 2009 at 09:08:00PM +, Rui Miguel Silva Seabra wrote: > > > http://www.amazon.com/gp/bestsellers/electronics/172594/ref=pd_zg_hrsr_e_1_3_last > > > > > > Wow, just wow! > > > > > > It's an interesting device, not for me, but quite interesting. > > > > > > What I never expected is such a success. > > > > > > Quite a comparison to the Freerunner's success :) > > > > > > Congratulations, guys! > > > > Rui Grilo, a portuguese politician on a major role in IT policy on the last > > goverment (which was reelected), found it really interesting: > > > > http://twitter.com/rgrilo/status/4829977172 > > > > Translation: Really interesting, RT @RuiSeabra wikipedia on your hands, > > offline and more ecological > > Wow that kicks so much ass! > > Please keep letting us know how the spanish community sees our > WikiReader. I used to know spanish, but it seems my head is only big > enough to hold two languages. ? Spanish is only marginally similar to portuguese... :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Call quality
This sounds something like others experienced after changes to the default shr alsa file - Try turning the Mike gain down a bit - it could be overdriving (symptoms for me were fait audio, cracles and rushing sounds like wind, but distant sounds came through clearly - if there was ambient noise the FR was unusable). Not sure how qtmoko controls the gain, but for shr there are a number of files around BillK On Thu, 2009-10-29 at 17:52 +1000, Denis Johnson wrote: > Just made my first QtMoko V14 based call, FR A5 with buzzfix -> IPhone > and the other party struggled to understand me, they said somewhat > faint and very crackly/broken up. I heard the other party clearly > although I think I would have preferred a little more volume. > > I'm not sure if this is characteristic of QtMoko or just bad luck call > quality, however my previous experience with SHRU was fine. > > Anyone else can report their call quality with QtMoko ? > > Denis > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- William Kenworthy Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Call quality
-[ Thu, Oct 29, 2009 at 06:09:30PM +1000, Denis Johnson ] > > You should probably copy your mixer settings from SHR to QtMoko > > if it was better under SHR. > > Oops, already blown away :-( Yes but if you never changed them you may be able to find the default ones on google. I had the same problem than you until two days ago, when I spent some time with my mother on the phone playing with alsamixer until she reported the sound quality was allright. It took around 15 minutes, but she did not complain because I do not call here very often. So maybe you also know someone whom you should call more often ... :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Version of Minimoko and additions
Dnia 2009-10-23, pią o godzinie 20:30 +0200, Matthias Huber pisze: > Good evening, Lists! > > Today i released a new Version of Minimoko with Additions. Hi Matthias, tell me should this be considered as another distro? I mean, do you want to put this into applications or distro section in CU? -- Patryk "LeadMan" Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
> lots of alpha blending - if you have the 16bit engine you get no > scale cache (thats 32bit engine only). but worst.. is the font > style. check carefully. text has a soft dropshadow. that is drawn > by 1. drawing the shadow first and that draw 25 copies of the text > with very faint alpha. THEN draw the text on top. that is a pretty > big expense. there is no text effect cache in evas at the moment, > so this really hits you. turn off the soft dropshadow effect in the > theme.. and watch it get 3 or 4 times faster (expedite has a test > just for this > - on a desktop (in fps) i get 128 and 489 fps respectively just by > having no soft shadow on the text). thats pushing on close to 4 > times faster. it's an effect - that doesn't come cheaply. the > alternative (an actual blur filter) isn't too cheap either. but > it's something that can be improved for sure. you want it fast? > turn it off. :) Thank you for all the explanation. I think the 32bit engine is the only to go with now. Perhaps the optimization is is already done, maybe not. @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? > i started a > rewrite- illume2 is in svn. its much cleaner and leaner designed to > allow for replacable home screens (ie a home window provides by > either another e module or another process). as well as "top > shelf" (inf act any corner/region of the screen) can also be a > window provided by.. another module... or another process etc. its > much more like the kbd code. it's started. it's not usable. it's on > the backburner until a bunch of other tasks are done that are much > higher priority. ok, will hope for better times to come > > developed? What do you use on small device? Illume was ditched > > long time ago, is there not a replacement with attention? > > Anything you could recommend? > can't talk about it :) perhaps we can benefit from it in (near?) future... :) thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Strange behaviour of elementary entry and illume keyboard. Did anybody noticed it?
I logged it in the SHR bug tracker two months back: http://trac.shr-project.org/trac/ticket/601 The ticket got closed with following comments: "I also stumbled upon this issue, it's an upstream issue, someone should really open a ticket in the e17 trac, I'll try looking into it more throughly." I haven't logged any bug in the e17 trac. Niels. -- Microsoft gives you windows, Linux gives you the whole house. > To: community@lists.openmoko.org > From: van...@penguin.cz > Date: Wed, 28 Oct 2009 19:43:36 +0100 > Subject: Re: Strange behaviour of elementary entry and illume keyboard. Did > anybody noticed it? > >>Oh yes, I got VERY annoyed from that f*cking inconsistent backspace >>behaviour! Sorry, this had to be written. Its so annoying when editing >>text after having typed a few sentences, although I couldn't make out >>any rule behind that. >> >>Am Mittwoch, den 28.10.2009, 19:15 +0100 schrieb Laszlo KREKACS: >>> Hi! >>> >>> Have anybody noticed, when you type some text in a elementary entry, >>> then you click on any other element (a button for example) and you >>> click again on the entry. >>> >>> Now the cursor is still at the end of the text. But when you send >>> some chars using illume >>> keyword it inserts the chars *before the last char*. > > > has this been reported in E track? > > Petr > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community _ Windows 7: helpt je meer voor elkaar te krijgen. Ontdek Windows 7. http://windows.microsoft.com/windows-7 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[ALL] Call quality
Which one is the mike gain? Does anything change in the mike when going from handset to speakerset? The page on the wiki isn't very enlightening for non-handset cases... Rui On Thu, Oct 29, 2009 at 04:16:37PM +0800, William Kenworthy wrote: > This sounds something like others experienced after changes to the > default shr alsa file - Try turning the Mike gain down a bit - it could > be overdriving (symptoms for me were fait audio, cracles and rushing > sounds like wind, but distant sounds came through clearly - if there was > ambient noise the FR was unusable). Not sure how qtmoko controls the > gain, but for shr there are a number of files around > > BillK > > > On Thu, 2009-10-29 at 17:52 +1000, Denis Johnson wrote: > > Just made my first QtMoko V14 based call, FR A5 with buzzfix -> IPhone > > and the other party struggled to understand me, they said somewhat > > faint and very crackly/broken up. I heard the other party clearly > > although I think I would have preferred a little more volume. > > > > I'm not sure if this is characteristic of QtMoko or just bad luck call > > quality, however my previous experience with SHRU was fine. > > > > Anyone else can report their call quality with QtMoko ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community update 2009-10-28
Thanks! But I would say there are lot of news this time ;) thanks to all contributors. -- Patryk "LeadMan" Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Version of Minimoko and additions
Patryk Benderz schrieb: Dnia 2009-10-23, pią o godzinie 20:30 +0200, Matthias Huber pisze: Good evening, Lists! Today i released a new Version of Minimoko with Additions. Hi Matthias, tell me should this be considered as another distro? I mean, do you want to put this into applications or distro section in CU? it is definitely no disto. for a distro, you make special packages and compile all yourself therefore i declared Minimoko as "Desktop" and xminimokostatus as "Application". (also, it bases fully on shr and shr works fully, if you rename my .Xsession) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Call quality
On Thu, Oct 29, 2009 at 6:17 PM, wrote: > -[ Thu, Oct 29, 2009 at 06:09:30PM +1000, Denis Johnson ] >> > You should probably copy your mixer settings from SHR to QtMoko >> > if it was better under SHR. >> >> Oops, already blown away :-( > > Yes but if you never changed them you may be able to find the default ones > on google. ok, I did end up changing them Inever had quality problems in shr but things were faint so I tweaked until I got acceptable. Fortunately I have a backup on my desktop machine. The gsmhandset.state file I used in SHR is attached. But I am yet to try it on QtMoko Denis gsmhandset.state Description: Binary data ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: how to port a scheme interpreter to om?
2009/10/28 Shawn : > >> >> Ah, the happy conjunction of my main free software interests... (I'm >> one of Guile's maintainers.) > > wowo~it's pleasure to meet you here dude~ Likewise! > checking for lt_dlinit in -lltdl... no > configure: error: libltdl not found. See README. OK, this just means that you're missing a prerequisite: development files (headers and libraries) for the libltdl library. On Debian these are in the libltdl-dev package; on other distros I'd look for libltdl-dev, or libtool-dev, or something like that. To save time, you may like to check the other prerequisite too, i.e. GMP, before trying to build again. You can find the details in the README file. Hope that helps! Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Petr Vanek wrote: >> lots of alpha blending - if you have the 16bit engine you get no >> scale cache (thats 32bit engine only). but worst.. is the font >> style. check carefully. text has a soft dropshadow. that is drawn >> by 1. drawing the shadow first and that draw 25 copies of the text >> with very faint alpha. THEN draw the text on top. that is a pretty >> big expense. there is no text effect cache in evas at the moment, >> so this really hits you. turn off the soft dropshadow effect in the >> theme.. and watch it get 3 or 4 times faster (expedite has a test >> just for this >> - on a desktop (in fps) i get 128 and 489 fps respectively just by >> having no soft shadow on the text). thats pushing on close to 4 >> times faster. it's an effect - that doesn't come cheaply. the >> alternative (an actual blur filter) isn't too cheap either. but >> it's something that can be improved for sure. you want it fast? >> turn it off. :) >> > > > Thank you for all the explanation. I think the 32bit engine is the > only to go with now. Perhaps the optimization is is already done, > maybe not. > > @Bernd Prünster: you are already very good with this, it would be good > to see the difference, if not used already... mind to try the above in > gry* ? > gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... > >> i started a >> rewrite- illume2 is in svn. its much cleaner and leaner designed to >> allow for replacable home screens (ie a home window provides by >> either another e module or another process). as well as "top >> shelf" (inf act any corner/region of the screen) can also be a >> window provided by.. another module... or another process etc. its >> much more like the kbd code. it's started. it's not usable. it's on >> the backburner until a bunch of other tasks are done that are much >> higher priority. >> > > ok, will hope for better times to come > > >>> developed? What do you use on small device? Illume was ditched >>> long time ago, is there not a replacement with attention? >>> Anything you could recommend? >>> >> can't talk about it :) >> > > perhaps we can benefit from it in (near?) future... :) > > thank you > > Petr > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Call quality
On Thu, Oct 29, 2009 at 7:38 PM, Denis Johnson wrote: > On Thu, Oct 29, 2009 at 6:17 PM, wrote: > Fortunately I have a backup on my desktop machine. The > gsmhandset.state file I used in SHR is attached. But I am yet to try > it on QtMoko sorry to reply to my own mail but I wanted to report back that I retried a call to the same party after changing to my shr state file and although they reported it to be an improvement they said they now had echo at their end. denis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Launcher v0.41 - New Release
Hi, Here is the latest release. Changes :- 1. Clean Ups, Bug fixes and Speed ups (hopefully) 2. Should indicate last call made and sms sent in contacts app 3. Better re-sending of failed sms's Enjoy. http://n2.nabble.com/file/n3911066/launcher_0.41_arm.ipk launcher_0.41_arm.ipk -- View this message in context: http://n2.nabble.com/Launcher-v0-41-New-Release-tp3911066p3911066.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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
>> @Bernd Prünster: you are already very good with this, it would be >> good to see the difference, if not used already... mind to try the >> above in gry* ? >> >gry* doesnt use dropshadow, it was one of the forst thigs i kicked >out, gry* uses a white outline on black text. >but thats something thats bugging me. i have to make some tests... i have been trying gry* lately and more less like it. btw can you already change the background image in Illume settings? i still get the "Enlightenment was unable to import the image due to conversion errors" ? Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 11:37:06 +0100 Petr Vanek said: > >> @Bernd Prünster: you are already very good with this, it would be > >> good to see the difference, if not used already... mind to try the > >> above in gry* ? > >> > >gry* doesnt use dropshadow, it was one of the forst thigs i kicked > >out, gry* uses a white outline on black text. > >but thats something thats bugging me. i have to make some tests... > > i have been trying gry* lately and more less like it. > > btw can you already change the background image in Illume settings? i > still get the "Enlightenment was unable to import the image due to > conversion errors" ? u are probably missing edje_cc from the distro -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 11:12:29 +0100 Bernd Prünster said: > Petr Vanek wrote: > >> lots of alpha blending - if you have the 16bit engine you get no > >> scale cache (thats 32bit engine only). but worst.. is the font > >> style. check carefully. text has a soft dropshadow. that is drawn > >> by 1. drawing the shadow first and that draw 25 copies of the text > >> with very faint alpha. THEN draw the text on top. that is a pretty > >> big expense. there is no text effect cache in evas at the moment, > >> so this really hits you. turn off the soft dropshadow effect in the > >> theme.. and watch it get 3 or 4 times faster (expedite has a test > >> just for this > >> - on a desktop (in fps) i get 128 and 489 fps respectively just by > >> having no soft shadow on the text). thats pushing on close to 4 > >> times faster. it's an effect - that doesn't come cheaply. the > >> alternative (an actual blur filter) isn't too cheap either. but > >> it's something that can be improved for sure. you want it fast? > >> turn it off. :) > >> > > > > > > Thank you for all the explanation. I think the 32bit engine is the > > only to go with now. Perhaps the optimization is is already done, > > maybe not. > > > > @Bernd Prünster: you are already very good with this, it would be good > > to see the difference, if not used already... mind to try the above in > > gry* ? > > > gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, > gry* uses a white outline on black text. > but thats something thats bugging me. i have to make some tests... even that can be slow. in this case, the text will be drawn 5 times to produce that effect. > >> i started a > >> rewrite- illume2 is in svn. its much cleaner and leaner designed to > >> allow for replacable home screens (ie a home window provides by > >> either another e module or another process). as well as "top > >> shelf" (inf act any corner/region of the screen) can also be a > >> window provided by.. another module... or another process etc. its > >> much more like the kbd code. it's started. it's not usable. it's on > >> the backburner until a bunch of other tasks are done that are much > >> higher priority. > >> > > > > ok, will hope for better times to come > > > > > >>> developed? What do you use on small device? Illume was ditched > >>> long time ago, is there not a replacement with attention? > >>> Anything you could recommend? > >>> > >> can't talk about it :) > >> > > > > perhaps we can benefit from it in (near?) future... :) > > > > thank you > > > > Petr > > > > > > > > ___ > > 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 -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Gift for c_c
Hi! Some months back I promised to c_c to show him an example code, how to hide elementary entry, and show another. (Intone paging between lyrics view, cover art view, file list). So here it goes: http://github.com/klaszlo/esnippets/tree/master/playground/intone/ Just launch this program using (I already compiled the .edj file, so you dont need to launch build.sh manually): python cc_simple.py How demo works: Just click on the entry (Textbox 1), it should change to "Textbox 2" and back to "Textbox 1" when you click it again. I hope you find it useful c_c, and you implement it in your intone program. No more excuse ... Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
CH(R> > btw can you already change the background image in Illume settings? i CH(R> > still get the "Enlightenment was unable to import the image due to CH(R> > conversion errors" ? CH(R> CH(R> u are probably missing edje_cc from the distro thanks, this was it. i have already reported it distro maintainers. Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
Thomas Otterbein writes: > > On Wednesday 28 October 2009 22:08:00 Rui Miguel Silva Seabra wrote: > > http://www.amazon.com/gp/bestsellers/electronics/172594/ref=pd_zg_hrsr_e_1_ > >3_last > > > > Wow, just wow! > > > > It's an interesting device, not for me, but quite interesting. > > > > What I never expected is such a success. > > > > Quite a comparison to the Freerunner's success :) > > > > Congratulations, guys! > > > > Rui > > Hmm, a lot of devices made by Palm, some of them already stone old, > are the Bestsellers at Amazon? Where is their own Kindle? The Kindle is listed as a best-seller, but in a different subcategory of `electronics'. Actually, it occupies multiple spots in the top-10 listing in the *overall* `electronics' category, while WikiReader is #4 in a much more restricted category. Not to downplay whatever success the WikiReader is seeing, though--I got one, myself, and I'm very impressed by and happy with it; a few of my technically-minded friends have remarked critically, merely on a conceptual basis, but those who have actually seen it (especially the `normal people') have responded very positively. It's really not evident just how profound the device is until you find yourslef amongst friends who are trying to remember the details of something of which you've never even heard, and then suddenly `you're the expert' in the group. My first experience with this: a couple of friends were trying to make sense of their memories of `trying to read' Nikolai Gogol's book, `Dead Souls'..., and there it was in my WikiReader--suddenly I was an expert on the book (the big question was `what was the point of the protagonist's scheme to buy already-dead serfs who counted as taxable property for him'; the answer was `he was going to retire by *mortgaging* them'). My wife and I received a `this is what the mercaptan additive in Natural gas smells like' scratch-and-sniff in the mail from the local gas-supply company, the other day, and I was able to instantly start a conversation with my wife, in our kitchen, about the history behind these odour-additives (and this history turns out to be quite an amazing story, actually). We're having amazing experiences like this semi-regularly, thanks to this device. People do say `$100 seems a little expensive', but then they concede that maybe it /isn't/ so expensive when reminded that just an 8-GB micro-SD card by itself retails for as much as $50 (and I note that more simplistic devices than the WikiReader, on that Amazon list--like the Scrabble-dictionary--also sell for $50+...). After actually having the profoundly-wowing `instant expert' experience a few times, it becomes easy to accept that the device as being worth $100, even though it's terribly difficult to `just explain it' to someone who has the perspective of `well, *I* already have a $500 device with a $100-per-*month* subscription and a favourable location that alows *me* to be connected to the Internet all the time, anything that doesn't provide wireless real-time updates and *news* with updated charts and graphs has all the appeal of the Pet Rock'. I guess I should post this on Amazon's review-page for the device Regarding the Amazon best-seller list per se: I'm not sure that I'm entirely clear on what exactly Amazon's `bestseller' rating means-- is the `current ranking' just based on the rate of sales per hour, averaged over the last 1 hour? Do they explain it, somewhere? -- Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
Joshua You made everyone in the Taipei office so happy with this post. This is exactly the type of experiences we had in mind when creating WikiReader. Please do post on Amazon if you have a bit of extra time: http://bit.ly/3spvKq It really does help us a lot! -Sean On Thu, Oct 29, 2009 at 9:35 PM, Joshua Judson Rosen wrote: > > Thomas Otterbein writes: > > > > On Wednesday 28 October 2009 22:08:00 Rui Miguel Silva Seabra wrote: > > > http://www.amazon.com/gp/bestsellers/electronics/172594/ref=pd_zg_hrsr_e_1_ > > >3_last > > > > > > Wow, just wow! > > > > > > It's an interesting device, not for me, but quite interesting. > > > > > > What I never expected is such a success. > > > > > > Quite a comparison to the Freerunner's success :) > > > > > > Congratulations, guys! > > > > > > Rui > > > > Hmm, a lot of devices made by Palm, some of them already stone old, > > are the Bestsellers at Amazon? Where is their own Kindle? > > The Kindle is listed as a best-seller, but in a different subcategory > of `electronics'. Actually, it occupies multiple spots in the top-10 > listing in the *overall* `electronics' category, while WikiReader is > #4 in a much more restricted category. Not to downplay whatever > success the WikiReader is seeing, though--I got one, myself, and I'm > very impressed by and happy with it; a few of my technically-minded > friends have remarked critically, merely on a conceptual basis, but > those who have actually seen it (especially the `normal people') have > responded very positively. > > It's really not evident just how profound the device is until you find > yourslef amongst friends who are trying to remember the details of > something of which you've never even heard, and then suddenly `you're > the expert' in the group. My first experience with this: a couple of > friends were trying to make sense of their memories of `trying to > read' Nikolai Gogol's book, `Dead Souls'..., and there it was in my > WikiReader--suddenly I was an expert on the book (the big question was > `what was the point of the protagonist's scheme to buy already-dead > serfs who counted as taxable property for him'; the answer was `he was > going to retire by *mortgaging* them'). My wife and I received a `this > is what the mercaptan additive in Natural gas smells like' > scratch-and-sniff in the mail from the local gas-supply company, the > other day, and I was able to instantly start a conversation with my > wife, in our kitchen, about the history behind these odour-additives > (and this history turns out to be quite an amazing story, > actually). We're having amazing experiences like this semi-regularly, > thanks to this device. > > People do say `$100 seems a little expensive', but then they concede > that maybe it /isn't/ so expensive when reminded that just an 8-GB > micro-SD card by itself retails for as much as $50 (and I note that > more simplistic devices than the WikiReader, on that Amazon list--like > the Scrabble-dictionary--also sell for $50+...). > > After actually having the profoundly-wowing `instant expert' > experience a few times, it becomes easy to accept that the device as > being worth $100, even though it's terribly difficult to `just explain > it' to someone who has the perspective of `well, *I* already have a > $500 device with a $100-per-*month* subscription and a favourable > location that alows *me* to be connected to the Internet all the time, > anything that doesn't provide wireless real-time updates and *news* > with updated charts and graphs has all the appeal of the Pet Rock'. > > I guess I should post this on Amazon's review-page for the device > > Regarding the Amazon best-seller list per se: I'm not sure that I'm > entirely clear on what exactly Amazon's `bestseller' rating means-- > is the `current ranking' just based on the rate of sales per hour, > averaged over the last 1 hour? Do they explain it, somewhere? > > -- > Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
On Thursday 29 October 2009 14:35 Joshua Judson Rosen wrote: > Thomas Otterbein writes: > > On Wednesday 28 October 2009 22:08:00 Rui Miguel Silva Seabra wrote: > > > http://www.amazon.com/gp/bestsellers/electronics/172594/ref=pd_zg_hrsr_ > > >e_1_ 3_last > > > > > > Wow, just wow! > > > > > > It's an interesting device, not for me, but quite interesting. > > > > > > What I never expected is such a success. > > > > > > Quite a comparison to the Freerunner's success :) > > > > > > Congratulations, guys! > > > > > > Rui > > > > Hmm, a lot of devices made by Palm, some of them already stone old, > > are the Bestsellers at Amazon? Where is their own Kindle? > > The Kindle is listed as a best-seller, but in a different subcategory > of `electronics'. Actually, it occupies multiple spots in the top-10 > listing in the *overall* `electronics' category, while WikiReader is > #4 in a much more restricted category. Not to downplay whatever > success the WikiReader is seeing, though--I got one, myself, and I'm > very impressed by and happy with it; a few of my technically-minded > friends have remarked critically, merely on a conceptual basis, but > those who have actually seen it (especially the `normal people') have > responded very positively. I do not doubt the value of the device, though it's of no use for me until I get a international version (Hungarian, German), for my kids - or even better a version supporting images, for myself. :-) However I find it a bit miss-placed between the other "PDAs" as they have very little in common, beyond the ability to display pages from Wikipedia. And I'm still under the impression that the other devices are fairly outdated. There are 8 devices produced by Palm between the first 25. And there is also a "Siemens Flip Phone" (i doubt it's PDA capabilities). Siemens sold it's mobile business to BenQ ages ago and even BenQ abandoned it for a couple of years now. Again, this is not criticism on the Wikireader but rather questioning the Amazon Bestseller List as such. However Sean has already mentioned in this thread that the sales numbers are huge, so a high ranking in whatever list is most likely appropriate. ;-) Best Regards thomas -- Thomas Otterbein ASCII ribbon campaign ( ) against HTML e-mail X www.asciiribbon.org / \ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
> However I find it a bit miss-placed between the other "PDAs" as they "PDA & Handheld" -- and btw: who makes the charts makes the categories :-) > still under the impression that the other devices are fairly outdated. looks like "all time top 100" -- the sheer number of devices sold seems to count. as long as the device is sold by amazon, it's potentially in the top 100, i guess (looking at frinst "1478 days in the top 100" for palm tx, being still avaliable). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Carsten Haitzler (The Rasterman) wrote: >> gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, >> gry* uses a white outline on black text. >> but thats something thats bugging me. i have to make some tests... >> > > even that can be slow. in this case, the text will be drawn 5 times to produce > that effect. > rater, would you mind to elaborate? (is outline the fastest effect if you want to enable the user to set a custom background while maintaining the labels readable?) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
On Thu, Oct 29, 2009 at 1:20 AM, Thomas Otterbein wrote: > Hmm, a lot of devices made by Palm, some of them already stone old, are the > Bestsellers at Amazon? Where is their own Kindle? Or devices from HTC? Does HP > still procude Handhelds at all? > If we take all the electronics category, the Kindle is the first, and WikiReader is not in the top 100: http://www.amazon.com/gp/bestsellers/electronics/ref=pd_ts_pg_4?ie=UTF8&pg=4 Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
On Thu, Oct 29, 2009 at 3:40 PM, Laszlo KREKACS wrote: > http://www.amazon.com/gp/bestsellers/electronics/ref=pd_ts_pg_4?ie=UTF8&pg=4 Just to put this into perspective: Amazon Kindle got 7111 customer review while WikiReader 13. Laszlo ps: sorry for spamming the thread;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
2009/10/29 Laszlo KREKACS > On Thu, Oct 29, 2009 at 3:40 PM, Laszlo KREKACS > wrote: > > > http://www.amazon.com/gp/bestsellers/electronics/ref=pd_ts_pg_4?ie=UTF8&pg=4 > > Just to put this into perspective: > Amazon Kindle got 7111 customer review while WikiReader 13. > You'd need to compare for how long each one is being sold. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
2009/10/28 Michael 'Mickey' Lauer : > > Why do all of you insist on using scrolling as the only metaphor to present > excerpts of large content? Given the physical size of the display and the > hardware constraints (touchscreen jitter, for a start... not going to comment > on the Glamo) I think this is very questionable. There are other metaphors > available that would fit the device's strengths much better. What about > paging? Excellent idea. Certainly as far as the Illume launcher is concerned, I think it would be more usable (instead of having to scroll) to have multiple pages of icons, which you switch between using the same < and > as for switching between apps. (i.e. each icon page acts like another app) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Call quality
2009/10/29 Denis Johnson : > > I'm not sure if this is characteristic of QtMoko or just bad luck call > quality, however my previous experience with SHRU was fine. I wonder how all the distro guys decide what state files to include. Surely we don't need each distribution making independent decisions on this? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR] which to use?
I was thinking about try SHR again, but I don't know which image I should use. I heard somewhere that there was a mostly-stable image built in October, but I can't find it anywhere. I have the unstable from early September, but I thought that there was something more recent than that. Thanks, Tonym ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: how to port a scheme interpreter to om?
thanks, Neil.I will take it try after the compiling of openWRT is finished. > > OK, this just means that you're missing a prerequisite: development > files (headers and libraries) for the libltdl library. On Debian > these are in the libltdl-dev package; on other distros I'd look for > libltdl-dev, or libtool-dev, or something like that. > > To save time, you may like to check the other prerequisite too, i.e. > GMP, before trying to build again. You can find the details in the > README file. > > Hope that helps! > Neil > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- GNU powered it... GPL protect it... God blessing it... regards HFG--Shawn the R0ck ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gift for c_c
Hi, Laszlo KREKACS wrote: > > I hope you find it useful c_c, and you implement it in your intone > program. No more excuse ... > I will :-D Thanks! There are a few pending things to be done in intone. Will do them soon. -- View this message in context: http://n2.nabble.com/Gift-for-c-c-tp3911968p3914627.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: [ALL] Call quality
On Thursday 29 October 2009, Rui Miguel Silva Seabra wrote: > Which one is the mike gain? 48. The advice on the wiki is bad, and likely to lead to distortion. Keep 48 low unless you have 12 and 5 near maximum. > Does anything change in the mike when going from handset to speakerset? Possibly, especially if you've changed the mic settings in gsmhandset.state. 48, 12 and 5 are the channels you want to look at for the mic. > The page on the wiki isn't very enlightening for non-handset cases... Half of me thinks this is a good idea as if it's not obvious from the diagram at http://wiki.openmoko.org/wiki/Neo_1973_audio_subsystem#ALSA_Channels then people are probably going to combine the settings badly anyway. The other half says I want to check through all the state files anyway, and I may as well document it better when I do. If you're using an FSO-based distro you could try fso-simplemixer.py. It presents you with a single slider for Mic, and sets the required channels in a sensible combination. The few reports so far suggest it does a good job, but back up your state files or using it just in case. Details in the thread below. http://lists.openmoko.org/pipermail/community/2009-October/056063.html > Rui > > On Thu, Oct 29, 2009 at 04:16:37PM +0800, William Kenworthy wrote: > > This sounds something like others experienced after changes to the > > default shr alsa file - Try turning the Mike gain down a bit - it could > > be overdriving (symptoms for me were fait audio, cracles and rushing > > sounds like wind, but distant sounds came through clearly - if there was > > ambient noise the FR was unusable). Not sure how qtmoko controls the > > gain, but for shr there are a number of files around > > > > BillK > > > > On Thu, 2009-10-29 at 17:52 +1000, Denis Johnson wrote: > > > Just made my first QtMoko V14 based call, FR A5 with buzzfix -> IPhone > > > and the other party struggled to understand me, they said somewhat > > > faint and very crackly/broken up. I heard the other party clearly > > > although I think I would have preferred a little more volume. > > > > > > I'm not sure if this is characteristic of QtMoko or just bad luck call > > > quality, however my previous experience with SHRU was fine. > > > > > > Anyone else can report their call quality with QtMoko ? > > ___ > 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: how to port a scheme interpreter to om?
On Wed, Oct 28, 2009 at 8:57 AM, Shawn wrote: > hi guys, >does anybody has try to port the scheme interpreter(guile,etc) to > openMOKO? I have used Chicken on OM. You can even compile scheme to machine code right on the phone if you have gcc etc. installed. And I wrote an OE recipe for it too (which might mean there are packages being built... I haven't checked lately). http://chicken.wiki.br/cross-compilation-on-open-moko I think Chicken is way faster than Guile, and has a lot of libraries/extensions (called "eggs") available. http://chicken.wiki.br/chicken-projects/egg-index-4.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gift for c_c
On Thu, Oct 29, 2009 at 7:17 PM, c_c wrote: >> I hope you find it useful c_c, and you implement it in your intone >> program. No more excuse ... >> > I will :-D Thanks! > There are a few pending things to be done in intone. Will do them soon. I also figured out a rough way to autoscroll lyrics based on the music: 1. We know the current position and the length of the music: t_percent = t_cur/t_length 2. We can scroll an elementary scroller: (x_cur, y_cur, x_max, y_max) = scroller1.region_get() y_cur = int(y_max*t_percent) scroller1.region_show(x_cur, y_cur, x_max, y_max) It will be not accurate (so when we scroll with our finger, we should disable the autoscrolling feature), but should work most of the time;-) (also reenable when songs changes) Also I have thinked a bit about lyrics timing function. We should display the lyrics as normal edje TEXT. So we can change each line's color. Also we need some buttons (preferably over the text). No scrolling required in this scenario. We see the current line and past two lines and the following two lines. I can cook up a proof-of-concept gui for this, if you have trouble. If you have trouble with my precedent example, I can finish the intone gui (I already did a hbox with some buttons;-), just didnt want to confuse you. But the idea is simple, we are using edje for the same as you used vbox. Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, Oct 29, 2009 at 4:46 PM, Neil Jerram wrote: > I think it would be more usable (instead of having to scroll) to have > multiple pages of icons, which you switch between using the same < and >> as for switching between apps. (i.e. each icon page acts like > another app) To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app 2. sliding left/sliding right would change the current page. I would also suggest different background image for each "virtual desktop". Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
On Wed, Oct 28, 2009 at 10:08 PM, Rui Miguel Silva Seabra wrote: > > http://www.amazon.com/gp/bestsellers/electronics/172594/ref=pd_zg_hrsr_e_1_3_last > > Wow, just wow! > > It's an interesting device, not for me, but quite interesting. > Yes, I am eagerly awaiting mine. usps has the package listed as "Status:Acceptance", and it was accepted on Oct. 22. Hopefully I will get it soon. :-) -- Regards, Torfinn Ingolfsen, Norway ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, 2009-10-28 at 12:51 +0100, DJDAS wrote: > otherwise I would by an HTC with Android if I only wanted > a Linux-phone carefull...everything is non-standard Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QVGA 240x320 in GTA01 in SHR
Hi Can anyone help me get GTA01 into 240x320 mode in SHR unstable (latest buildhost) I've tried the following.. $ xrandr -s 240x320 Size 240x320 not found in available modes $ chvt 4 && echo qvga-normal > /sys/devices/platform/spi_s3c24xx_gpio.1/spi0.0/state && fbset qvga LCD changes to something but it's all messed up, grey lines, nothing really recognisable. Have to reboot phone to get it back to readable. Thanks, Ben. My fb.modes file is the typical one and contains the following # Timings for GTA01 VGA and QVGA mode mode "480x640" # D: 26.000 MHz, H: 43.334 kHz, V: 65.657 Hz geometry 480 640 480 640 16 timings 38461 104 8 2 16 8 2 accel false endmode mode "vga" # D: 26.000 MHz, H: 43.334 kHz, V: 65.657 Hz geometry 480 640 480 640 16 timings 38461 104 8 2 16 8 2 accel false endmode mode "240x320" # D: 8.475 MHz, H: 24.635 kHz, V: 75.569 Hz geometry 240 320 240 320 16 timings 118000 88 8 2 2 8 2 accel false endmode mode "qvga" # D: 8.475 MHz, H: 24.635 kHz, V: 75.569 Hz geometry 240 320 240 320 16 timings 118000 88 8 2 2 8 2 accel false endmode ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[wikireader]Error on parsing the spanish wikipedia
Hi I'm trying to generate the file for a spainsh wikipedia on the WR , after compiling succsesfuly the source on the git and solve some annoyings with utf8 encoding on phyton error was somthing like this: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position: ordinal not in range(128) this was solved changing the default encode "ascii" to "utf8" int the /usr/lib/python2.6/site.py file after this I was hable to execute ok the instruction: make DESTDIR=image WORKDIR=work XML_FILES=xml-file-samples/eswiki-latest-pages-articles.xml index parse render combine Every thing seem fine for a couple(about 6-7h) of hours parsing the 70 articles in spanish but then ... the horror Count: 38 Traceback (most recent call last): File "./ArticleParser.py", line 224, in main() File "./ArticleParser.py", line 172, in main process_article_text(title.encode('utf-8'), f.read(length), newf) File "./ArticleParser.py", line 218, in process_article_text newf.write(text + '\n') IOError: [Errno 32] Broken pipe make[1]: *** [parse] Error 1 make[1]: se sale del directorio `/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer' make: *** [parse] Error 2 I have relaunched the process again with the (few)hope that was a temporary fault but If any one has a clue will be helpfull. BTW.- I documenting all this proccess to make a step by step howto on how to put the wikipedia in other languages on the wikireader. David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher v0.41 - New Release
> Here is the latest release. Changes :- > >1. Clean Ups, Bug fixes and Speed ups (hopefully) >2. Should indicate last call made and sms sent in contacts app >3. Better re-sending of failed sms's > >Enjoy. > >http://n2.nabble.com/file/n3911066/launcher_0.41_arm.ipk >launcher_0.41_arm.ipk good, good! first start was somewhat slow, so i erased the .launcher db to start fresh, although now i think it was framework still starting... now it starts damn fast! it feels very responding, after all data is loaded. (most delays seem to be caused by waiting for the opimd data). two minor issues: 1) in contacts, all the categories are listed twice (all empty), this was also the same in .39. 2) opimd fields should probably be configurable somewhat, now it doesn't show all my fields... or did i miss something? phonelog now allows functional call deletion, great! (after launcher restart, i can see some calls from 1.1.1970 again but i think the opimd db got borked, i will erase it and start fresh). thank you, kind regards Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, Oct 28, 2009 at 5:44 AM, wrote: > > Reading an ebook or looking a webpage or a map is better with scrolling > I guess. > > > I've been using my FR with ePdfView to read books quite a bit lately, and I always read a full screen of text and then click on the scrollbar to move to the next screen of text. I find it hard to track text on the screen if you are continuously scroll - I think paging is a much better metaphor, at least for ebook reading. A map might be one situation where incremental scrolling is better than paging - I certainly use it a lot on my desktop when using google maps, for instance. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Understanding accelerometer data
I'm struggling to understand my accelerometer data. Here's what I see, opening and reading the /dev/input/event[2,3] files every 4 seconds, when my FR is flat on its back on the table. (event2 -36 54 198)(event3 -72 108 234) (event2 -36 54 198)(event3 -72 90 234) (event2 -36 54 198)(event3 -72 108 252) (event2 -36 54 198)(event3 -72 108 234) I'd expect the x and y values to be much smaller than the z values (compared to the ratios here) because of the z value including gravity. Am I misunderstanding what the data is telling me? To put it another way, if I accept that the z values here do mean 1g, it looks like there are x and y accelerations going on of between 0.1g and 0.5g - which is unexpected given that the FR is not moving. Thanks for any enlightenment! Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Laszlo KREKACS schrieb: On Thu, Oct 29, 2009 at 4:46 PM, Neil Jerram wrote: I think it would be more usable (instead of having to scroll) to have multiple pages of icons, which you switch between using the same < and as for switching between apps. (i.e. each icon page acts like another app) To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. 2. sliding left/sliding right would change the current page. I would also suggest different background image for each "virtual desktop". sliding between desktops is very interesting for me too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Understanding accelerometer data
2009/10/30 Neil Jerram : > I'd expect the x and y values to be much smaller than the z values > (compared to the ratios here) because of the z value including > gravity. Am I misunderstanding what the data is telling me? yes. acceleration is change of velocity. if there is no change in velocity, there will be no acceleration. hence, if the phone is still, all acc values should be zero. gravity or not, there is no net acc on the phone. i don't know the format the accelerometers output data in, but i'd take a punt that the values shown are noise. try running one of the acc scripts on the wiki and going for a walk/run/climbing steps/waving it around/car ride with it, to see what sort of acc values you can get for different activities ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Understanding accelerometer data
Am Donnerstag, 29. Oktober 2009 23:16:53 schrieb Robin Paulson: > 2009/10/30 Neil Jerram : > > I'd expect the x and y values to be much smaller than the z values > > (compared to the ratios here) because of the z value including > > gravity. Am I misunderstanding what the data is telling me? > > yes. acceleration is change of velocity. if there is no change in > velocity, there will be no acceleration. hence, if the phone is still, > all acc values should be zero. gravity or not, there is no net acc on > the phone. i don't know the format the accelerometers output data in, > but i'd take a punt that the values shown are noise. try running one > of the acc scripts on the wiki and going for a walk/run/climbing > steps/waving it around/car ride with it, to see what sort of acc > values you can get for different activities If the Freerunner is not moving (x^2+y^2+z^2)^(1/2) must be g. The values of the freerunner are in mg so it must be 1000. Your values are really strange. Do the x values never change? I would recommend the python script for easy testing: http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval Greets Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
On Thu, Oct 29, 2009 at 11:03 PM, Michal Brzozowski wrote: > 2009/10/29 Laszlo KREKACS >> >> On Thu, Oct 29, 2009 at 3:40 PM, Laszlo KREKACS >> wrote: >> > >> > http://www.amazon.com/gp/bestsellers/electronics/ref=pd_ts_pg_4?ie=UTF8&pg=4 >> >> Just to put this into perspective: >> Amazon Kindle got 7111 customer review while WikiReader 13. > > You'd need to compare for how long each one is being sold. That and it does help to have a front page listing ;-) -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Understanding accelerometer data
> yes. acceleration is change of velocity. if there is no change in > velocity, there will be no acceleration. hence, if the phone is still, > all acc values should be zero. gravity or not, there is no net acc on > the phone. i don't know the format the accelerometers output data in, > but i'd take a punt that the values shown are noise. No. Accelerometers do not measure change in velocity, but change in velocity + gravity. There is no way to build an engine that would distinguish change in velocity from gravity (lookup equivalence gravity/acceleration in wikipedia for some interresting reading). Thus, what you have here is noise added to gravity in the vertical direction. Kindly, ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Understanding accelerometer data
2009/10/29 Michael Tansella : > > If the Freerunner is not moving (x^2+y^2+z^2)^(1/2) must be g. The values of > the freerunner are in mg so it must be 1000. > > Your values are really strange. Do the x values never change? Not never, but they do seem reluctant to change. For example if I lift the end of the FR with the hole in, keeping the side-to-side axis horizontal, I would expect the x and y values of event2 to increase equally, and z to decrease a bit. What I observed was as expected for y and z, but no change in x. > I would recommend the python script for easy testing: > http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval It's certainly possible that I've just written my program wrong. So yes, I'll try that script too. Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
William Kenworthy writes: > On Wed, 2009-10-28 at 22:39 +0100, Petr Vanek wrote: >> On Wed, 28 Oct 2009 21:32:03 + >> Al Johnson (AJ) wrote: >> >> >On Wednesday 28 October 2009, Petr Vanek wrote: >> >> >I meant that it ought to behave that way in future, not that it >> >> >would in the current version. I don't care if the phone goes to >> >> >sleep during the snooze interval so long as the alarm goes off >> >> >again five minutes later! >> >> > >> >> :) sure, now it didn't wake up itself and me neither :)) >> >> >> >> what if the unlocking 1-2-3-4 pattern is configurable, how would >> >> snooze get in then? >> > >> >How about puzzle to stop the sound, display the message and show the >> >ACK slider? If you don't ACK then there's another alarm after the >> >snooze interval. When I implement snoozing (repeating the alarm if not ACK) I consider easy turning off the alarm for the first time (most probably a button), and a puzzle in a snoozed mode (all but first time). >> >> that would do just fine for me, just some people wanted to get rid of >> the puzzle... >> >> Petr >> > > Even without the puzzel, you still need an acknowledge button for the > alarm so thats not a problem. The problem with the puzzel is 4 buttons > with small, unreadable text that have to be pressed in a specific order > when you have just been woken up and are disoriented, cant find your > glasses and your grumpy, just woken up better half is berating you for > the umpteenth time for not being able to turn off the alarm :( The digits could be made bigger. I considered it a feature that until I the digits are blurred means I am not awaken, ie alarm should still play. But the story is of course different when you do not want to wake up the rest of the house. > > BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Thu, 2009-10-29 at 23:52 +0100, Łukasz Pankowski wrote: > William Kenworthy writes: > > > On Wed, 2009-10-28 at 22:39 +0100, Petr Vanek wrote: > >> On Wed, 28 Oct 2009 21:32:03 + > >> Al Johnson (AJ) wrote: > >> > >> >On Wednesday 28 October 2009, Petr Vanek wrote: > >> >> >I meant that it ought to behave that way in future, not that it > >> >> >would in the current version. I don't care if the phone goes to > >> >> >sleep during the snooze interval so long as the alarm goes off > >> >> >again five minutes later! > >> >> > > >> >> :) sure, now it didn't wake up itself and me neither :)) > >> >> > >> >> what if the unlocking 1-2-3-4 pattern is configurable, how would > >> >> snooze get in then? > >> > > >> >How about puzzle to stop the sound, display the message and show the > >> >ACK slider? If you don't ACK then there's another alarm after the > >> >snooze interval. > > When I implement snoozing (repeating the alarm if not ACK) I consider > easy turning off the alarm for the first time (most probably a button), > and a puzzle in a snoozed mode (all but first time). > Now that sounds a good compromise > >> > >> that would do just fine for me, just some people wanted to get rid of > >> the puzzle... > >> > >> Petr > >> > > > > Even without the puzzel, you still need an acknowledge button for the > > alarm so thats not a problem. The problem with the puzzel is 4 buttons > > with small, unreadable text that have to be pressed in a specific order > > when you have just been woken up and are disoriented, cant find your > > glasses and your grumpy, just woken up better half is berating you for > > the umpteenth time for not being able to turn off the alarm :( > > The digits could be made bigger. This would be a big help > > I considered it a feature that until I the digits are blurred means I am > not awaken, ie alarm should still play. But the story is of course > different when you do not want to wake up the rest of the house. > Yes, I am an early riser in a house of late risers - what a pain but at least I get the place to myself - as long as I am quiet Everyones use case is different! The trick is getting it flexible enough to satisfy the majority ;) BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Error on parsing the spanish wikipedia
David We're working on exactly the same thing now :-) I'll ask Chris to email the list once we get past it. I think the problem is with the mixtures of different encodings (latin-1 and UTF-8) in the Spanish Wikipedia and the way our code is handling this. For some reason Python's print (at times) wants to default to ascii, even after we explicitly tell it to use UTF-8. -Sean On Fri, Oct 30, 2009 at 4:50 AM, David Reyes Samblas Martinez wrote: > > Hi I'm trying to generate the file for a spainsh wikipedia on the WR , > after compiling succsesfuly the source on the git and solve some > annoyings with utf8 encoding on phyton error was somthing like this: > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in > position: ordinal not in range(128) > this was solved changing the default encode "ascii" to "utf8" int the > /usr/lib/python2.6/site.py file > after this I was hable to execute ok the instruction: > make DESTDIR=image WORKDIR=work > XML_FILES=xml-file-samples/eswiki-latest-pages-articles.xml index > parse render combine > > Every thing seem fine for a couple(about 6-7h) of hours parsing the > 70 articles in spanish but then ... the horror > Count: 38 > Traceback (most recent call last): > File "./ArticleParser.py", line 224, in > main() > File "./ArticleParser.py", line 172, in main > process_article_text(title.encode('utf-8'), f.read(length), newf) > File "./ArticleParser.py", line 218, in process_article_text > newf.write(text + '\n') > IOError: [Errno 32] Broken pipe > make[1]: *** [parse] Error 1 > make[1]: se sale del directorio > `/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer' > make: *** [parse] Error 2 > > I have relaunched the process again with the (few)hope that was a > temporary fault but If any one has a clue will be helpfull. > > BTW.- I documenting all this proccess to make a step by step howto on > how to put the wikipedia in other languages on the wikireader. > > > > David Reyes Samblas Martinez > http://www.tuxbrain.com > Open ultraportable & embedded solutions > Openmoko, Openpandora, Arduino > Hey, watch out!!! There's a linux in your pocket!!! > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
2009/10/29 Sean Moss-Pultz : > On Thu, Oct 29, 2009 at 11:03 PM, Michal Brzozowski wrote: >> 2009/10/29 Laszlo KREKACS >>> >>> On Thu, Oct 29, 2009 at 3:40 PM, Laszlo KREKACS >>> wrote: >>> > >>> > http://www.amazon.com/gp/bestsellers/electronics/ref=pd_ts_pg_4?ie=UTF8&pg=4 >>> >>> Just to put this into perspective: >>> Amazon Kindle got 7111 customer review while WikiReader 13. >> >> You'd need to compare for how long each one is being sold. > > That and it does help to have a front page listing ;-) > > -Sean > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > So, bagged myself one of these bad boys today and I am equally excited as when I first got my hands on a 1973. Really looking forward to educating myself while I ride the Tube! Keep up the good work! John. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Error on parsing the spanish wikipedia
Great! :) good to see you are working on this!, please count on me for any testing to be done, I will try to make a look on the code myself to kill the bug but no time and nor expertise so no promises :P David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/10/30 Sean Moss-Pultz : > David > > We're working on exactly the same thing now :-) > > I'll ask Chris to email the list once we get past it. I think the > problem is with the mixtures of different encodings (latin-1 and > UTF-8) in the Spanish Wikipedia and the way our code is handling this. > For some reason Python's print (at times) wants to default to ascii, > even after we explicitly tell it to use UTF-8. > > -Sean > > > On Fri, Oct 30, 2009 at 4:50 AM, David Reyes Samblas Martinez > wrote: >> >> Hi I'm trying to generate the file for a spainsh wikipedia on the WR , >> after compiling succsesfuly the source on the git and solve some >> annoyings with utf8 encoding on phyton error was somthing like this: >> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in >> position: ordinal not in range(128) >> this was solved changing the default encode "ascii" to "utf8" int the >> /usr/lib/python2.6/site.py file >> after this I was hable to execute ok the instruction: >> make DESTDIR=image WORKDIR=work >> XML_FILES=xml-file-samples/eswiki-latest-pages-articles.xml index >> parse render combine >> >> Every thing seem fine for a couple(about 6-7h) of hours parsing the >> 70 articles in spanish but then ... the horror >> Count: 38 >> Traceback (most recent call last): >> File "./ArticleParser.py", line 224, in >> main() >> File "./ArticleParser.py", line 172, in main >> process_article_text(title.encode('utf-8'), f.read(length), newf) >> File "./ArticleParser.py", line 218, in process_article_text >> newf.write(text + '\n') >> IOError: [Errno 32] Broken pipe >> make[1]: *** [parse] Error 1 >> make[1]: se sale del directorio >> `/OE/Proyectos/tuxbrain/productos/wikireader/wikireader/host-tools/offline-renderer' >> make: *** [parse] Error 2 >> >> I have relaunched the process again with the (few)hope that was a >> temporary fault but If any one has a clue will be helpfull. >> >> BTW.- I documenting all this proccess to make a step by step howto on >> how to put the wikipedia in other languages on the wikireader. >> >> >> >> David Reyes Samblas Martinez >> http://www.tuxbrain.com >> Open ultraportable & embedded solutions >> Openmoko, Openpandora, Arduino >> Hey, watch out!!! There's a linux in your pocket!!! >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Error on parsing the spanish wikipedia
On Thu, Oct 29, 2009 at 6:54 PM, David Reyes Samblas Martinez wrote: > Great! :) good to see you are working on this!, please count on me for > any testing to be done, I will try to make a look on the code myself > to kill the bug but no time and nor expertise so no promises :P I haven't seen the code but if you don't feel like fixing it now you can add a try/catch on the block that is processing each page so that you have a wiki to play with while the error is fixed. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Understanding accelerometer data
2009/10/29 Neil Jerram : > > It's certainly possible that I've just written my program wrong. So > yes, I'll try that script too. OK, I understand what was wrong with my program now. It was reopening the /dev/input/event[2,3] file before every read. It appears that the first set of readings after opening contains incorrect data, and unfortunately that's what my program was getting every time. My thinking was that I didn't want to use a lot of CPU by reading the files non-stop; hence I'd sleep for a few seconds between each read. But then I thought that I might get out of date data, because of the kernel buffering unread data in the open file object. To avoid that, I decided to open, read and close on every iteration of reading the accelerometer. But I saw while googling that the buffer for these files only holds 64 sets of data - hence if the sample period is 10ms it should only ever be possible to be up to 640ms out of date. So the approach of keeping the file open is fine after all. Thanks for the help! Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 15:38:46 +0100 Bernd Prünster said: > Carsten Haitzler (The Rasterman) wrote: > >> gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, > >> gry* uses a white outline on black text. > >> but thats something thats bugging me. i have to make some tests... > >> > > > > even that can be slow. in this case, the text will be drawn 5 times to > > produce that effect. > > > rater, would you mind to elaborate? (is outline the fastest effect if > you want to enable the user to set a custom background while maintaining > the labels readable?) yes, but it's still 5x slower to draw than no outline. a suggestion: just put a semi-translucent black box under the text and have white test. this will be readable everywhere and be fastest. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] which to use?
2009/10/30 Tony McKeehan : > I was thinking about try SHR again, but I don't know which image I > should use. > > I heard somewhere that there was a mostly-stable image built in October, > but I can't find it anywhere. I have the unstable from early September, > but I thought that there was something more recent than that. from the shr build repo, it looks like the last update to unstable was sept 18th http://build.shr-project.org/shr-unstable/ipk/armv4t/ and that ties in with my recollections of the last update as to which to use, unstable is actually pretty stable. it does phone calls and text messages no problem. i'm pretty happy with it, and the maintainers include new packages (intone, launcher, etc.) fairly quickly there's never been a stable release of shr, but there is a testing release, which is supposedly more stable than unstable, but that's apparently as old as may: http://build.shr-project.org/shr-testing/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
On Fri, Oct 30, 2009 at 7:29 AM, john wrote: > > 2009/10/29 Sean Moss-Pultz : > > On Thu, Oct 29, 2009 at 11:03 PM, Michal Brzozowski > > wrote: > >> 2009/10/29 Laszlo KREKACS > >>> > >>> On Thu, Oct 29, 2009 at 3:40 PM, Laszlo KREKACS > >>> wrote: > >>> > > >>> > http://www.amazon.com/gp/bestsellers/electronics/ref=pd_ts_pg_4?ie=UTF8&pg=4 > >>> > >>> Just to put this into perspective: > >>> Amazon Kindle got 7111 customer review while WikiReader 13. > >> > >> You'd need to compare for how long each one is being sold. > > > > That and it does help to have a front page listing ;-) > > > > -Sean > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > So, bagged myself one of these bad boys today and I am equally excited > as when I first got my hands on a 1973. Really looking forward to > educating myself while I ride the Tube! Keep up the good work! Thanks John. Please let us know what you think when it arrives! -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Error on parsing the spanish wikipedia
On Fri, Oct 30, 2009 at 7:54 AM, David Reyes Samblas Martinez wrote: > Great! :) good to see you are working on this!, please count on me for > any testing to be done, I will try to make a look on the code myself > to kill the bug but no time and nor expertise so no promises :P We'll get it working. Just give us a bit of time. And it would be super helpful if you could help test / QA. Thanks a lot for the offer! -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Error on parsing the spanish wikipedia
On Fri, Oct 30, 2009 at 7:58 AM, Nelson Castillo wrote: > On Thu, Oct 29, 2009 at 6:54 PM, David Reyes Samblas Martinez > wrote: >> Great! :) good to see you are working on this!, please count on me for >> any testing to be done, I will try to make a look on the code myself >> to kill the bug but no time and nor expertise so no promises :P > > I haven't seen the code but if you don't feel like fixing it now you > can add a try/catch on the block that is processing each page so that > you have a wiki to play with while the error is fixed. Yeah we're trying exactly that Nelson. It's just a long process to render all this stuff. We actually have 9 quad-core systems running in parallel now. Each with at least six GB of ram :-) -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher v0.41 - New Release
Hi, Petr Vanek wrote: > > good, good! > Thanks! Petr Vanek wrote: > > it feels very responding, after all data is loaded. (most delays seem > to be caused by waiting for the opimd data). > Actually, the contacts are synced the first time only. The SMS's are typically not that many, but for opimd to go through all the calls, parse them and send them through the dbus really takes long. Since launcher doesn't know if you received calls when it wasn't running, it uses the time of the last call it has in its local db to query for newer calls from opim. Hence the delay. Typically, about 10 - 12 secs. Keeping a smaller log will speed up launcher. I've been thinking of deleting all the calls older than those launcher displays - or some x days automatically. What do you think? Petr Vanek wrote: > > 1) in contacts, all the categories are listed twice (all empty), this > was also the same in .39. > That must be something I'm doing wrong in the db creation. While I solve that issue, you could remove those duplicates (and change them to something more appropriate to yourself) manually by changing the category names in the contacts_cat table. - sqlite .launcher/launcher.db - delete from contacts_cat; (or delete from contacts_cat where category='Family';) - delete from contacts_cat where key = 1; - insert into contacts cat (category) values ('your_new_cat'); I will finish work on the customisation of categories in some time. If you have deleted the old launcher db - you've lost the categorisation of the apps and the contacts. Maybe I need to shift this to another db - so that the working db can be deleted but this data remains. To set categories for the contacts click on set cat. You'll see a list of your contacts. Select a category, select the contacts you want in that category and click 'Set Category' button. The selected contacts will be removed from this list and appear under their category. Petr Vanek wrote: > > 2) opimd fields should probably be configurable > somewhat, now it doesn't show all my fields... or did i miss something? > That's missing. I'm working on it - should be done soon. Thanks for all the feedback. Did you like the the fact that your contacts now show when you contacted them last? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/Launcher-v0-41-New-Release-tp3911066p3917078.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: Gift for c_c
Hi, I've thought of doing something similar. The only problem I face is creating the edje files. But :- 1. If we're looking at going the edje way - which does give far better layout options (something I had thought about for intone anyway) it would be better if intone's look could be overhauled. What I mean is, for eg - we could have rounded buttons (play/pause), simple animation for sliding out the vol control etc. My thinking is that since the core seems fairly stable (need to add reporting mplayer errors though) - the gui can go through a transformation. We could get more feedback from other users too (even as the gui develops). I could give you (or anybody else who's interested) write access to the svn - that will help the dev process and make it faster. The only reason I haven't moved to edc files is my limitation with the layout. Your help (or anyone else's) will be welcome in improving the user experience. 2. I'll look at implementing the mplayer error reporting part soon. That's something that causes most of the remining hangs (if they do occur) - since right now intone doesn't respond to mplayer crashing / hanging / getting killed. And this is a drawback. The right behaviour should be to pause, tell the user something, re-start mplayer and continue playing from where the error occurred or move on to the next song. 3. Then - I will add the auto-scrolling feature for karaoke. What do you think? -- View this message in context: http://n2.nabble.com/Gift-for-c-c-tp3911968p3917118.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