Re: Launcher v0.41 - New Release
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?
if the number of days is configurable (possible to set to unlimited),
this would be very good.
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.
ok
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?
couldn't enjoy this one yet, from home i have to call from a gsm gate,
there is no signal inside my house... but will test this afternoon or
on the weekend,
thanks for all the great work and time! :)
Petr
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Am Mittwoch, den 28.10.2009, 09:36 -0400 schrieb Ken Young: Personally, I wish OM had stayed with the UI they had in 2007.1. That's right, 2007.1 - the first version, which had no kinetic scrolling. There was never any chance that OM would produce a phone with graphics as smooth and fancy as what a high-volume smart phone has. You have a very valid points here. We certainly did some strategic mistakes here -- me included, since I did not realize the awesomeness and importance of dbus early enough... it's not too late though for us (as in the community) to fix this. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
2009/10/29 Ken Young r...@cfa.harvard.edu: 2) The Freerunner has one, and ONLY ONE, feature which is somewhat better than what is found on a typical smart phone. The VGA display. no. you're right, the fr has one feature better than any other smartphone, but it's not the screen. it's not any of the hardware, it's far more important than that it's the openness give the user a choice, let them decide if they want pixels or speed. that's what open is about ___ 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/30 Sean Moss-Pultz s...@openmoko.com: On Fri, Oct 30, 2009 at 7:29 AM, john jptmo...@gmail.com wrote: 2009/10/29 Sean Moss-Pultz s...@openmoko.com: On Thu, Oct 29, 2009 at 11:03 PM, Michal Brzozowski ruso...@poczta.fm wrote: 2009/10/29 Laszlo KREKACS laszlo.krekacs.l...@gmail.com On Thu, Oct 29, 2009 at 3:40 PM, Laszlo KREKACS laszlo.krekacs.l...@gmail.com wrote: http://www.amazon.com/gp/bestsellers/electronics/ref=pd_ts_pg_4?ie=UTF8pg=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 I received it already I meant to say. Very impressed! I am going to see if I can setup some offline mobile learning experiments at a couple of Uni's here in London. John. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher v0.41 - New Release
On Fri, Oct 30, 2009 at 3:09 AM, Petr Vanek van...@penguin.cz 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? if the number of days is configurable (possible to set to unlimited), this would be very good. +1 for configurable number of days for the logs Did you like the the fact that your contacts now show when you contacted them last? Yes I like the fact that it shows when and how you contacted someone last, I have found this feature very useful already thank you for adding it! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
2009/10/29 William Kenworthy bi...@iinet.net.au: On Thu, 2009-10-29 at 23:52 +0100, Łukasz Pankowski wrote: new ffalarms ive been using a recurring alarm all week with no issue. around tuesday i found that you can set the days of the week in the alarm. this was after i had already made the alarm so i figured i would let it be. today i deleted the recurring alarm as soon as the delete was acknowledged ffalarms seg'ed. now running ffalarms seg's r...@om-gta02 ~ $ ffalarms icalerror.c:99: BADARG: Bad argument to function ffalarms: icalerror.c:100: icalerror_set_errno: Assertion `0' failed. Aborted r...@om-gta02 ~ $ any ideas? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Congratulation, Wikireader! 7th in Amazon TOP 100
-Sean On Fri, Oct 30, 2009 at 6:50 PM, john jptmo...@gmail.com wrote: 2009/10/30 Sean Moss-Pultz s...@openmoko.com: On Fri, Oct 30, 2009 at 7:29 AM, john jptmo...@gmail.com wrote: 2009/10/29 Sean Moss-Pultz s...@openmoko.com: On Thu, Oct 29, 2009 at 11:03 PM, Michal Brzozowski ruso...@poczta.fm wrote: 2009/10/29 Laszlo KREKACS laszlo.krekacs.l...@gmail.com On Thu, Oct 29, 2009 at 3:40 PM, Laszlo KREKACS laszlo.krekacs.l...@gmail.com wrote: http://www.amazon.com/gp/bestsellers/electronics/ref=pd_ts_pg_4?ie=UTF8pg=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! I received it already I meant to say. Very impressed! I am going to see if I can setup some offline mobile learning experiments at a couple of Uni's here in London. Awesome. This is something we'd love to see! -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 4:50 AM, David Reyes Samblas Martinez
da...@tuxbrain.com 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 module
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
OK that's fixed now. Chris already checked in the code. Our build
worked fine. We need to do a few more tweaks and then we can post a
(super) early test image. Give us until early this coming week.
-Sean
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
r...@om-gta02 ~ $ ffalarms icalerror.c:99: BADARG: Bad argument to function ffalarms: icalerror.c:100: icalerror_set_errno: Assertion `0' failed. Aborted r...@om-gta02 ~ $ any ideas? It happened to me as well...and its probably you have got an empty .ffalarms/alarms file in your home directory. Just delete the file and the app would come up again. I was about to report it...I guess empty file should be handled gracefully --Vikas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Michael 'Mickey' Lauer schrieb: , since I did not realize the awesomeness and importance of dbus early enough... it's not too late though for us (as in the community) to fix this. when i understand you right, you think, the dbus concept is wrong ? and if so, could you please explain deeper, why you think so ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[wikireader]Suggestions for next steps on software
Though on how the evolution of the soft of the wikireader must be, I have oredered the sugesstions by impact on functionality/easy to implement ratio, of course under a totally non-hardcore developer and only-one-week user criteria. *First and prioritary, allow have multiple languages on same sdcard, I think a one easy approach is to have a selection menu on boot with the available languages on the sdcard (looking at the sufix of the pedia files pedia_es, pedia_de, pedia_pt. ) present a bare text menu with the items, select, and then operate as usual. More complex things like changing of language inside a topic or include non wikipedia content to that menu using a config file can be implemented later on. *Second adaptation of the keyboard for internationalization, I suggest ,as quick fix, the introduction of a third keyboard screen with the special chars like ñ, ç, ... add here the common chars on other european languages, to simplify not include accentuated vocals and consonants , when searching a word you will select the correct accentuated one on the list. Cirilic, chinese, japanese, arabic and other completly diferent alphabets is a full redo of the keyboard, there are important to have in but I don't describe his implementation and be selectable as quickfix... *Third Use long press of the buttons search, and history to: long press on search = launch other apps, present a menu (loaded from a config file to launch apps like the calculator(calc.elf file included in the sdcard)and the multiple apps people will start to develop on this platform, (note taking app will be helpful for example) I think change the behavior of the history short press as back is more useful than actual one, and on long Press present a menu to back/forward/view history/change content menu Random is funny as it is please dont touch :) *Forth: Include images , I know this will increase a lot both the space on sdcard and cpu load of the device, but they can be implemented as link(pic) in the main content and once clicked open them at full screen , and pressing the history(back) button and return to content , same aproach with formulas. zoom in/out maybe aviable from a long press on the screen with a pop up menu, a fixed scales and max image size has to be defined on what the device can handle. of course this image strored in the sd are b/w bitmaps, the host is the responsable of make the render of the original ones to this format. Maybe formulas can be rendered on the device if they are stored in latex on the wikipedia and the Wikireade can handle this or has to be redered as images on the host it it can't be done. What do you think about? 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: ffalarms 0.3 -- recurring alarms
On Fri, Oct 30, 2009 at 8:14 AM, Vikas Saurabh vikas.saur...@gmail.com wrote: I was about to report it...I guess empty file should be handled gracefully --Vikas thanks, that did it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Error on parsing the spanish wikipedia
Are you uploading this changes to git? can I take a look?
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 s...@openmoko.com:
On Fri, Oct 30, 2009 at 4:50 AM, David Reyes Samblas Martinez
da...@tuxbrain.com 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 module
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
OK that's fixed now. Chris already checked in the code. Our build
worked fine. We need to do a few more tweaks and then we can post a
(super) early test image. Give us until early this coming week.
-Sean
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Gift for c_c
On Fri, Oct 30, 2009 at 5:44 AM, c_c cchan...@yahoo.com wrote: 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. I agree. Completely alternative displays could be implement as simple .edj themes. What I mean is, for eg - we could have rounded buttons (play/pause), simple animation for sliding out the vol control etc. We can play with it yes. However I cant imagine what you mean under simple animation for sliding out the vol control. 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. We can go with an incremental approach. So no need to implement all at once, but develop always a little. If you implement what I posted above, we are already at the .edje theme. So no extra voodoo is required, we can replace other elements with our custom design step by step. So the first step is definietly implementing elementary layout. 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. Seems an important feature. 3. Then - I will add the auto-scrolling feature for karaoke. I think it can be the first step, as it is only a minor programing challenge, and only requires elementary layout, which is required anyway. What do you think? I can help you, yes. BUT, I was never able to compile anything for the freerunner, I could not modify any program which was written in C. So unless someone can invest time to teaching me for compiling, developing setup for C, Im unable to help in the programmic part, basically because, I cant touch the code. And I also lack C knowledge. I only can code in python and I know a little elementary/edje programming (embryo scripting). (Btw, I dont really understand why programming in C is required in intone, as all the speed critical part is provided by third party (mplayer, enlightenment). Besides intone does not launch fast. It launches 6 sec for me on the freerunner, while my own python program launch 6 sec too. So no speed improvements either. Im not campaigning for python or anything, just dont know the main motivation. Python is definietly easier, and development cycle is much shorter (no compilation required). If you are willing spend on me multiple days on irc, then I can involve more into intone, if not I can provide example codes for specific feature. Thats my offer;-) Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Fri, 2009-10-30 at 16:18 +0100, Matthias Huber wrote: Michael 'Mickey' Lauer schrieb: , since I did not realize the awesomeness and importance of dbus early enough... it's not too late though for us (as in the community) to fix this. when i understand you right, you think, the dbus concept is wrong ? and if so, could you please explain deeper, why you think so ? I think it's just the reverse: he saw too late that dbus is really good. Xav ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[wikireader]Developer Kernel-2009.10-27 doesn't boot
the tweetered kernel with kinetic movement and increased touchscreen sensibility http://cloud.github.com/downloads/wikireader/wikireader/kernel-2009-10-27.zip I have unziped it and copy to the sd card replacing the(backuped :P) original kernel and the device doesn't boot (at least in 10 minutes after seeing the Wikireader splash screen i decided is not booting) 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: [wikireader]Error on parsing the spanish wikipedia
On Fri, Oct 30, 2009 at 4:22 PM, David Reyes Samblas Martinez da...@tuxbrain.com wrote: Are you uploading this changes to git? can I take a look? Btw is there any plan to implement images rendering? If so, any time estimation? Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher v0.41 - New Release
hi is it possible to define launcher as the default desktop application (ie making it disappear from the task list)? it's kind of annoying using it as an application ... -- Gand' On Fri, Oct 30, 2009 at 1:48 PM, Adam Jimerson vend...@gmail.com wrote: On Fri, Oct 30, 2009 at 3:09 AM, Petr Vanek van...@penguin.cz 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? if the number of days is configurable (possible to set to unlimited), this would be very good. +1 for configurable number of days for the logs Did you like the the fact that your contacts now show when you contacted them last? Yes I like the fact that it shows when and how you contacted someone last, I have found this feature very useful already thank you for adding 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: Centralization of graphical awesomeness
You have a very valid points here. We certainly did some strategic mistakes here -- me included, since I did not realize the awesomeness and importance of dbus early enough... How lucky you are ! I still wonder why dbus was invented in the first place :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Suggestions for next steps on software
David Reyes Samblas Martinez wrote: Though on how the evolution of the soft of the wikireader must be, I have oredered the sugesstions by impact on functionality/easy to implement ratio, of course under a totally non-hardcore developer and only-one-week user criteria. *First and prioritary, allow have multiple languages on same sdcard, I think a one easy approach is to have a selection menu on boot with the available languages on the sdcard (looking at the sufix of the pedia files pedia_es, pedia_de, pedia_pt. ) present a bare text menu with the items, select, and then operate as usual. More complex things like changing of language inside a topic or include non wikipedia content to that menu using a config file can be implemented later on. I notice that the current implementation fits within the old 8.3 DOS file naming scheme (except that both upper case and lower case is used). Is this done to avoid the FAT patent issue? If so, then we need to devise a naming scheme that fits within that... perhaps something like llnn.ext where: indicates which wiki ll indicates which language nn indicates which alphabetical section (I assume the articles are grouped according to first letter, 00 through 26 for A-Z and other characters... or is this wrong?) Other alphabets have different numbers of letters, so do we sometimes need more than two digits? And some languages don't use alphabets... has somebody already worked out a general scheme for breaking up the files, and is this documented somewhere? We have to break up the data into chunks somehow. FAT has a 4GB file limit, as I recall... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher v0.41 - New Release
On 10/30/09, Gand' gand...@viroenforce.com wrote: hi is it possible to define launcher as the default desktop application (ie making it disappear from the task list)? it's kind of annoying using it as an application ... -- Gand' On Fri, Oct 30, 2009 at 1:48 PM, Adam Jimerson vend...@gmail.com wrote: On Fri, Oct 30, 2009 at 3:09 AM, Petr Vanek van...@penguin.cz 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? if the number of days is configurable (possible to set to unlimited), this would be very good. +1 for configurable number of days for the logs Did you like the the fact that your contacts now show when you contacted them last? Yes I like the fact that it shows when and how you contacted someone last, I have found this feature very useful already thank you for adding it! It should be possible. Launcher has to obtain X root window, just like openmoko-today2 was doing (someone reported recently that it works with Illume) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher v0.41 - New Release
On Friday 30 October 2009, Gand' wrote: hi is it possible to define launcher as the default desktop application (ie making it disappear from the task list)? it's kind of annoying using it as an application ... Not without modifying or rewriting illume. It doesn't have a default desktop app. Raster started work on illume2 which might handle this, but it's on the back burner. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Suggestions for next steps on software
Hi .. I'm not sure if it has been mentioned - didnt follow all the buzz on the list .. .. and it's not a software update .. .. but I initially expected Wikireader to have GPS onboard and simply tell you about your surroundings. There are 1000s of GPS annotated entries on Wikipedia ? I see all those 'W' links in Google maps. A perfect travelguide. WikiTravelMate. $2c, *-pike ___ 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)
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. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher v0.41 - New Release
On Friday 30 October 2009, Sebastian Krzyszkowiak wrote: On 10/30/09, Gand' gand...@viroenforce.com wrote: hi is it possible to define launcher as the default desktop application (ie making it disappear from the task list)? it's kind of annoying using it as an application ... -- Gand' On Fri, Oct 30, 2009 at 1:48 PM, Adam Jimerson vend...@gmail.com wrote: On Fri, Oct 30, 2009 at 3:09 AM, Petr Vanek van...@penguin.cz 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? if the number of days is configurable (possible to set to unlimited), this would be very good. +1 for configurable number of days for the logs Did you like the the fact that your contacts now show when you contacted them last? Yes I like the fact that it shows when and how you contacted someone last, I have found this feature very useful already thank you for adding it! It should be possible. Launcher has to obtain X root window, just like openmoko-today2 was doing (someone reported recently that it works with Illume) Interesting - I didn't know that would work with illume. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher v0.41 - New Release
and how should that be done ? -- Gand' On Fri, Oct 30, 2009 at 5:27 PM, Al Johnson openm...@mazikeen.demon.co.ukwrote: On Friday 30 October 2009, Sebastian Krzyszkowiak wrote: On 10/30/09, Gand' gand...@viroenforce.com wrote: hi is it possible to define launcher as the default desktop application (ie making it disappear from the task list)? it's kind of annoying using it as an application ... -- Gand' On Fri, Oct 30, 2009 at 1:48 PM, Adam Jimerson vend...@gmail.com wrote: On Fri, Oct 30, 2009 at 3:09 AM, Petr Vanek van...@penguin.cz 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? if the number of days is configurable (possible to set to unlimited), this would be very good. +1 for configurable number of days for the logs Did you like the the fact that your contacts now show when you contacted them last? Yes I like the fact that it shows when and how you contacted someone last, I have found this feature very useful already thank you for adding it! It should be possible. Launcher has to obtain X root window, just like openmoko-today2 was doing (someone reported recently that it works with Illume) Interesting - I didn't know that would work with illume. ___ 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: Centralization of graphical awesomeness
Am Freitag, den 30.10.2009, 16:36 +0100 schrieb ri...@happyleptic.org: You have a very valid points here. We certainly did some strategic mistakes here -- me included, since I did not realize the awesomeness and importance of dbus early enough... How lucky you are ! I still wonder why dbus was invented in the first place :-) Hehe, coming from a strong background in CORBA on one hand, but pure bare-metal unix domain socket IPC on the other hand, I have to admit that while dbus lacks a lot, it * (pretty much) ends the horror of proprietary IPC protocols, thus * enabling interconnecting components, hence * bringing interoperability. * It also comes with an interactive scripting console (read: Python). And that's what I'm all glad for. But now we went really off topic considering the original thread :) :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher v0.41 - New Release
Sebastian Krzyszkowiak wrote: It should be possible. Launcher has to obtain X root window, just like openmoko-today2 was doing (someone reported recently that it works with Illume) c_c try ELM_WIN_DESKTOP instead of ELM_WIN_BASIC. there is even a screenie of openmoko-today as root window on scap (i hope the info i got helps, but when i made that screenie my system was already lost, because of all the stuff from scaredycat repo i needed for openmoko-today2) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko - /opt/qtmoko/bin/lan-network
Hello, On Wed, Sep 23, 2009 at 11:10 PM, Torfinn Ingolfsen tin...@gmail.comwrote: Here is another: If you runt WPA-PSK with AES you will get this output from the script: + . /root/Settings/Network/wireless/eth0 + WIRELESS_ESSID=kg4 + WIRELESS_AUTH_MODE=WPA-PSK + WIRELESS_WPA_PSK=j85first + WIRELESS_PAIRWISE=CCMP TKIP /root/Settings/Network/wireless/eth0: 1: TKIP: not found + WIRELESS_GROUP=CCMP TKIP /root/Settings/Network/wireless/eth0: 1: TKIP: not found To fix that, change lines 277 and 278 into: echo WIRELESS_PAIRWISE=\CCMP TKIP\ $TMP_FILE; echo WIRELESS_GROUP=\CCMP TKIP\ $TMP_FILE; It seems these two fixes aren't in the lan-network script used in QtMoko v14. Perhaps it should be fixed? -- Regards, Torfinn Ingolfsen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gift for c_c
Hi, Laszlo KREKACS wrote: However I cant imagine what you mean under simple animation for sliding out the vol control. I meant that we could have something like the illume slipshelf on the right side of the screen that slides in and shows the volume control and then hides itself when not in use after 2 secs or so. Laszlo KREKACS wrote: So the first step is definietly implementing elementary layout. Yup. Laszlo KREKACS wrote: 3. Then - I will add the auto-scrolling feature for karaoke. I think it can be the first step, as it is only a minor programing challenge, and only requires elementary layout, which is required anyway. I agree. Laszlo KREKACS wrote: And I also lack C knowledge. I only can code in python and I know a little elementary/edje programming (embryo scripting). I can help - lets set up something for next weekend if you're keen. Laszlo KREKACS wrote: (Btw, I dont really understand why programming in C is required in intone, as all the speed critical part is provided by third party (mplayer, enlightenment). Besides intone does not launch fast. It launches 6 sec for me on the freerunner, while my own python program launch 6 sec too. So no speed improvements either. There are a number of advantages to C that I can think of, the main ones being speed and smaller memory requirements. The launching speed is not the best benchmark since intone :- 1. checks for mplayer's presence 2. restores its state from a db 3. modprobes snd-pcm-oss 4. creates the fifo files to control mplayer 5. checks for zombie mplayer processes 6. kills them 7. starts up mplayer 8. renices it 9. starts a thread for the dbus calls before the window is created. I guess I could reduce the window showing time - it's just not been that much of an issue. Try playing an ogg file in the background (~50% cpu) with a reasonably long playlist that needs scrolling and see what happens when you scroll if the frontend is in python. I do agree about the easier part and the dev cycle being shorter in python. Anyhow, if you can help me with the edc files - I can write the code. And if you can help with the code - even better :-) -- View this message in context: http://n2.nabble.com/Gift-for-c-c-tp3911968p3920389.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: Launcher v0.41 - New Release
Hi, Jesus McCloud wrote: c_c try ELM_WIN_DESKTOP instead of ELM_WIN_BASIC. Ok. I tried it - doesn't seem to make any diff. What am I looking out for? -- View this message in context: http://n2.nabble.com/Launcher-v0-41-New-Release-tp3911066p3920434.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: [wikireader]Suggestions for next steps on software
Doug Jones wrote: David Reyes Samblas Martinez wrote: Though on how the evolution of the soft of the wikireader must be, I have oredered the sugesstions by impact on functionality/easy to implement ratio, of course under a totally non-hardcore developer and only-one-week user criteria. *First and prioritary, allow have multiple languages on same sdcard, I think a one easy approach is to have a selection menu on boot with the available languages on the sdcard (looking at the sufix of the pedia files pedia_es, pedia_de, pedia_pt. ) present a bare text menu with the items, select, and then operate as usual. More complex things like changing of language inside a topic or include non wikipedia content to that menu using a config file can be implemented later on. I notice that the current implementation fits within the old 8.3 DOS file naming scheme (except that both upper case and lower case is used). Is this done to avoid the FAT patent issue? If so, then we need to devise a naming scheme that fits within that... perhaps something like llnn.ext where: indicates which wiki ll indicates which language nn indicates which alphabetical section (I assume the articles are grouped according to first letter, 00 through 26 for A-Z and other characters... or is this wrong?) Other alphabets have different numbers of letters, so do we sometimes need more than two digits? And some languages don't use alphabets... has somebody already worked out a general scheme for breaking up the files, and is this documented somewhere? We have to break up the data into chunks somehow. FAT has a 4GB file limit, as I recall... Actually it seems a bit more complicated than this. The language designations used within Wikipedia are not just limited to two characters -- these aren't just country codes. Most languages there are designated by a two-letter code, but some are three letters, and go all the way up to simple for simple English and cbk-zam for Chavacano de Zamboanga. Clearly we should be aiming for a system that can accommodate all available versions of Wikipedia, as well as those yet to be implemented. The current implementation uses a flat directory structure, with no subdirectories. Is there some compelling reason for this? We could put each separate wiki into its own directory. This would make it much easier to fit everything within the 8.3 naming scheme (assuming that this scheme really is a requirement). It would also make it easier for the user to copy a new wiki onto the card; they just have to copy one folder, instead of keeping track of dozens of files. This would also eliminate the need for a config file at the root that would need to be updated as wikis are added or removed. Instead, the boot code scans the root, finds all the directories, looks inside each one for a short metadata file that contains the description for that wiki (in the appropriate language of course), and then uses that data to build the first menu that the user sees. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR-U] process priority
I just noticed that framework is running with niceness 0 (while enlightenment is running with -10). Can this be the reason that sometimes it takes a long time for calls to respond? (one can easily observe UI freezes on litephone when disconnecting a call). It a wild hunch, but I can't really test it as I don't have a spare phone to call and test the theory. --Vikas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher v0.41 - New Release
c_c wrote: Mario Huelsegge wrote: Hi, i just tried out the launcher, and the contacts application seems to have problems with opimd tel. number fields different from phone. Programs like opimd-contacts and pisi sync use names like Home phone and Cell phone. Can you give me more specific examples of the field types? The standard field was supposed to be tel:number. Just point me how it is in other apps and I'll modify launcher to support those. opimd_cli e.g. gives me this output (contacts synced with pisi from evolution): Surname: xx Name: xx E-mail: xx Path: /org/freesmartphone/PIM/Contacts/0 Cell phone: tel:0157xx Home phone: tel:05xx only if a field is called Phone instead of Cell phone or Home phone it is recognised by launcher -- View this message in context: http://n2.nabble.com/Launcher-v0-41-New-Release-tp3911066p3920505.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: QtMoko - WiFi - only one WLAN?
Hi, On Wed, Sep 30, 2009 at 3:01 PM, Torfinn Ingolfsen tin...@gmail.com wrote: When I go To Settings, Internet, it lists these are the network services... First I had one wireless defined, named Wireless home. This one works nicely, after I got it working. :-) It normally shows up as offline, and I can select WLAN detection from the menu (in addition to properties and so on). I defined another, named WLAN, but this only shows up as Unavailable. and on the menu for that I only have New, Delete and Properties. 1) why doesn't it work? (it is configured exactly the same as the other, except for the name) 2) why doesn't WLAN detection show up on the menu? Nobody knows? -- Regards, Torfinn Ingolfsen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko - WiFi - ease of use?
Hello again, On Wed, Sep 30, 2009 at 2:35 PM, Torfinn Ingolfsen tin...@gmail.com wrote: Ok, so now WiFi works - great. (still on QrMoko v11, I hope to upgrde to v12 before Radek releases again). And when I am at home and the Neo is connected to my own wireless network it is truly great. Scan seems to work (WLAN Detection), but I have to select Add Networks afterward, results (of the scan) doesn't show up automatically. However, the list of new networks doesn't indicate if the networks are encrypted or open. And if I try to connect to a network, the connection will just fail if the network is encrypted, without even asking me fro a passphrase. If I go into the wireless encryption screen, all the new networks show up as open (even when they are encrypted) Seriously, It can't be supposed to work like this, that I have to know every detail about a network I want to connect to? As long as I have the correct passphrase, the WLAN program in QtMoko should figure out the rest of the technical details. So, is ther an easier way? Something that works like NetworkManager in Ubuntu perhpas? The silence seems to indicate that there isn't a usable tool for QtMoko when it comes to easily connect to any wireless network from the gui when I am out and about. Any hints to the comtrary would be nice... -- Torfinn Ingolfsen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Suggestions for next steps on software
2009/10/30 Doug Jones dj...@frombob.to: Doug Jones wrote: David Reyes Samblas Martinez wrote: Though on how the evolution of the soft of the wikireader must be, I have oredered the sugesstions by impact on functionality/easy to implement ratio, of course under a totally non-hardcore developer and only-one-week user criteria. *First and prioritary, allow have multiple languages on same sdcard, I think a one easy approach is to have a selection menu on boot with the available languages on the sdcard (looking at the sufix of the pedia files pedia_es, pedia_de, pedia_pt. ) present a bare text menu with the items, select, and then operate as usual. More complex things like changing of language inside a topic or include non wikipedia content to that menu using a config file can be implemented later on. I notice that the current implementation fits within the old 8.3 DOS file naming scheme (except that both upper case and lower case is used). Is this done to avoid the FAT patent issue? If so, then we need to devise a naming scheme that fits within that... perhaps something like llnn.ext where: indicates which wiki ll indicates which language nn indicates which alphabetical section (I assume the articles are grouped according to first letter, 00 through 26 for A-Z and other characters... or is this wrong?) Other alphabets have different numbers of letters, so do we sometimes need more than two digits? And some languages don't use alphabets... has somebody already worked out a general scheme for breaking up the files, and is this documented somewhere? We have to break up the data into chunks somehow. FAT has a 4GB file limit, as I recall... Actually it seems a bit more complicated than this. The language designations used within Wikipedia are not just limited to two characters -- these aren't just country codes. Most languages there are designated by a two-letter code, but some are three letters, and go all the way up to simple for simple English and cbk-zam for Chavacano de Zamboanga. Clearly we should be aiming for a system that can accommodate all available versions of Wikipedia, as well as those yet to be implemented. The current implementation uses a flat directory structure, with no subdirectories. Is there some compelling reason for this? We could put each separate wiki into its own directory. This would make it much easier to fit everything within the 8.3 naming scheme (assuming that this scheme really is a requirement). It would also make it easier for the user to copy a new wiki onto the card; they just have to copy one folder, instead of keeping track of dozens of files. This would also eliminate the need for a config file at the root that would need to be updated as wikis are added or removed. Instead, the boot code scans the root, finds all the directories, looks inside each one for a short metadata file that contains the description for that wiki (in the appropriate language of course), and then uses that data to build the first menu that the user sees. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I like this approach, just remind that as far I see the code and by comments of the devs, the kernel implements the bare just enough to read files, so I think directories are not implemented at all that's why all is on root directory so at least basic hierarchical filesystem has to be implemented before we can do this solution. But directories will easy the organization of pictures too ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Suggestions for next steps on software
.. but I initially expected Wikireader to have GPS onboard and simply tell you about your surroundings. There are 1000s of GPS annotated entries on Wikipedia ? I see all those 'W' links in Google maps. A perfect travelguide. WikiTravelMate. Hi ! I'm starting a project like this next week for the freerunner ;) Stay tuned ;) $2c, *-pike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- -- Openmoko phone gui : http://www.qalee.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko - FBreader?
Ok, I have installed FBreader (with apt--get). Now, How do I get an icon / menu entry to start it from on my QtMoko v14 dektop? -- Regards, Torfinn Ingolfsen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Error on parsing the spanish wikipedia
just an think I realized , all faulty articles the title starts with
the ~ simbol
regards
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable embedded solutions
Openmoko, Openpandora, Arduino
Hey, watch out!!! There's a linux in your pocket!!!
2009/10/30 David Reyes Samblas Martinez da...@tuxbrain.com:
Are you uploading this changes to git? can I take a look?
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 s...@openmoko.com:
On Fri, Oct 30, 2009 at 4:50 AM, David Reyes Samblas Martinez
da...@tuxbrain.com 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 module
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
OK that's fixed now. Chris already checked in the code. Our build
worked fine. We need to do a few more tweaks and then we can post a
(super) early test image. Give us until early this coming week.
-Sean
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Laszlo KREKACS schrieb: 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. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Error on parsing the spanish wikipedia
2009/10/30 Laszlo KREKACS laszlo.krekacs.l...@gmail.com: On Fri, Oct 30, 2009 at 4:22 PM, David Reyes Samblas Martinez da...@tuxbrain.com wrote: Are you uploading this changes to git? can I take a look? Btw is there any plan to implement images rendering? If so, any time estimation? Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Some kind of renderer has been already implemented because keyboard, and the erase history dialog are images . I'm wrong? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
SHR-U wifi problem!!
I flashed my freerunner with shr-u, did an opkg upgrade now when i try connecting to wifi it hangs, stops responding... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-U wifi problem!!
i use mokonet to connect On Sat, Oct 31, 2009 at 1:00 AM, Aditya Gandhi aditya...@gmail.com wrote: I flashed my freerunner with shr-u, did an opkg upgrade now when i try connecting to wifi it hangs, stops responding... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[WikiReader] file system questions (was: [wikireader]Suggestions for next steps on software)
[snip] I like this approach, just remind that as far I see the code and by comments of the devs, the kernel implements the bare just enough to read files, so I think directories are not implemented at all that's why all is on root directory so at least basic hierarchical filesystem has to be implemented before we can do this solution. But directories will easy the organization of pictures too Good point. So two important questions to be answered, before we get any further into this: (1) Has OpenMoko made the policy decision that filenames will be limited to 8.3? (2) How complicated will it be to implement subdirectory support? Note that only one subdirectory level is really needed to implement what has already been suggested. The current implementation contains 81 files, totaling 4.2GB for the English version. Nearly all of that is in the big wiki data files (pedia*). The other files, the ones you get when you make install, comprise 49 files and only 18MB, and most of that is fonts (which are often different for different languages). We could adopt a brain-swap approach: After bootup, the user selects one wiki and then the app switches to the selected subdirectory and considers that to be the root until the next cold boot. All 81 files for that particular wiki and language would be in that subdirectory, including the big wiki data files and the fonts and the remaining files (45 files, only 381KB, and this includes ALL of the executables!) While the single app is running, it would not have to access (or even know about) anything outside its current directory, so no filesystem calls relating to directory navigation would be needed within that particular kernel.elf. Only the initial wiki selection app (we would have to write one) would have to understand subdirectories, and only to one level deep. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[wikireader]Error on ArticleParsing.py
Man, you forget a , in line 49 on host-tools/offline-renderer/ArticleParser.py
(re.compile(r'amp;([a-zA-Z]{2,8});', re.IGNORECASE), r'\1;'),---Here!
# change % so php: wr_parser does not convert them
(re.compile(r'%', re.IGNORECASE), r'%25')
Regards
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable embedded solutions
Openmoko, Openpandora, Arduino
Hey, watch out!!! There's a linux in your pocket!!!
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-U wifi problem!!
Aditya Gandhi schrieb: i use mokonet to connect On Sat, Oct 31, 2009 at 1:00 AM, Aditya Gandhi aditya...@gmail.com mailto:aditya...@gmail.com wrote: I flashed my freerunner with shr-u, did an opkg upgrade now when i try connecting to wifi it hangs, stops responding... strange. is it reproducable (with reboot) ? i have something in mind with encryption problems of mokonnect (did you mean them ?) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] file system questions (was: [wikireader]Suggestions for next steps on software)
2009/10/30 Doug Jones dj...@frombob.to: [snip] I like this approach, just remind that as far I see the code and by comments of the devs, the kernel implements the bare just enough to read files, so I think directories are not implemented at all that's why all is on root directory so at least basic hierarchical filesystem has to be implemented before we can do this solution. But directories will easy the organization of pictures too Good point. So two important questions to be answered, before we get any further into this: (1) Has OpenMoko made the policy decision that filenames will be limited to 8.3? (2) How complicated will it be to implement subdirectory support? Note that only one subdirectory level is really needed to implement what has already been suggested. The current implementation contains 81 files, totaling 4.2GB for the English version. Nearly all of that is in the big wiki data files (pedia*). The other files, the ones you get when you make install, comprise 49 files and only 18MB, and most of that is fonts (which are often different for different languages). We could adopt a brain-swap approach: After bootup, the user selects one wiki and then the app switches to the selected subdirectory and considers that to be the root until the next cold boot. All 81 files for that particular wiki and language would be in that subdirectory, including the big wiki data files and the fonts and the remaining files (45 files, only 381KB, and this includes ALL of the executables!) While the single app is running, it would not have to access (or even know about) anything outside its current directory, so no filesystem calls relating to directory navigation would be needed within that particular kernel.elf. Only the initial wiki selection app (we would have to write one) would have to understand subdirectories, and only to one level deep. mmm this aproach will not complicate too much if after more apps than a reader are implemented? It would not be better to have a even a one level dir fs? nevertheless you will implement it for the starting menu, why not do it directly in the kernel and allow other apps take advantage of this implementation? Again talking from the most totally inexperience. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community 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: SHR-U wifi problem!!
I dont know about encryption problems And its recursive even after reboot The aux buttin red led starts blinking after about 5-10 secs On Sat, Oct 31, 2009 at 1:35 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: Aditya Gandhi schrieb: i use mokonet to connect On Sat, Oct 31, 2009 at 1:00 AM, Aditya Gandhi aditya...@gmail.comwrote: I flashed my freerunner with shr-u, did an opkg upgrade now when i try connecting to wifi it hangs, stops responding... strange. is it reproducable (with reboot) ? i have something in mind with encryption problems of mokonnect (did you mean them ?) ___ 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: SHR-U wifi problem!!
I did a reinstall using usbnet still the same problem On Sat, Oct 31, 2009 at 1:46 AM, Aditya Gandhi aditya...@gmail.com wrote: I dont know about encryption problems And its recursive even after reboot The aux buttin red led starts blinking after about 5-10 secs On Sat, Oct 31, 2009 at 1:35 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: Aditya Gandhi schrieb: i use mokonet to connect On Sat, Oct 31, 2009 at 1:00 AM, Aditya Gandhi aditya...@gmail.comwrote: I flashed my freerunner with shr-u, did an opkg upgrade now when i try connecting to wifi it hangs, stops responding... strange. is it reproducable (with reboot) ? i have something in mind with encryption problems of mokonnect (did you mean them ?) ___ 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]Suggestions for next steps on software
Hi, David Reyes Samblas Martinez da...@tuxbrain.com writes: *First and prioritary, allow have multiple languages on same sdcard TBH i can't really understand the desire to have encyclopedic articles written in other languages. It's encyclopedia, not literature after all! Why not concentrate on correctness and volume instead of translating from one language to another equivalent (for this purposes)? It's just happened so that English became an internationally understood way of communication, what is the benefit in trying so hard to do something to alter that? I'd prefer having a good English dictionary integrated instead. -- 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: [wikireader]Suggestions for next steps on software
purposes)? It's just happened so that English became an internationally understood way of communication, what is the benefit in trying so hard to do something to alter that? - english wikipedia does not cover all topics - different languages provide different quality of articles - because there _are_ different versions of wikipedia already ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[All] Black Screen of Death - Won't resume from standby
I've seen this several times with SHR-Unstable and now with Android. So, I'd say it's something that is common among these distro's. Is it seen on all distros? Is it the kernel? Hardware bug? Bootloader issue? Any clues how to debug this or what might cause it? I know I'm not the only one that sees it. How are others dealing with these random lock-ups? Thanks, Steven ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [All] Black Screen of Death - Won't resume from standby
Steven ** montgoss+openmokocommun...@gmail.com writes: I know I'm not the only one that sees it. How are others dealing with these random lock-ups? Saw that several times. It just doesn't resume, obviously a kernel (probably but unlikely bootloader) problem. It'd be nice to reproduce it with ramconsole or a real console attached. Quite possibly it's https://docs.openmoko.org/trac/ticket/2309 -- 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
Tangogps google maps
whats the latest config to get google maps working on tangogps I need help with it too ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] file system questions
David Reyes Samblas Martinez wrote: 2009/10/30 Doug Jones dj...@frombob.to: [snip] I like this approach, just remind that as far I see the code and by comments of the devs, the kernel implements the bare just enough to read files, so I think directories are not implemented at all that's why all is on root directory so at least basic hierarchical filesystem has to be implemented before we can do this solution. But directories will easy the organization of pictures too Good point. So two important questions to be answered, before we get any further into this: (1) Has OpenMoko made the policy decision that filenames will be limited to 8.3? (2) How complicated will it be to implement subdirectory support? Note that only one subdirectory level is really needed to implement what has already been suggested. The current implementation contains 81 files, totaling 4.2GB for the English version. Nearly all of that is in the big wiki data files (pedia*). The other files, the ones you get when you make install, comprise 49 files and only 18MB, and most of that is fonts (which are often different for different languages). We could adopt a brain-swap approach: After bootup, the user selects one wiki and then the app switches to the selected subdirectory and considers that to be the root until the next cold boot. All 81 files for that particular wiki and language would be in that subdirectory, including the big wiki data files and the fonts and the remaining files (45 files, only 381KB, and this includes ALL of the executables!) While the single app is running, it would not have to access (or even know about) anything outside its current directory, so no filesystem calls relating to directory navigation would be needed within that particular kernel.elf. Only the initial wiki selection app (we would have to write one) would have to understand subdirectories, and only to one level deep. mmm this aproach will not complicate too much if after more apps than a reader are implemented? It would not be better to have a even a one level dir fs? nevertheless you will implement it for the starting menu, why not do it directly in the kernel and allow other apps take advantage of this implementation? Again talking from the most totally inexperience. These are good questions. But first we need to answer question #1 above. If we do indeed limit ourselves to 8.3 file names, that also can complicate a lot that we might want to do later, especially if we are limited to a flat directory. When we are thinking about future apps to put on this device, we ought to be careful to keep in mind its current limitations, and what it would take to go beyond them. It has no actual operating system, as most people understand this term. Each app has to be almost completely self-contained. There are no services to allow apps to talk to each other, and indeed only one app can run at a time. When the WikiReader app is running, it is in complete control of the device and nothing else can run until you reboot the device. (The WikiReader app is called kernel.elf for a reason.) Changing this would require putting something resembling a real operating system on there. This is certainly possible, but I suspect it is way, way beyond the scope of anything we have been talking about so far! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Suggestions for next steps on software
2009/10/30 Paul Fertser fercer...@gmail.com: Hi, David Reyes Samblas Martinez da...@tuxbrain.com writes: *First and prioritary, allow have multiple languages on same sdcard TBH i can't really understand the desire to have encyclopedic articles written in other languages. let me gess... your native language is english isn't it? :P It's encyclopedia, not literature after all! Why not concentrate on correctness and volume instead of translating from one language to another equivalent (for this purposes)? It's just happened so that English became an internationally understood way of communication, what is the benefit in trying so hard to do something to alter that? as arne has pointed is not just translating each wikipedia in different language is a different wikipedia and local topics as geography and cultural topics are more rich in the local language than in a foreign one. Also you must face a fact... not everyone in a non english country speaks/reads/or even have listen ever english! yes! it's true believe me , or travel a little more (outside the tourist circuits of course) :) Also comercial reasons the more lenguages can be integrated the more maket you will arrive. I'd prefer having a good English dictionary integrated instead. I prefer a good Spanish one :) I gess if RAE (Royal Academy of Spanish) has an xml to parse :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!!! -- 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: Understanding accelerometer data
2009/10/30 Neil Jerram neiljer...@googlemail.com: OK, I understand what was wrong with my program now. It was reopening the /dev/input/event[2,3] file before every read. [...] FWIW, I've now added my corrected program (in Guile Scheme) to http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] file system questions
2009/10/30 Doug Jones dj...@frombob.to: David Reyes Samblas Martinez wrote: 2009/10/30 Doug Jones dj...@frombob.to: [snip] I like this approach, just remind that as far I see the code and by comments of the devs, the kernel implements the bare just enough to read files, so I think directories are not implemented at all that's why all is on root directory so at least basic hierarchical filesystem has to be implemented before we can do this solution. But directories will easy the organization of pictures too Good point. So two important questions to be answered, before we get any further into this: (1) Has OpenMoko made the policy decision that filenames will be limited to 8.3? (2) How complicated will it be to implement subdirectory support? Note that only one subdirectory level is really needed to implement what has already been suggested. The current implementation contains 81 files, totaling 4.2GB for the English version. Nearly all of that is in the big wiki data files (pedia*). The other files, the ones you get when you make install, comprise 49 files and only 18MB, and most of that is fonts (which are often different for different languages). We could adopt a brain-swap approach: After bootup, the user selects one wiki and then the app switches to the selected subdirectory and considers that to be the root until the next cold boot. All 81 files for that particular wiki and language would be in that subdirectory, including the big wiki data files and the fonts and the remaining files (45 files, only 381KB, and this includes ALL of the executables!) While the single app is running, it would not have to access (or even know about) anything outside its current directory, so no filesystem calls relating to directory navigation would be needed within that particular kernel.elf. Only the initial wiki selection app (we would have to write one) would have to understand subdirectories, and only to one level deep. mmm this aproach will not complicate too much if after more apps than a reader are implemented? It would not be better to have a even a one level dir fs? nevertheless you will implement it for the starting menu, why not do it directly in the kernel and allow other apps take advantage of this implementation? Again talking from the most totally inexperience. These are good questions. But first we need to answer question #1 above. If we do indeed limit ourselves to 8.3 file names, that also can complicate a lot that we might want to do later, especially if we are limited to a flat directory. When we are thinking about future apps to put on this device, we ought to be careful to keep in mind its current limitations, and what it would take to go beyond them. It has no actual operating system, as most people understand this term. Each app has to be almost completely self-contained. There are no services to allow apps to talk to each other, and indeed only one app can run at a time. When the WikiReader app is running, it is in complete control of the device and nothing else can run until you reboot the device. (The WikiReader app is called kernel.elf for a reason.) Changing this would require putting something resembling a real operating system on there. This is certainly possible, but I suspect it is way, way beyond the scope of anything we have been talking about so far! Yes, I had missed the point of the monolitic app, so then an easy approach to make different apps (menus,calculator, note taking, basic drawing, ...) is to enrich it in the reader app itself this way maybe some services (read services as already implemented functions in the code of the reader app) can be used by the little apps, understanding than this little apps are not independent apps but just another screen of the same big app. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community 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: [wikireader]Suggestions for next steps on software
David Reyes Samblas Martinez da...@tuxbrain.com writes: 2009/10/30 Paul Fertser fercer...@gmail.com: David Reyes Samblas Martinez da...@tuxbrain.com writes: *First and prioritary, allow have multiple languages on same sdcard TBH i can't really understand the desire to have encyclopedic articles written in other languages. let me gess... your native language is english isn't it? :P Wrong :P I learnt English a little bit at school and later at the University. I guess it's obvious for a native speaker judging by my far from ideal writing skills. It's encyclopedia, not literature after all! Why not concentrate on correctness and volume instead of translating from one language to another equivalent (for this purposes)? It's just happened so that English became an internationally understood way of communication, what is the benefit in trying so hard to do something to alter that? as arne has pointed is not just translating each wikipedia in different language is a different wikipedia and local topics as geography and cultural topics are more rich in the local language than in a foreign one. It's true, i agree. But i tend to look for non-local topics on 90% of occassions. Also in my experience looking for local topics is usually more rewarding when i do simple googling instead of reading localized wikipedia. Also you must face a fact... not everyone in a non english country speaks/reads/or even have listen ever english! yes! it's true believe me , or travel a little more (outside the tourist circuits of course) :) I think volunteers that write wikipedia articles do that for the benefit of the people who want to learn. And those who do can learn enough English to understand articles, it'd also have other numerous benefits obviously. Also comercial reasons the more lenguages can be integrated the more maket you will arrive. Heh, commercial reasons are something i tend to overlook usually :) -- 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: [wikireader]Suggestions for next steps on software
2009/10/30 Paul Fertser fercer...@gmail.com: David Reyes Samblas Martinez da...@tuxbrain.com writes: 2009/10/30 Paul Fertser fercer...@gmail.com: David Reyes Samblas Martinez da...@tuxbrain.com writes: *First and prioritary, allow have multiple languages on same sdcard TBH i can't really understand the desire to have encyclopedic articles written in other languages. let me gess... your native language is english isn't it? :P Wrong :P I learnt English a little bit at school and later at the University. I guess it's obvious for a native speaker judging by my far from ideal writing skills. Obvously I'm not a native speaker either due my lack of criteria judging :P It's encyclopedia, not literature after all! Why not concentrate on correctness and volume instead of translating from one language to another equivalent (for this purposes)? It's just happened so that English became an internationally understood way of communication, what is the benefit in trying so hard to do something to alter that? as arne has pointed is not just translating each wikipedia in different language is a different wikipedia and local topics as geography and cultural topics are more rich in the local language than in a foreign one. It's true, i agree. But i tend to look for non-local topics on 90% of occassions. Also in my experience looking for local topics is usually more rewarding when i do simple googling instead of reading localized wikipedia. yes bun in this in case of wikireader you have no Saint Google to pray you are offline so the more sources you can store in the card the better and the first easy step is to include more wikipedia. Also you must face a fact... not everyone in a non english country speaks/reads/or even have listen ever english! yes! it's true believe me , or travel a little more (outside the tourist circuits of course) :) I think volunteers that write wikipedia articles do that for the benefit of the people who want to learn. And those who do can learn enough English to understand articles, it'd also have other numerous benefits obviously. I don't know where you are but in Spain we are little far to generalize this as a fact .English level is far from desiderable in a european country, things are changing slowly, now english is learned or at least listened in very early stages in school , my three year daughter two teachers one of thems is an only english speaking teacher and she is starting to understand some easy orders and sentences I hope when this generation grow things will be different here. Also comercial reasons the more lenguages can be integrated the more maket you will arrive. Heh, commercial reasons are something i tend to overlook usually :) more units sold more users, more resources to OM and his friends to to still investing in more cool openfree ideas :) as companies we can't overlook this ;) -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Laszlo KREKACS schrieb: 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. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. the problem is not differentiating between slide and click - e and elementary have this too. it's that if you drag horizontally for example, your actual events often look something like: ++ +--+ +--+ +-+ ++-++ +--+ + + + +---+ if you dont press firmly with a sharp point (stylus, fingernail etc.). you can go to every app and start trying to add filtering to close such gaps, but now you duplicate that code everywhere. IMHO tslib/x should filter it so the input to clients is the intended input by the user. also you will have unintended clicks (drawing press/release over time): + +-+ +-+ you pressed just once - or you think you did. but you actually had a press, a release, and a press , release etc. again because your pressure went above, below and above the pressure level needed to register a click. imho there should be some filtering on the input events that patches these gaps. and that filtering should go in x or tslib. capacitivie screens are much more sensitive and have a different problem - but their events are filtered too as you dont get a point - you get an area that is pressed, so they have a hysterisis on how big the area has to be first to start a press registering and then it has to get much smaller that this area to stop. eg: press start @ 8x8 pixels, press stop at 3x3 pixels. as long as your press area, once registered, is 3x3 pixels, it will continue to be pressed until it gets below. -- - 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: [WikiReader] file system questions
[snip] Yes, I had missed the point of the monolitic app, so then an easy approach to make different apps (menus,calculator, note taking, basic drawing, ...) is to enrich it in the reader app itself this way maybe some services (read services as already implemented functions in the code of the reader app) can be used by the little apps, understanding than this little apps are not independent apps but just another screen of the same big app. Actually, the possibility that interests me the most is the idea of making it easy to put additional content into the reader. The current software is good at displaying textual content, and good at searching for text as well. The hardware is less than optimal for the other types of apps you mentioned -- but it's a good reader. There are many sources of text that one might want to carry around in such a device, not just Wikipedia. E-books, websites, mail archives, other wikis... all we have to do is build the tools to convert the content into a format the device can understand. This is much easier than writing new code to run on the device. For those people who want to write code that runs on the device, there are plenty of things that would make it an even better reader. But I expect to concentrate on the WikiReader tools that run on other computers. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Developer Kernel-2009.10-27 doesn't boot
On Fri, Oct 30, 2009 at 11:28 PM, David Reyes Samblas Martinez da...@tuxbrain.com wrote: the tweetered kernel with kinetic movement and increased touchscreen sensibility http://cloud.github.com/downloads/wikireader/wikireader/kernel-2009-10-27.zip I have unziped it and copy to the sd card replacing the(backuped :P) original kernel and the device doesn't boot (at least in 10 minutes after seeing the Wikireader splash screen i decided is not booting) David Try taking the SD card out and wiggling the socket a bit and putting it back in. Sometimes the contacts don't work perfectly. -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 11:22 PM, David Reyes Samblas Martinez da...@tuxbrain.com wrote: Are you uploading this changes to git? can I take a look? Yes. The latest commit fixes it. Have a look here: http://github.com/wikireader/wikireader 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 11:29 PM, Laszlo KREKACS laszlo.krekacs.l...@gmail.com wrote: On Fri, Oct 30, 2009 at 4:22 PM, David Reyes Samblas Martinez da...@tuxbrain.com wrote: Are you uploading this changes to git? can I take a look? Btw is there any plan to implement images rendering? Math (images) are on our roadmap. Hopefully before the end of this year. The screen is only 1bit. So anything else would look kinda funny. -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Error on parsing the spanish wikipedia
On Sat, Oct 31, 2009 at 2:46 AM, David Reyes Samblas Martinez da...@tuxbrain.com wrote: just an think I realized , all faulty articles the title starts with the ~ simbol David No that's not a problem. That character gets removed in a later build stage. We had to add that because of a integer conversion issue with SQLite. It was automatically converting articles like 1984 into integers (not strings) and storing them in the database. SQLite, BTW, claims this is a feature. Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader]Error on ArticleParsing.py
On Sat, Oct 31, 2009 at 4:00 AM, David Reyes Samblas Martinez
da...@tuxbrain.com wrote:
Man, you forget a , in line 49 on
host-tools/offline-renderer/ArticleParser.py
(re.compile(r'amp;([a-zA-Z]{2,8});', re.IGNORECASE), r'\1;'),---Here!
# change % so php: wr_parser does not convert them
(re.compile(r'%', re.IGNORECASE), r'%25')
Stange. We must not have pushed the right changes. Sorry about that!
-Sean
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [WikiReader] file system questions (was: [wikireader]Suggestions for next steps on software)
On Sat, Oct 31, 2009 at 3:46 AM, Doug Jones dj...@frombob.to wrote: [snip] I like this approach, just remind that as far I see the code and by comments of the devs, the kernel implements the bare just enough to read files, so I think directories are not implemented at all that's why all is on root directory so at least basic hierarchical filesystem has to be implemented before we can do this solution. But directories will easy the organization of pictures too Good point. So two important questions to be answered, before we get any further into this: (1) Has OpenMoko made the policy decision that filenames will be limited to 8.3? We're using FAT. (2) How complicated will it be to implement subdirectory support? Not a problem. We're going to do something like this when we support more languages. Note that only one subdirectory level is really needed to implement what has already been suggested. The current implementation contains 81 files, totaling 4.2GB for the English version. Nearly all of that is in the big wiki data files (pedia*). The other files, the ones you get when you make install, comprise 49 files and only 18MB, and most of that is fonts (which are often different for different languages). Correct. We could adopt a brain-swap approach: After bootup, the user selects one wiki and then the app switches to the selected subdirectory and considers that to be the root until the next cold boot. All 81 files for that particular wiki and language would be in that subdirectory, including the big wiki data files and the fonts and the remaining files (45 files, only 381KB, and this includes ALL of the executables!) While the single app is running, it would not have to access (or even know about) anything outside its current directory, so no filesystem calls relating to directory navigation would be needed within that particular kernel.elf. Only the initial wiki selection app (we would have to write one) would have to understand subdirectories, and only to one level deep. Yeah that should work. -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
