Re: [Sugar-devel] GSoC 2010: Peaceful Revolution
On Fri, Mar 26, 2010 at 01:15, Carlos mauro unima...@gmail.com wrote: Hello! My name is Carlos Mauro. I'm a master student from Perú. I send this idea to Sugar for this GSoC. Friends,I wait the feedback. http://idea.sugarlabs.org/drupal5/ideatorrent/idea/28/ Peaceful Revolution This is a activity with help to the father and son teach read to the baby 2 to 4 yeas old. This is automation from Glen Doman theory, this theory sing the baby can be learn to read before 2 years old. Only make a practice. This project have a two solutions: Work with a openoffice.org and put the solution into XO 1.5 or use the XO 1.0 using a speak and a GUI administrator with the parent or son make a session and integrate the openclipart with the Sugar with a web service or another element to send the files to make a slide for the baby. The application finally is similar a photo slide but the photo have a word and sound with the pronunciation o the sound record for the parent. This application would provide a greater range of target audiences using the XO-1.0 since it now also include a homeschooling which encourages children's early reading. More details and research on this topic: http://www.gentlerevolution.com/mm5/merchant.mvc The application finally is similar a photo slide but the photo have a word and sound with the pronunciation o the sound record for the parent. This application would provide a greater range of target audiences using the XO-1.0 since it now also include a homeschooling which encourages children's early reading. More details and research on this topic: http://www.gentlerevolution.com/mm5/merchant.mvc Do you have any mockups? I have trouble guessing what your activity will look like from those links. Thanks, Tomeu FeedBack Please :$ -- Carlos Mauro Cárdenas Fernández Ingeniero de Sistemas 4582877 980525716 Creemos en el amor de los Seres Humanos http://forpapers.blogspot.com/ http://unimauro.blogspot.com/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal Backup/Restore UI
I'm a bit confused, is the problem reliable full restore with limited local space or the DS having the xapian DB open while the copy happens? Or both? Thanks, Tomeu On Fri, Mar 26, 2010 at 00:51, Bernie Innocenti ber...@codewiz.org wrote: In Paraguay, we started discussing the topic of improving backup and restore procedures. Let's compare notes with a wider audience. We started from an existing backup/restore procedure written by Daniel Drake one year ago. It's meant to be invoked from the Terminal and uses a transactional approach: 1) the technician runs a script to restore the journal from the school server into a temporary directory while Sugar is still running; 2) then, you restart Sugar (by killing the sugar-shell process); 3) on startup, the olpc-session script notices the temporary directory and replaces the datastore with it almost atomically. The problem with this approach was that it only works as long as there's a enough free space in the filesystem, which is rarely the case with laptops that are actually in use. Transactional behavior would be good to have, but I don't see how we could implement it reliably. Even an rsync in-place would have to be done with --delete-before to ensure it works all the time. This opens the question of how we stop the datastore from accessing the journal and mess it up while we're still updating it. We're currently doing it quite a gross way: kill the datastore process before beginning the restore, then restart Sugar: http://trac.paraguayeduca.org/browser/scripts/os-modifications/diario-restaurar We'll thoroughly test this new kludge tomorrow. I'm confident it will work, but it's a shame that users need to call tech support in order to restore a backup. Perhaps it's time to add integrated backup/restore functionality to the datastore itself, with a nice UI in the Journal or in the control panel. The underlying mechanism could be as simple as the one we're testing now, but with proper synchronization with the datastore and no need to restart Sugar. Shall we go on and write a feature page, targeting 0.90? If it's done as a control panel item, it may be sufficiently self-contained to backport it all the way back to 0.84. For the time being, I might add the backup and restore scripts to olpc-utils. Or, better, create a new sugar-utils package for these things that are generally useful on any platform. Suggestions? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal Backup/Restore UI
On Sun, 2010-03-28 at 14:14 +0200, Tomeu Vizoso wrote: I'm a bit confused, is the problem reliable full restore with limited local space or the DS having the xapian DB open while the copy happens? Or both? Both, but somehow we managed to solve them in a quick dirty way: 1) our script kills the datastore process before starting the restore. Then, at the end of the procedure, we restart Sugar. 2) we restore the journal in place, using the --delete-before option of rsync in order to free up space in the filesystem beforehand I've tested this procedure yesterday in a school, and it worked egregiously with two different laptops. The code is here: http://trac.paraguayeduca.org/browser/scripts/os-modifications/diario-restaurar Now we're just missing a nice GUI for end-users: a control panel icon or a button in the journal toolbar. Someone has to file a feature request and discuss it with the Design team. Would anyone like to get started on this while we're still busy fixing the few remaining high-priority bugs in Sugar 0.84? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hard code freeze exception request: fix for a regression introduced by a bug fix
On Sat, Mar 27, 2010 at 20:03, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Sat, Mar 27, 2010 at 06:46:14PM +0100, Simon Schampijer wrote: The fix is easy and I tested it as working [2]. I think Sayamindu tested it, too. +1 +1 This is a good example of how seemingly simple and small changes can introduce major regressions towards the end of the cycle. Let's hope the proposed patch doesn't introduce new issues! Regards, Tomeu CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJLrkhpAAoJELpz82VMF3DaxWQH/iouPSFj7wm2SuwtGegZL+MS sN6p4ffRQe6dyWPY92jnB96fV3k89BzjRmHZES1t4OTsXikmbV1qLbunFqvp6zNj X5pJYi+i31WpsZ+6jvasp1jZP4u09pwwMULx287JbF6yGxWw1vG2OZDQ61fcPkbk 2+OcvokWwCFgm3GoPPkY5Pl/vUD1om4Pg9ZnTNZWShhv/JlmS4RuVYsSNVDm32I/ 455X4mhNHffMzlFNQmT+AOmNsXnqo8VGbLYzLiuCfhuym9m5pmYg3E3lQZW/buup tXAe9M0BlDGUdDuwwFEAhmhNppbC7anCG+NIsjhtpwpSSa7I5hBjV1XNWwBATKQ= =y3Td -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] What's going on with Sugar on a Stick?
Yes Sebastian, by all means preparing for your exams and solving your school financing problem are higher priorities! Rooting for you. Sean. On Fri, Mar 26, 2010 at 5:15 PM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Sebastian first of all thanks for all your hard work up until now. And more importantly all the best for your upcoming final exams. We look forward to seeing you on the flip side! as you may have noticed, there are a couple of changes coming to Sugar on a Stick to keep the whole project sustainable. In the upcoming month, from March 28 (I'll be off starting Sunday night) to May 7, my ability to devote time to the project will cease. I have to prepare for my major A-level exams; more importantly, I have to secure a significant amount of funding in order to be able to attend college later this fall. (If you're interested in helping, see http://sdziallas.com/blog/sebastian/2010/03/sebastian-needs-100k.html for more details - any advice would be appreciated.) This does not affect the release date. Sugar on a Stick will be released as a spin through Fedora's release engineering process on May 11. We are bound to this date and will have a working release in time. The general release schedule including all relevant policies is available here [1]. Nightly builds are also available [2] (and will contain a fixed IRC activity within a couple of days, as soon as [3] has been pushed to stable). Activity authors are also advised that the final freeze date for package updates is April 27, so make sure to get fixes pushed well in advance to give package maintainers and the update system time to process. Peter Robinson has kindly agreed to act in case something is needed. Please make sure to post to the appropriate lists, though, so that everybody is in the loop. Finally, please file bugs at bugs.sugarlabs.org as explained in [4] to save all of us time. Just as a couple of points here. Please keep as much of the discussion on the soas mailing list as possible so that everyone is aware of any issues in a lead up to the release in March. I will do my best to keep up with things as we work towards the release. Please also check the bug tracker [1] to see if any issues are already known about and if you don't see it there please file a bug against SoaS so it can be tracked. I will be reviewing and updating things over the next week as we head full forward into the Fedora 13 / SoaS 3 Beta. I look forward to your assistance in making this a great release. Peter http://bugs.sugarlabs.org ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New Chapter in Make Your Own Sugar Activities needs review
On 28.03.2010, at 04:04, James Simmons wrote:
In the last version of the book I had some content on working with the
Journal in the Adding Refinements chapter but it wasn't much and
didn't belong there. After finishing Sugar Commander I felt that I
had a good example to use for a whole chapter on working with the
Journal, so I removed the content from Adding Refinements and added
the new chapter. The code in Sugar Commander works, but I'd still
appreciate a review of this new information to be certain that I have
the details right.
Nice chapter :)
There is one serious flaw in your Sugar Commander code:
datastore.find({})
You should never call that find method without narrowing the results, at least
in production code. Since you only use specific properties, you should tell the
datastore to only return these. Otherwise, it will send megabytes of unused
preview data (and arbitrary meta data you cannot even anticipate) over D-Bus if
there are hundreds of Journal entries, which is not at all uncommon. So the
right way would be to write
ds_objects, num_objects = datastore.find({}, properties=['uid',
'title', 'mime_type', 'mountpoint'])
assuming those are the properties you need, which is not that much more
complicated. You always have to include 'uid', otherwise the find() method
breaks. Which is a bug IMHO ;)
For filtering by mountpoint, it's better to give this as a query argument
rather than fetching all entries and discarding the unwanted entries later:
query = {}
if mountpoint_id is not None:
query['mountpoints'] = [ mountpoint_id ]
ds_objects, num_objects = datastore.find(query, properties=['uid',
'title', 'mime_type'])
This is more efficient, but not as important as specifying the returned
properties.
The real Journal also employs the technique of only fetching the visible
entries, a page at a time, by adding 'limit' and 'offset' arguments to the find
call. This would complicate the discussion so it's okay to leave out I guess.
But narrowing the find() results to the needed properties is essential.
Later down you write Metadata entries for Journal objects alwayts [sic]
contain strings which is only true for Sugar 0.82. In Sugar 0.84 and later the
entries are actually byte arrays, not strings. This also makes this later
statement incorrect: ... since the Journal has never been able to store
binaries as metadata In fact, newer Sugar versions _do_ store the preview
as binary, not base64 encoded.
This is also not quite correct: the [preview] image file is always 320 x 240
pixels. The preview can actually be of arbitrary size, the recommended
resolution is (was?) 300 x 225 pixels, a quarter in each dimension of the XO's
1200x900 screen size.
I also noticed some typos, but found the chapter too entertaining to write them
down ... just run a spell checker ;)
- Bert -
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] mcnamara....@gmail.com
On Sun, Mar 28, 2010 at 7:51 PM, Yevlempy(Harsh Verma) yevle...@gmail.comwrote: Hi I Would like to propose GSOC 2010 idea for Sugarlabs. The Proposal I would like to propose an idea of Integrating LDTP with sugar. Gnome/LDTP[1] (Linux Desktop Testing Project) seem to be doing this set of things for Gnome (and other desktops) the evince test suite includes automatic UI tests as well. Advantages We can do a set of basic tests that simulate a user working with Sugar basically doing the Smoke Test stuff automatically. Having a fully working test suite that can not test those few parts will also be a good motivation/idea to replace them. Required As a starter i would need some kind of test framework that starts up Sugar in a virtual X server (i.e. something like xvfb), wait for Sugar to start up (for most of the tests - maybe some might try to crash it by activating things while the UI is still is loading) and run a single test (each test will start fresh).Which can be achieved by trying to reuse Mago[2]. And looking at the [3] we can also try to do some thing with xvfg.LDTP can be used to test the functionality of an accessibility enabled application. As sugar is build on top of the Gnome libraries, the AIUI, the Gnome libraries already take care of that. My FOSS expirence I have been a Fedora Ambassador[4] since a long time enjoying the open source world. I basically do stuff with python and pygtk(though in process of reading), recently i have made a control panel extension for sugar i.e font panel which codes be found at [5]. The detailed documentation of its making can be found [6]. I also have worked with web framework before i.e Rubyonrails. I would like someone to mentor me on this idea, and would love to hear up from mentors and developers. [1]http://ldtp.freedesktop.org/wiki/ [2]https://launchpad.net/mago [3]http://ldtp.freedesktop.org/wiki/HOWTO [4]http://fedoraproject.org/wiki/User:Yevlempy [5] http://git.sugarlabs.org/projects/sugar/repos/yevlempy/commits/973b0bd9def313cf6cf9ffea967c4626ebb9ffc6 [6]http://yevlempy.wordpress.com/2010/03/27/the-sugar-font-panel/ Thanks, --yev-- -- yevlempy | Harsh Verma Fedora Ambassador(INDIA) http://yevlempy.wordpress.com/ Sorry for typo :(. -- yevlempy | Harsh Verma Fedora Ambassador(INDIA) http://yevlempy.wordpress.com/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New Chapter in Make Your Own Sugar Activities needs review
From: James Simmons nices...@gmail.com
Date: Sun, Mar 28, 2010 at 8:45 AM
Subject: Re: [Sugar-devel] New Chapter in Make Your Own Sugar
Activities needs review
To: Bert Freudenberg b...@freudenbergs.de
Bert,
Thanks much. I'll fix Sugar Commander and the chapter per your
instructions. There is NO WAY I would have figured out what you wrote
on my own.
Thanks again,
James Simmons
On Sun, Mar 28, 2010 at 7:44 AM, Bert Freudenberg b...@freudenbergs.de wrote:
On 28.03.2010, at 04:04, James Simmons wrote:
In the last version of the book I had some content on working with the
Journal in the Adding Refinements chapter but it wasn't much and
didn't belong there. After finishing Sugar Commander I felt that I
had a good example to use for a whole chapter on working with the
Journal, so I removed the content from Adding Refinements and added
the new chapter. The code in Sugar Commander works, but I'd still
appreciate a review of this new information to be certain that I have
the details right.
Nice chapter :)
There is one serious flaw in your Sugar Commander code:
datastore.find({})
You should never call that find method without narrowing the results, at
least in production code. Since you only use specific properties, you should
tell the datastore to only return these. Otherwise, it will send megabytes of
unused preview data (and arbitrary meta data you cannot even anticipate) over
D-Bus if there are hundreds of Journal entries, which is not at all uncommon.
So the right way would be to write
ds_objects, num_objects = datastore.find({}, properties=['uid',
'title', 'mime_type', 'mountpoint'])
assuming those are the properties you need, which is not that much more
complicated. You always have to include 'uid', otherwise the find() method
breaks. Which is a bug IMHO ;)
For filtering by mountpoint, it's better to give this as a query argument
rather than fetching all entries and discarding the unwanted entries later:
query = {}
if mountpoint_id is not None:
query['mountpoints'] = [ mountpoint_id ]
ds_objects, num_objects = datastore.find(query, properties=['uid',
'title', 'mime_type'])
This is more efficient, but not as important as specifying the returned
properties.
The real Journal also employs the technique of only fetching the visible
entries, a page at a time, by adding 'limit' and 'offset' arguments to the
find call. This would complicate the discussion so it's okay to leave out I
guess. But narrowing the find() results to the needed properties is essential.
Later down you write Metadata entries for Journal objects alwayts [sic]
contain strings which is only true for Sugar 0.82. In Sugar 0.84 and later
the entries are actually byte arrays, not strings. This also makes this later
statement incorrect: ... since the Journal has never been able to store
binaries as metadata In fact, newer Sugar versions _do_ store the
preview as binary, not base64 encoded.
This is also not quite correct: the [preview] image file is always 320 x 240
pixels. The preview can actually be of arbitrary size, the recommended
resolution is (was?) 300 x 225 pixels, a quarter in each dimension of the
XO's 1200x900 screen size.
I also noticed some typos, but found the chapter too entertaining to write
them down ... just run a spell checker ;)
- Bert -
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] scalability in the neighborhood view
On Wed, Mar 24, 2010 at 8:38 PM, Frederick Grose fgr...@gmail.com wrote: http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups See http://wiki.sugarlabs.org/go/Design_Team/Proposals/Groups Thanks for the links. I re-read the spec and mockups. Looks like a fantastic start. Brief comments - For closed groups managed by Moodle/XS, it would make things easier for teacher if we could to read a URL from the group description field, and show an icon that links there (opening Browse.xo...) - The user management for closed groups already exists in Moodle (but looks moodlish instead of Sugarish). This is in case Tomeu is lazy ;-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal Backup/Restore UI
On Sun, Mar 28, 2010 at 2:29 PM, Bernie Innocenti ber...@codewiz.org wrote: On Sun, 2010-03-28 at 14:14 +0200, Tomeu Vizoso wrote: I'm a bit confused, is the problem reliable full restore with limited local space or the DS having the xapian DB open while the copy happens? Or both? Both, but somehow we managed to solve them in a quick dirty way: Doesn't copy-to-journal skip all the ugly? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New Chapter in Make Your Own Sugar Activities needs review
This PDF has the Fun With The Journal chapter updated using Bert Freudenberg's suggestions. I've updated Sugar Commander based on these suggestions and it works better than ever, and thanks to Bert I understand parts of my own code that were mysterious before. http://objavi.flossmanuals.net/books/ActivitiesGuideSugar-en-2010.03.28-22.20.52.pdf James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal Backup/Restore UI
On Sun, 2010-03-28 at 20:08 +0200, Martin Langhoff wrote: On Sun, Mar 28, 2010 at 2:29 PM, Bernie Innocenti ber...@codewiz.org wrote: On Sun, 2010-03-28 at 14:14 +0200, Tomeu Vizoso wrote: I'm a bit confused, is the problem reliable full restore with limited local space or the DS having the xapian DB open while the copy happens? Or both? Both, but somehow we managed to solve them in a quick dirty way: Doesn't copy-to-journal skip all the ugly? Oh, well, indeed. Though we need to figure out how to glue it to the rsync back-end. The easy part is binding rsync to Python: this was already done in duplicity by wrapping librsync with simple C and Python code which we could steal. Then it starts to get hard: the files are probably going to come down from the xs in some random order. librsync provides a sophisticated callback interface, but there seems to be also a whole-file interface. This approach also opens other interesting possibilities such as restoring individual files or merging the backup with the current journal contents. However, it looks like it would take a couple of months of effort to get something like this done. For the time being, we could keep using the plain rsync and maybe just add a stop/resume interface to the datastore? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal Backup/Restore UI
On Sun, 2010-03-28 at 21:22 -0300, Bernie Innocenti wrote: Oh, well, indeed. Though we need to figure out how to glue it to the rsync back-end. The easy part is binding rsync to Python: this was already done in duplicity by wrapping librsync with simple C and Python code which we could steal. Wait, I had overlooked this note: librsync does not speak the (hairy) application-specific protocol used by rsync. They only share an algorithm, not any code. This rules it out for our usecase, unless we also want to rewrite the xs backend. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Status of printing support?
Sorry about the long hiatus. I Had to go places for my thesis; almost done with Engg. school. Daniel, would be nice if you can update me with what you've worked out on. I will be free full time, and will definitely work on integrating it. Regards, Vamsi On Fri, Mar 5, 2010 at 10:35 PM, Daniel Castelo dcast...@plan.ceibal.edu.uy wrote: I have spoken with the developers of the GoSC [1] Andres Ambrois and Vamsi Krishna Davuluri about this topic, some time ago I've spoken with Tomeu too. I have read the discussion about this topic on the list [2] and I am not sure if the community has a consensus about the solution. About GoSC, I have tested the Print activity and works fine. I've wrote a new wiki page about this feature, with the goal of separate the work done on GoSC and the feature that we want in Sugar [3]. A solution could be add an option to the journal to print some types of entries. Here in Uruguay the first goal is to bring the possibility of print using a local printer. I know that Vamsi wants to work on this feature, and obviously me too. Finally, sorry for the delay! [1] http://wiki.sugarlabs.org/go/Summer_of_Code/2009/Print_Support [2] http://lists.sugarlabs.org/archive/sugar-devel/2009-April/013921.html http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014166.html [3] http://wiki.sugarlabs.org/go/Features/Print_Support On Sun, Feb 28, 2010 at 6:11 PM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, since a teacher at the Austrian pilot project asked whether Sugar would support printing in the forseeable I was wondering what the current status in this area was? Last time I checked (back in August) the GSoC project hadn't evolved beyond a very early prototype that I personally couldn't get to run. Looking around the mailing list and the wiki I couldn't find any updated information so is it safe to assume that little to no progress has been made in that area? Or did I simply miss something? Also I remember Daniel from Plan Ceibal talking about the desire to make that happen based on demands from Uruguay. @Daniel, any news from South America when it comes to this? Thanks in advance, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] unable to share Activities on XO-1.5
Many people here in DC tried to share Sugar Activities (during the XO-1.5 Getting Started Documentation Sprint this weekend), but were unable to proceed, and unable to take the required screenshots to document this functionality. Below is a sample problem report. What workarounds might they try? Thanks! We (GH SU) had access to multiple XO-1.5's for the first time. Attempting to upgrade the manual page http://laptop.org/7.1.0/gettingstarted/sharing.shtml we were (consistently) unable to make this Activity sharing happen. Whereas we've both succeeded with the XO-1, several times. Testing setup: 2 XO-1.5, both SKU99 (early production units) Software: Build 116 Sugar 0.84.14 Firmware Q3A35 Wireless Firmware 9.70.7.p0 We tested this with cable and wifi both. Chat was never really working on the joining computer. Greatest success (like in the picture) was the message that the other host connected, but no actual text transmitted... Abiword worked but only after 2min of waiting (and only with wifi). The invitation mode never worked. inline: chat_1mindelay.png___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] unable to share Activities on XO-1.5
G'day Adam, http://laptop.org/7.1.0/gettingstarted/sharing.shtml is correct as far as it goes, and is the method I've used to test sharing between two XO-1.5 running os116. I didn't experience any difficulty, but the sharing does depend on the environment. I've had it working via ad-hoc Create new wireless network and via access point. I've no cable available. There are several ways it can fail, but the sample problem report suggests that a slow or lossy network (Abiword in two minutes) was the main problem. The usual causes of a slow or lossy network are radiofrequency interference or other wireless traffic nearby. I'd like to know if the XO-1 was tested in the same location and at the same time, and if so whether the XO-1's were configured or had settled on mesh channel 1. Further diagnosis of the problem is certainly possible using shell tools in the Terminal window, but I'm not sure if you want that level of detail. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New Chapter in Make Your Own Sugar Activities needs review
On Sun, Mar 28, 2010 at 16:26, James Simmons nices...@gmail.com wrote: This PDF has the Fun With The Journal chapter updated using Bert Freudenberg's suggestions. I've updated Sugar Commander based on these suggestions and it works better than ever, and thanks to Bert I understand parts of my own code that were mysterious before. Ah, lots of goodies, indeed. I have an idea that we can improve the presentation and sequencing of ideas to make this easier on the reader who knows Python but not Sugar. It will take me a little while to work through it, and I have some writing of my own to catch up on. I'll see what I can do next week. http://objavi.flossmanuals.net/books/ActivitiesGuideSugar-en-2010.03.28-22.20.52.pdf James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://www.earthtreasury.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
