Re: [IAEP] Wanted: List of Sugar activities for the XO-1.5
Another suggestions from -Sur. Geogebra and Wikibrowse. cheers! Rafael Ortiz On Fri, Nov 27, 2009 at 3:38 PM, Claudia Urrea wrote: > What about SocialCalc? I use it with measure to graph the data collected. It > can also be used to do any kind of budget, etc. People use it.. and they are > planning to release a new version with Spanish localization. > > All my XOs have VNC launcher... I use it during workshops or demos, but I > couldn't find it in Sugar Labs. > > Claudia. > > On Thu, Nov 26, 2009 at 8:20 PM, Rafael Enrique Ortiz Guerrero > wrote: >> >> Hi, >> >> It's done..let's see what people says there. >> >> >> Rafael Ortiz >> >> >> >> On Thu, Nov 26, 2009 at 7:19 AM, Tomeu Vizoso wrote: >> > On Wed, Nov 25, 2009 at 18:47, Rafael Enrique Ortiz Guerrero >> > wrote: >> >> Also this should be asked to future XO 1.5 deployments, >> >> they could have another ideas for activities to be included in the >> >> list. >> > >> > Should we ask in olpc-sur? >> > >> > Thanks, >> > >> > Tomeu >> > >> >> >> >> >> >> >> >> >> >> Rafael Ortiz >> >> >> >> >> >> >> >> On Tue, Nov 24, 2009 at 11:05 AM, Jim Simmons >> >> wrote: >> >>> Chris, >> >>> >> >>> I agree with Gerald on either Get Books or Get IA Books (not both). >> >>> Get Books is still being worked on by Sayamindu Dasgupta but perhaps >> >>> he could get it in shape for inclusion in time. Right now it doesn't >> >>> work on .82, but I can't see that being an issue. >> >>> >> >>> Get IA Books works on either but is limited to the books in the >> >>> Internet Archive. There are only about a million books there! It is, >> >>> however, ready to go. It isn't a popular download on ASLO but it >> >>> deserves to be. >> >>> >> >>> You might also consider Read Etexts, because of its text to speech >> >>> with highlighting feature and its own built in book search. It only >> >>> works with Project Gutenberg titles, so no pictures. The present >> >>> version is useable, but I'm working on a new version that supports >> >>> word wrapping on PG texts and saving font size and speech preferences >> >>> (pitch and rate). This is a popular download on ASLO. >> >>> >> >>> I've never tried the IRC Activity so I'm not knocking it, but I wonder >> >>> if children would find that useful. They already have Chat and Speak. >> >>> >> >>> If you're going to include Read you should consider what evince >> >>> modules, etc. to include with it. With the right modules Read can do >> >>> DJVU, .cbz, and EPUB documents as well as PDFs. DJVU in particular is >> >>> useful for Internet Archive books. >> >>> >> >>> James Simmons >> >>> >> >>> >> Date: Mon, 23 Nov 2009 15:26:22 -0500 >> From: Gerald Ardito >> Subject: Re: [IAEP] Wanted: List of Sugar activities for the XO-1.5 >> To: Chris Ball >> Cc: iaep@lists.sugarlabs.org, de...@lists.laptop.org >> Message-ID: >> <9403b1570911231226j58f91cafhbce60f25d00c...@mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Chris, >> >> I would suggest at least one of the Activities to get books, like Get >> IA >> Books. >> >> Otherwise, this list looks good. >> >> Thanks. >> Gerald >> >>> ___ >> >>> IAEP -- It's An Education Project (not a laptop project!) >> >>> IAEP@lists.sugarlabs.org >> >>> http://lists.sugarlabs.org/listinfo/iaep >> >>> >> >> ___ >> >> IAEP -- It's An Education Project (not a laptop project!) >> >> IAEP@lists.sugarlabs.org >> >> http://lists.sugarlabs.org/listinfo/iaep >> >> >> > >> > >> > >> > -- >> > «Sugar Labs is anyone who participates in improving and using Sugar. >> > What Sugar Labs does is determined by the participants.» - David >> > Farning >> > >> ___ >> IAEP -- It's An Education Project (not a laptop project!) >> IAEP@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/iaep > > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Wanted: List of Sugar activities for the XO-1.5
What about *SocialCalc*? I use it with measure to graph the data collected. It can also be used to do any kind of budget, etc. People use it.. and they are planning to release a new version with Spanish localization. All my XOs have *VNC launcher*... I use it during workshops or demos, but I couldn't find it in Sugar Labs. Claudia. On Thu, Nov 26, 2009 at 8:20 PM, Rafael Enrique Ortiz Guerrero < dir...@gmail.com> wrote: > Hi, > > It's done..let's see what people says there. > > > Rafael Ortiz > > > > On Thu, Nov 26, 2009 at 7:19 AM, Tomeu Vizoso wrote: > > On Wed, Nov 25, 2009 at 18:47, Rafael Enrique Ortiz Guerrero > > wrote: > >> Also this should be asked to future XO 1.5 deployments, > >> they could have another ideas for activities to be included in the list. > > > > Should we ask in olpc-sur? > > > > Thanks, > > > > Tomeu > > > >> > >> > >> > >> > >> Rafael Ortiz > >> > >> > >> > >> On Tue, Nov 24, 2009 at 11:05 AM, Jim Simmons > wrote: > >>> Chris, > >>> > >>> I agree with Gerald on either Get Books or Get IA Books (not both). > >>> Get Books is still being worked on by Sayamindu Dasgupta but perhaps > >>> he could get it in shape for inclusion in time. Right now it doesn't > >>> work on .82, but I can't see that being an issue. > >>> > >>> Get IA Books works on either but is limited to the books in the > >>> Internet Archive. There are only about a million books there! It is, > >>> however, ready to go. It isn't a popular download on ASLO but it > >>> deserves to be. > >>> > >>> You might also consider Read Etexts, because of its text to speech > >>> with highlighting feature and its own built in book search. It only > >>> works with Project Gutenberg titles, so no pictures. The present > >>> version is useable, but I'm working on a new version that supports > >>> word wrapping on PG texts and saving font size and speech preferences > >>> (pitch and rate). This is a popular download on ASLO. > >>> > >>> I've never tried the IRC Activity so I'm not knocking it, but I wonder > >>> if children would find that useful. They already have Chat and Speak. > >>> > >>> If you're going to include Read you should consider what evince > >>> modules, etc. to include with it. With the right modules Read can do > >>> DJVU, .cbz, and EPUB documents as well as PDFs. DJVU in particular is > >>> useful for Internet Archive books. > >>> > >>> James Simmons > >>> > >>> > Date: Mon, 23 Nov 2009 15:26:22 -0500 > From: Gerald Ardito > Subject: Re: [IAEP] Wanted: List of Sugar activities for the XO-1.5 > To: Chris Ball > Cc: iaep@lists.sugarlabs.org, de...@lists.laptop.org > Message-ID: > <9403b1570911231226j58f91cafhbce60f25d00c...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Chris, > > I would suggest at least one of the Activities to get books, like Get > IA > Books. > > Otherwise, this list looks good. > > Thanks. > Gerald > >>> ___ > >>> IAEP -- It's An Education Project (not a laptop project!) > >>> IAEP@lists.sugarlabs.org > >>> http://lists.sugarlabs.org/listinfo/iaep > >>> > >> ___ > >> IAEP -- It's An Education Project (not a laptop project!) > >> IAEP@lists.sugarlabs.org > >> http://lists.sugarlabs.org/listinfo/iaep > >> > > > > > > > > -- > > «Sugar Labs is anyone who participates in improving and using Sugar. > > What Sugar Labs does is determined by the participants.» - David > > Farning > > > ___ > IAEP -- It's An Education Project (not a laptop project!) > IAEP@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Feature Policy updated
On Fri, Nov 27, 2009 at 07:40:26PM +0100, Simon Schampijer wrote: * Backup up by the community * The proposer of the feature has to get feedback from the community. This includes technical feedback, feedback from the deployments etc. See as well in the last paragraph about which points the community might care. Of course there will be some different opinions in the community - in general there should be more YES than NO in the community for a feature to be able to get into a Sugar release. This puts the burden of interacting with deployments on each individual feature proposer (but away from the core developers, which is a good thing). How is that supposed to happen (getting feedback from deployments)? Writing to iaep? What if nobody replies to those messages (e.g. because it doesn't matter to them either way), will the feature be rejected even if it's a good idea? (*) (*) Obviously "good idea" is quite subjective, but I assume you understand what I mean. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] [ANNOUNCE] Feature Policy updated
Dear Sugar community, the Feature policy [1] has been updated. * Why this process * Let me quote the first paragraph to exaplin what this policy is for: "The main goal of the feature process is to phrase out the ideas on how Sugar should evolve that are floating around in the community. These can be requests from the field or individual propositions on how to enhance the learning platform. Once the idea is written out in a wiki page (following the process described in detail below) and a maintainer is found who will be working on this feature, it can be proposed to be part of a Sucrose release cycle. The work on that feature will be tracked during the cycle and if finished in time it will find it's way in the Sucrose stable release." * Who can propose a feature * Basically, anyone can propose a feature following the guidelines in the wiki page [2]. This feature can be emerge from a deployment need or a teacher request etc. You do not need to be able to build the feature yourself. Of course to be making it's way into a release someone needs to own the feature and build it. The way to propose a feature to be included in the release cycle and how it gets included in a stable release is described at [3]. * Backup up by the community * The proposer of the feature has to get feedback from the community. This includes technical feedback, feedback from the deployments etc. See as well in the last paragraph about which points the community might care. Of course there will be some different opinions in the community - in general there should be more YES than NO in the community for a feature to be able to get into a Sugar release. * Design * What we enforce is the work with the Design Team when proposing a feature that includes UI changes or adds a new UI. We want to keep the UI consistent and the quality high. As the Sugar environment is mainly about the UI and a clear work flow this is very important. * Things you should consider when proposing a feature * There are several things you should consider when proposing a feature for the Sugar learning platform [4]. How does it impact learning? How usable and useful is this feature to a young learners? How well does this fit into a classroom environment? [...] These are good guidelines to make a Feature a success. Keep the ideas and implementations coming, Simon PS: If you need an example of someone following the process have a look at Aleksey's last mails [5]. [1] http://wiki.sugarlabs.org/go/Features/Policy [2] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature [3] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle [4] http://wiki.sugarlabs.org/go/Features/Policy#Things_you_should_consider_when_proposing_a_feature [5] http://lists.sugarlabs.org/archive/sugar-devel/2009-November/021031.html ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] The sugar stack
On Fri, Nov 27, 2009 at 1:14 PM, Aleksey Lim wrote: > On Fri, Nov 27, 2009 at 05:56:42PM +, Aleksey Lim wrote: >> On Fri, Nov 27, 2009 at 09:55:20AM -0600, David Farning wrote: >> > Many of the discussion about this have stalled because of confusion >> > over what aspect the stack we are trying to define. >> > >> > As a starting point, I would suggest: >> > 1. That we get rid of the glucose - fructose categorisation. It is >> > overloaded and confusing >> >> yup, I like scheme when new activity developer well understands(from >> beginning) that there is core and his new activity(w/o "core", since >> fructose comes from sucrose release) which uses core functionality. >> >> > 2. That Quality and synchronisation of activities becomes an >> > Activities Team issue. >> >> and ASLO could be useful on that way(featured activities, editors >> collections etc) and this process is pretty transparent(e.g. we have >> public aslo@ ml to discuss editros questions) and well visible(all >> editors changes are accessible right after changes) on ASLO. >> >> So, in comparing with fructose scheme(which e.g. involves all distro >> packagers, since they should package fructose) in case of ASLO we >> have more flexible method. > > I guess one of major reasons to keep fructose is localization issue > (its much easier for translators to have tough set of activities > to localize them at first). > > In my mind its just remains from OLPC scheme(when where is only > one developer/deployer). But now, another deployment could have another > priority in choosing activities. > > So translate.sl.o could have several activity sets for various > deployers/deployments such we have now only for OLPC. > > And in addition to such sets, using "Featured activities" which > will be set of featured activities on ASLO(last activity versions). It would be interesting to auto-generate groups in Pootle based on the groups people define in ASLO. -walter > -- > Aleksey > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] The sugar stack
On Fri, Nov 27, 2009 at 05:56:42PM +, Aleksey Lim wrote: > On Fri, Nov 27, 2009 at 09:55:20AM -0600, David Farning wrote: > > Many of the discussion about this have stalled because of confusion > > over what aspect the stack we are trying to define. > > > > As a starting point, I would suggest: > > 1. That we get rid of the glucose - fructose categorisation. It is > > overloaded and confusing > > yup, I like scheme when new activity developer well understands(from > beginning) that there is core and his new activity(w/o "core", since > fructose comes from sucrose release) which uses core functionality. > > > 2. That Quality and synchronisation of activities becomes an > > Activities Team issue. > > and ASLO could be useful on that way(featured activities, editors > collections etc) and this process is pretty transparent(e.g. we have > public aslo@ ml to discuss editros questions) and well visible(all > editors changes are accessible right after changes) on ASLO. > > So, in comparing with fructose scheme(which e.g. involves all distro > packagers, since they should package fructose) in case of ASLO we > have more flexible method. I guess one of major reasons to keep fructose is localization issue (its much easier for translators to have tough set of activities to localize them at first). In my mind its just remains from OLPC scheme(when where is only one developer/deployer). But now, another deployment could have another priority in choosing activities. So translate.sl.o could have several activity sets for various deployers/deployments such we have now only for OLPC. And in addition to such sets, using "Featured activities" which will be set of featured activities on ASLO(last activity versions). -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] The sugar stack
On Fri, Nov 27, 2009 at 09:55:20AM -0600, David Farning wrote: > It seems time to think about the next _big_ technical issue for > growing Sugar Labs. Clearly articulating the Sugar Stack. For the > last year or so, we have been circling the issue with talk of stable > APIs, Glucose, Fructose, and expected dependencies. > > Last year, we created the release cycle. At first, _everyone_ > disagreed with the idea; Release cycles are perfect for _no_one_. > Defining the Sugar Stack is going to be nearly as painful, because the > 'stack definition' is not going to be perfect for anyone. yeah, but using 0install dependencies[1] should make stack definition issue not so hard(we can include to stack only very common dependencies) > Some reasons for defining a stack: > 1. Statement of quality. One of the most frequently cited reasons for > the glucose, fructose, honey classification is quality. > - Glucose is the core stuff. > - Fructose is the supported stuff. > - Honey is the rest. > This is a very valid method of defining layers of the project; Fedora > had core and extras, Ubuntu has main and universe, Eclipse has various > levels of official-ness, (none of which I can remember) The kernel > simply has 'in-tree' and 'out-of-tree'. > > 2. Statement of synchronisation. In some instances it is desirable > for various parts of a project to be tested and release together. > - Sugar core is developed according to a release cycle. > - Fructose tends to align with the release cycle. > - Honey happens 'when it happens.' > This is also very valid; Distro all have synchronised releases. The > desktop managers all ship a core at distinct release points. Ecplise > has its release train. > > 3. Statement of what is provided. Down streams _need_ to know what > applications they can depend on. > - Core APIs > - Optional things to meet dependencies. > Most languages provide for core functionality which can be extended > with modules. Apache also is organized as http server and installable > modules. > > Many of the discussion about this have stalled because of confusion > over what aspect the stack we are trying to define. > > As a starting point, I would suggest: > 1. That we get rid of the glucose - fructose categorisation. It is > overloaded and confusing yup, I like scheme when new activity developer well understands(from beginning) that there is core and his new activity(w/o "core", since fructose comes from sucrose release) which uses core functionality. > 2. That Quality and synchronisation of activities becomes an > Activities Team issue. and ASLO could be useful on that way(featured activities, editors collections etc) and this process is pretty transparent(e.g. we have public aslo@ ml to discuss editros questions) and well visible(all editors changes are accessible right after changes) on ASLO. So, in comparing with fructose scheme(which e.g. involves all distro packagers, since they should package fructose) in case of ASLO we have more flexible method. > This shifts the discussion back to the hard problem of how to think > terms of 'Sugar-Space' and 'Activities-Space'. > > Long term projects success depends on external organisation knowing > what they can depend on to be part of Sugar. > > Before starting a holy war The process of articulating the Sugar > stack, much the the release cycle, is an evolutionary process. There > is no way the anyone could sit down and declare, 'This is what Sugar > consists of... and will consist of in the future.' > > Instead, the stack is a snapshot of agreed upon APIs, libraries, and > applications on which downstream activities developers can depend. I > suggest that: > 1. The development team and activities team work together to start > defining the boundary between core and activities. well, from tech POV, its pretty clear - there are core packages and activities that use core API/services/resources > 2. All changes to the core and activities boundary should go through > the new features (or similar) process. > > After a few iterations, this process will become as second nature as > the release process. > > david > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > [1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Download_dependencies_for_sugar_activity -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Please help suggest illustrated eBooks for Sugar on a Stick v2 Blueberry launch
very helpful Jim thanks! On Fri, Nov 27, 2009 at 5:50 PM, Jim Simmons wrote: > Sean, > > Check out the Children's Library here: > > http://www.archive.org/details/iacl > > There are several books in Arabic, Farsi, and other languages. The > top rated Arabic books are short, well illustrated, and aimed at young > children so they might be good choices in DJVU format. Some > possibilities: > > Tagalog -- Pag-Aalsa Sa Cavite; Bakit Binitay Sina Padre Gomez, Burgos > At Zamora? http://www.archive.org/details/vllpgls > > Arabic -- Ras Al-Afa http://www.archive.org/details/mrmrslf > > Farsi -- Raha Kih Mamanad http://www.archive.org/details/shjrhkh > > French -- L'Arche de N http://www.archive.org/details/larcheden00guig > > Chinese -- Kao Ai Ti Che Chih http://www.archive.org/details/ktchchh > > Chinese -- Ku Kung Wen Wu Pao Tsang Hsu Pien > http://www.archive.org/details/kkngwnw > > Hope this helps. > > James Simmons > > >>> Date: Thu, 26 Nov 2009 00:02:43 +0100 >>> From: Sean DALY >>> Subject: [IAEP] Please help suggest illustrated eBooks for Sugar on a >>> Stick v2 Blueberry launch >>> >>> Sugar on a Stick v2 Blueberry will be launched at the Netbook World >>> Summit in Paris on December 8th and Walter will open the summit with >>> the keynote presentation! >>> >>> Sebastian and other members of the SoaS team are working hard on >>> finalizing the master this weekend. >>> >>> In this holiday season with $250 Kindles and $299 Nooks and $$$ >>> eBooks, we want to talk about Sugar's great eBook tools as well as >>> open access eBooks - that eBooks shouldn't be only pricey DRM'd >>> downloads for pricey gadgets. >>> >>> To do this, we want to "populate" Blueberry's Journal with a small >>> number of eBooks. Small, so the Journal is not overstuffed; eBooks >>> there will help new Sugar users to understand the Journal. >>> >>> We do feel though that it is important that of the handful of eBooks, >>> not all should be in English. We won't have room for every language >>> (that needs to wait for a later version of Sugar or SoaS which could >>> have filter logic by language). But an eBook in half a dozen >>> languages, with instructions for parents and teachers where to find >>> others, will effectively demonstrate Sugar's potential as an eBook >>> reader solution. Books written in the native language will be >>> preferable to translations of books originally written in English - >>> we'd like to show that Sugar content can be localized and not merely >>> translated. >>> >>> Please suggest eBooks! ideally, an illustrated eBook in EPUB format >>> (although we may be able to convert from other formats by hand since >>> there will only be a few). Send links! >>> >>> If it's possible before Sunday, it would be fabulous if we could >>> include an eBook created by children in the classroom! Even a >>> collection of scans could be fairly easily "bound" into an eBook file. >>> >>> Thanks for your help! >>> >>> Sean >>> Sugar Labs Marketing Coordinator >> > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] [ANNOUNCE] Sucrose 0.88 Development Cycle Schedule
Dear Sugar Community, I am proud to present you the Sucrose 0.88 Schedule [1]! * Dates * We keep the time based 6 months release cycle. Final release will be: 31rd of March 2010. We basically have the same dates as GNOME. Those dates are made in conjunction with the various distributions. So we will be able to get our final release into the distributions. * New Freezes * We added some new freezes based on the experience of previous development cycles. For example we have now an UI freeze to avoid UI changes late in the cycle. As the UI is such a crucial part, we hope to keep the quality of the UI and the Sugar work flow high. This helps documentation efforts, as well. * Earlier Feature Freeze * Furthermore the Feature Freeze is earlier than in previous cycles. We want to give testers more chances to test the new features and the developers more time to clean the rough edges and stabilize them. At the final release we would like to give out a stable release with many new exciting features. * Long term planning * We layed out the 0.90 schedule, too. This allows for long term planning. For example for bigger features like versions in the datastore. If your feature misses the 0.88 boat, don't be sad the next release is coming. * Testing * We want to give out a Soas build containing Fedora 12 and the current development build. This should allow testers to have a simple to use platform for testing. Of course testing can happen as well in other distributions. The release dates are Wednesdays - we hope that the release is then packaged by the weekend to allow testers to do testing. Help wanted: We would like to see testing teams to emerge ---> coordinated effort, more fun etc. Of course individuals can do testing, too. * Feature Process * The has been an overview of the Feature Process [3]. Mainly trying to write it up more clearly. But as well adding more details about how to get feedback about a feature and how to work on UI features. There will be another mail with more details on the process. * Release Manager * As already in previous releases Simon Schampijer will be your release manager. * Do the actual work * The roadmap is only the framework for this development cycle. The amount of success is up to each one of us. We have an earlier Feature Freeze now to allow for testing, but the testing itself must still happen. We have more time for stabilizing now, but the developers need to do bug fixing then. The roadmap should help as well contributors to prioritize their work based on the freezes. Use that tool! Everyone a productive development cycle, Simon [1] http://wiki.sugarlabs.org/go/0.88/Roadmap#Schedule [2] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule [3] http://wiki.sugarlabs.org/go/Features/Policy ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Please help suggest illustrated eBooks for Sugar on a Stick v2 Blueberry launch
Sean, Check out the Children's Library here: http://www.archive.org/details/iacl There are several books in Arabic, Farsi, and other languages. The top rated Arabic books are short, well illustrated, and aimed at young children so they might be good choices in DJVU format. Some possibilities: Tagalog -- Pag-Aalsa Sa Cavite; Bakit Binitay Sina Padre Gomez, Burgos At Zamora? http://www.archive.org/details/vllpgls Arabic -- Ras Al-Afa http://www.archive.org/details/mrmrslf Farsi -- Raha Kih Mamanad http://www.archive.org/details/shjrhkh French -- L'Arche de N http://www.archive.org/details/larcheden00guig Chinese -- Kao Ai Ti Che Chih http://www.archive.org/details/ktchchh Chinese -- Ku Kung Wen Wu Pao Tsang Hsu Pien http://www.archive.org/details/kkngwnw Hope this helps. James Simmons >> Date: Thu, 26 Nov 2009 00:02:43 +0100 >> From: Sean DALY >> Subject: [IAEP] Please help suggest illustrated eBooks for Sugar on a >> Stick v2 Blueberry launch >> >> Sugar on a Stick v2 Blueberry will be launched at the Netbook World >> Summit in Paris on December 8th and Walter will open the summit with >> the keynote presentation! >> >> Sebastian and other members of the SoaS team are working hard on >> finalizing the master this weekend. >> >> In this holiday season with $250 Kindles and $299 Nooks and $$$ >> eBooks, we want to talk about Sugar's great eBook tools as well as >> open access eBooks - that eBooks shouldn't be only pricey DRM'd >> downloads for pricey gadgets. >> >> To do this, we want to "populate" Blueberry's Journal with a small >> number of eBooks. Small, so the Journal is not overstuffed; eBooks >> there will help new Sugar users to understand the Journal. >> >> We do feel though that it is important that of the handful of eBooks, >> not all should be in English. We won't have room for every language >> (that needs to wait for a later version of Sugar or SoaS which could >> have filter logic by language). But an eBook in half a dozen >> languages, with instructions for parents and teachers where to find >> others, will effectively demonstrate Sugar's potential as an eBook >> reader solution. Books written in the native language will be >> preferable to translations of books originally written in English - >> we'd like to show that Sugar content can be localized and not merely >> translated. >> >> Please suggest eBooks! ideally, an illustrated eBook in EPUB format >> (although we may be able to convert from other formats by hand since >> there will only be a few). Send links! >> >> If it's possible before Sunday, it would be fabulous if we could >> include an eBook created by children in the classroom! Even a >> collection of scans could be fairly easily "bound" into an eBook file. >> >> Thanks for your help! >> >> Sean >> Sugar Labs Marketing Coordinator > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] The sugar stack
It seems time to think about the next _big_ technical issue for growing Sugar Labs. Clearly articulating the Sugar Stack. For the last year or so, we have been circling the issue with talk of stable APIs, Glucose, Fructose, and expected dependencies. Last year, we created the release cycle. At first, _everyone_ disagreed with the idea; Release cycles are perfect for _no_one_. Defining the Sugar Stack is going to be nearly as painful, because the 'stack definition' is not going to be perfect for anyone. Some reasons for defining a stack: 1. Statement of quality. One of the most frequently cited reasons for the glucose, fructose, honey classification is quality. - Glucose is the core stuff. - Fructose is the supported stuff. - Honey is the rest. This is a very valid method of defining layers of the project; Fedora had core and extras, Ubuntu has main and universe, Eclipse has various levels of official-ness, (none of which I can remember) The kernel simply has 'in-tree' and 'out-of-tree'. 2. Statement of synchronisation. In some instances it is desirable for various parts of a project to be tested and release together. - Sugar core is developed according to a release cycle. - Fructose tends to align with the release cycle. - Honey happens 'when it happens.' This is also very valid; Distro all have synchronised releases. The desktop managers all ship a core at distinct release points. Ecplise has its release train. 3. Statement of what is provided. Down streams _need_ to know what applications they can depend on. - Core APIs - Optional things to meet dependencies. Most languages provide for core functionality which can be extended with modules. Apache also is organized as http server and installable modules. Many of the discussion about this have stalled because of confusion over what aspect the stack we are trying to define. As a starting point, I would suggest: 1. That we get rid of the glucose - fructose categorisation. It is overloaded and confusing 2. That Quality and synchronisation of activities becomes an Activities Team issue. This shifts the discussion back to the hard problem of how to think terms of 'Sugar-Space' and 'Activities-Space'. Long term projects success depends on external organisation knowing what they can depend on to be part of Sugar. Before starting a holy war The process of articulating the Sugar stack, much the the release cycle, is an evolutionary process. There is no way the anyone could sit down and declare, 'This is what Sugar consists of... and will consist of in the future.' Instead, the stack is a snapshot of agreed upon APIs, libraries, and applications on which downstream activities developers can depend. I suggest that: 1. The development team and activities team work together to start defining the boundary between core and activities. 2. All changes to the core and activities boundary should go through the new features (or similar) process. After a few iterations, this process will become as second nature as the release process. david ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [SoaS] Please help suggest illustrated eBooks for Sugar on a Stick v2 Blueberry launch
Many thanks for these suggestions! We have English, French, German, Bengali, and Italian suggestions. Sebastian - I will collate the files for you. I thought I found a nice Dutch title here (http://www.geheugenvannederland.nl/?/en/items/PRB01:811205169/&p=1&i=1&st=Gouden%20Vlinders&sc=%28cql.serverChoice%20all%20Gouden%20%20AND%20Vlinders%29/&wst=Gouden%20Vlinders) but unfortunately there are copyright restrictions, even for a 1927 book. Could anyone suggest other languages, in particular Spanish, Portugese, or Russian titles? Or indeed any other language. urgent! thanks Sean On Fri, Nov 27, 2009 at 4:16 PM, Bert Freudenberg wrote: > On 27.11.2009, at 02:15, Tim McNamara wrote: >> Max & Moritz is in the public domain. It would be a wonderful addition to >> the collection, if possible. Does anyone know whether it is available? > > Excellent suggestion! It's here: > > http://www.gutenberg.org/etext/17161 > > - Bert - > > > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [SoaS] Please help suggest illustrated eBooks for Sugar on a Stick v2 Blueberry launch
On 27.11.2009, at 02:15, Tim McNamara wrote: > Max & Moritz is in the public domain. It would be a wonderful addition to the > collection, if possible. Does anyone know whether it is available? Excellent suggestion! It's here: http://www.gutenberg.org/etext/17161 - Bert - ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sunflower for Science on XO
On Fri, Nov 27, 2009 at 09:50, Danny Kodicek wrote: > Hi, Tomeu, thanks for your reply > >> > 1) Screen resolution >> > The biggest problem we have is that the screen res of the XO seems >> > unnecessarily high and can't be changed. This leads to two >> big problems, one >> > of readibility (which we can fix with a bit of work) and >> one of performance. >> > Given the low spec of the machines, running full-screen >> animations, some of >> > them in 3d, is pretty hard work for them at that >> resolution. Does anyone >> > have any suggestions for ways to get round this issue? For >> example, I've >> > been thinking about whether we could run the software at >> half-res and then >> > use a screen magnifier app to bring it back to fullscreen >> >> That approach has been discussed and I think that someone got it to >> work up to some point, I recommend you to search in the >> de...@lists.laptop.org archives for the keyword "scaling", "zoom", >> etc. I'm cc'ing that list in the hope that someone will reply. > > Thanks for that, it's very helpful. I did some searching as you suggested > and it seems that this is a very commonly recognised issue, with lots of > discussion but no real solutions. It did seem that several people have been > calling for the XO to have a screen resolution switch option, which would > certainly be the simplest solution from our point of view. There was a > mention of a particular driver which apparently fixes the issue but hasn't > been included in any Sugar builds - anyone know anything about that? There is no such thing as Sugar builds. Sugar is a set of software components that people such as OLPC and Sugar on a Stick take and distribute on top of a linux distribution. Questions specific to the XO are better asked to the OLPC community. > On the same subject, we've also found that running in 16bit display mode is > a serious issue for any of our content that uses 3d. Is there any way to > cheat the display to think it's 32bit instead? I think you can draw to either 16bit or 32bit surfaces, then the X system will convert them to whatever it's using internally. But I have no idea how you would do that in win32 and/or wine. >> I recommend you to make an .xo that contains both wine and you binary, >> when the activity is launched, wine would be called with your binary >> as an argument. I think there was a good example running around some >> time ago, which did just that with an excel viewer or similar. > > That's kind of what I was aiming for, yes - if anyone could point me to that > example or any others that would be a big help. Maybe this could help? http://lists.sugarlabs.org/archive/sugar-devel/2008-April/005128.html Regards, Tomeu >> >> > I'm afraid I'm a total Linux novice, so any advice would be >> welcome, but if >> > you could talk to me like a small child that would be very >> helpful :) >> >> Sorry I cannot give you more precise instructions, I'm really short of >> time these days. I would suggest you to google around, patiently ask >> here and in other fora, and go step by step towards your goal, >> learning on the way. That's what small children do, right? :p > > Unfortunately I don't have quite as much time as the average small child to > build up my muscles - there's a chance we might be piloting the software in > a number of schools very soon and so I'm really trying to get up to speed > quickly! I'm a fast learner, but I find learning about Linux in general and > Sugar in particular to be like picking up sand - it's very hard to find info > that doesn't already assume a lot of prior knowledge. > > But as I say, even little bits of help are very gratefully received! In > particular, just nods in the right direction make a big difference - your > tip above was very helpful indeed. > > Thanks > Danny > > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
