[Sugar-devel] [ANNOUNCE] [ASLO] Suggest users proper activity version to download
Hi all, Current version of activities.sugarlabs.org analyzes Browse version and suggests proper activity version to download. So, click on Download button and activity page(e.g. [1]) will provide activity version compatible with current user's environment. The full list of activity versions on all Sugar Platforms still exists in Version History list (e.g. [2]). [1] http://activities.sugarlabs.org/en-US/sugar/addon/4024 [2] http://activities.sugarlabs.org/en-US/sugar/addons/versions/4024 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] community influence on development
Walter Bender walter.ben...@gmail.com writes: Maybe someone more deployment oriented should run for the Oversight Board to ensure we have better representation there (http://wiki.sugarlabs.org/go/Sugar_Labs/Governance/Oversight_Board/2009-2010-candidates). I jumped in. I hesitated because I won't be reachable from now till August, 17th, and I will be poorly connected till the end of August. Let me know if that makes my application irrelevant. Regards, -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] safer customization key (was Re: will the one true browse please stand up?)
On Fri, Jul 31, 2009 at 20:23, Daniel Draked...@laptop.org wrote: 2009/7/31 Joshua N Pritikin jpriti...@pobox.com: On Fri, Jul 31, 2009 at 03:52:06PM +0545, Daniel Drake wrote: 2009/7/31 Joshua N Pritikin jpriti...@pobox.com: That was not my experience. Where does the customization key code live in GIT? Here: http://dev.laptop.org/git/users/mstone/irfs-udebs/tree/src-olpc/init?h=unpack-bundles Well, I'd feel a lot better if prior to the unzip you added something like: if ext == '.xo': dest_dir = re.sub(r'\-\d+\.xo$', '', f) + '.activity' shutil.rmtree(join(tgt['.xo'], dest_dir)) I know this does not work as written because the filename can (and often does) mismatch unzip's idea of the directory name. Any idea how to get directory prefix from the zip? The customization key has always been sweet and simple like this; I don't suggest changing it as some deployments rely on this. Documenting the limitations would be sensible, though. In my opinion the real solution is moving away from .xo which has outgrown its original design... What do you propose doing? Thanks, Tomeu Daniel ___ 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] [RELEASE] Browse-110
On Fri, Jul 31, 2009 at 20:38, Sayamindu Dasguptasayami...@gmail.com wrote: Hi, I think the version jump is intentional to allow for intermediate stable releases targetted for 0.84 if the need arises. If someone finds a critical issue in Browse 103, Simon can always release 104 with the fix and nothing more. One day we may be able to agree in a different numbering scheme ;) Regards, Tomeu -sdg- On Fri, Jul 31, 2009 at 11:40 PM, Christoph Derndorferchristoph.derndor...@gmail.com wrote: Out of curiosity: How did we end up at Browse-110? Maybe I missed something here but wasn't the latest version 102, 103 or something when this issue was last discussed less than 72 hours ago? Slightly confused, Christoph On Fri, Jul 31, 2009 at 8:04 PM, Simon Schampijer si...@schampijer.de wrote: == Source == http://download.sugarlabs.org/sources/sucrose/fructose/Browse/Browse-110.tar.bz2 == News == Toolbar redesign ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ 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] Need Help: usb drive not visible in the journal
Hi all, I am facing a sort of weird problem at this point. On my xo, my usb drives are not visible in the journal. I mean the icons at the bottom of the journal are not visible. However, to my surprise my usb drives(pendrives) are mounted and I can access them from the terminal. I have tested it with 3 pen drives so I don't think its due to my pen drive. Moreover, these pen drives are not even visible in the objectChooser widget when I invoke it through any of the xo activities like write or paint. Can anybody please suggest me a solution. Moreover, is there any way to access the data in the journal through the terminal, I mean there are many activities which saves data into the journal and I am in severe need to access that data. Is there any way to do so. I got this link- http://wiki.laptop.org/go/Copy_to_and_from_the_Journal#Copy_from_Journal_script , but I think the names of files are hashed and I won't be able to recognize my file in this case. Kindly give your suggestions. Regards, sumit ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Need Help: usb drive not visible in the journal
What version of Sugar are you running? re copy-from-journal, if you use the -q flag, it will search on the title and description fields. copy-from-journal -q 'title of some journal object' filename with copy-to-journal, it is it important to use a -m flag copy to journal foo.png -m image/png -walter On Sat, Aug 1, 2009 at 6:46 AM, sumit singhsumit.co...@gmail.com wrote: Hi all, I am facing a sort of weird problem at this point. On my xo, my usb drives are not visible in the journal. I mean the icons at the bottom of the journal are not visible. However, to my surprise my usb drives(pendrives) are mounted and I can access them from the terminal. I have tested it with 3 pen drives so I don't think its due to my pen drive. Moreover, these pen drives are not even visible in the objectChooser widget when I invoke it through any of the xo activities like write or paint. Can anybody please suggest me a solution. Moreover, is there any way to access the data in the journal through the terminal, I mean there are many activities which saves data into the journal and I am in severe need to access that data. Is there any way to do so. I got this link- http://wiki.laptop.org/go/Copy_to_and_from_the_Journal#Copy_from_Journal_script , but I think the names of files are hashed and I won't be able to recognize my file in this case. Kindly give your suggestions. Regards, sumit ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Additional data for corrupted SoaS
BTW, the SoaS Caroline gave me on SugarCamp (thanks!) is quite unreliable in one of my computers (it also confirms my suspection about the trouble she was having with my Assimilator software: hardware flakeyness). If you're using this run of sticks at the GPA, you can add it to the list of potential causes for stick failure. As you're about to buy the next run: Do you have a sample model that you can try out in lots of different computers? Just run the following command in Linux, with only the to-be-tested USB stick plugged in: dd if=/dev/disk/by-id/usbpress TAB once of=/dev/null e.g. for the stick mentioned above: dd if=/dev/disk/by-id/usb-CHIPSBNK_USB_2.0_260917004B813900-0\:0 of=/dev/null If there's a problem, an error message will be printed as part of the output: sascha.si...@twin:~$ dd if=/dev/disk/by-id/usb-CHIPSBNK_USB_2.0_260917004B813900-0\:0 of=/dev/null dd: reading `/dev/disk/by-id/usb-CHIPSBNK_USB_2.0_260917004B813900-0:0': Input/output error 468448+0 records in 468448+0 records out 239845376 bytes (240 MB) copied, 14.7675 s, 16.2 MB/s sascha.si...@twin:~$ If it's sucessfull, the whole stick will have been read: sascha.si...@elaine:~$ dd if=/dev/disk/by-id/usb-CHIPSBNK_USB_2.0_260917004B813900-0\:0 of=/dev/null 2046976+0 records in 2046976+0 records out 1048051712 bytes (1.0 GB) copied, 67.108 s, 15.6 MB/s sascha.si...@elaine:~$ CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Bugs] #1117 NORM: Image collection from Museum of Fine Arts in Boston
On Sat, Aug 01, 2009 at 12:33:22PM -, SugarLabs Bugs wrote: #1117: Image collection from Museum of Fine Arts in Boston +--- Reporter: walter | Owner: tomeu Type: enhancement | Status: new Priority: Normal | Milestone: Unspecified by Release Team Component: sugar|Version: Unspecified Severity: Unspecified | Keywords: Distribution: Unspecified | Status_field: Unconfirmed +--- If anyone is interested in taking it on, I have permission from the Museum of Fine Arts in Boston to distribute 100 pictures from their collection --kid-oriented images. We never finished packaging them while I was at OLPC, but it would make a nice content bundle to include. I will need to review the final packaging details with the Museum, but I suspect that they will be more than willing to let us distribute them as part of Sugar, not just part of OLPC. I guess we should speed up process of creating library.sugarlabs.org in that case. I see two points here: * merge(in some form) Objects Bundles [1] to last sugar and backport it to 0.84(0.82?) * choosing the way to deploy these Object Bundles [2] In case of [1], in email thread[3] there are suggestions to utilize existed(non-sugar) data formats to packages Objects Bundles, I think we can start from simple(and already utilized in sugar) INI .info format. Later(even in 0.86 release cycle), after getting feedback of using library.sugarlabs.org we can switch to something different. In case of [2], I've heard about two(?) options: * Moodle on XS * Mozilla framework which already using for ASLO [1] http://wiki.sugarlabs.org/go/Features/Object_Bundles [2] http://wiki.sugarlabs.org/go/Features/Server_Objects_Sharing [3] http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06874.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Bugs] #1117 NORM: Image collection from Museum of Fine Arts in Boston
On Sat, Aug 01, 2009 at 12:58:09PM +, Aleksey Lim wrote: On Sat, Aug 01, 2009 at 12:33:22PM -, SugarLabs Bugs wrote: #1117: Image collection from Museum of Fine Arts in Boston +--- Reporter: walter | Owner: tomeu Type: enhancement | Status: new Priority: Normal | Milestone: Unspecified by Release Team Component: sugar|Version: Unspecified Severity: Unspecified | Keywords: Distribution: Unspecified | Status_field: Unconfirmed +--- If anyone is interested in taking it on, I have permission from the Museum of Fine Arts in Boston to distribute 100 pictures from their collection --kid-oriented images. We never finished packaging them while I was at OLPC, but it would make a nice content bundle to include. I will need to review the final packaging details with the Museum, but I suspect that they will be more than willing to let us distribute them as part of Sugar, not just part of OLPC. I guess we should speed up process of creating library.sugarlabs.org in that case. I see two points here: * merge(in some form) Objects Bundles [1] to last sugar and backport it to 0.84(0.82?) ..and of course we can use .xol bundles that should work on all sugars * choosing the way to deploy these Object Bundles [2] In case of [1], in email thread[3] there are suggestions to utilize existed(non-sugar) data formats to packages Objects Bundles, I think we can start from simple(and already utilized in sugar) INI .info format. Later(even in 0.86 release cycle), after getting feedback of using library.sugarlabs.org we can switch to something different. In case of [2], I've heard about two(?) options: * Moodle on XS * Mozilla framework which already using for ASLO [1] http://wiki.sugarlabs.org/go/Features/Object_Bundles [2] http://wiki.sugarlabs.org/go/Features/Server_Objects_Sharing [3] http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06874.html -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On 31 Jul 2009, at 10:54, Simon Schampijer wrote: 1). I was hoping for more feedback before we lock things down, but it's been pretty quiet. I was hoping to hack TurtleArt with a temporary toolbar imitation and get some real usability input from kids, but not sure we have the time? We land it today, Browse and Write are ready, so we can get feedback on them. From the schedule we still have a bit of time. So I am positive. 2). Is it possible to have the title entry input field default width set to allow for 9 icons on the right (this is the maximum needed for current Activity designs), then allow it scale down to some min width if extra icons are added? I would rather there was a little flexibility in the title entry rather than have the Stop and Keep buttons be the first to disappear. Looks like we are over this point, following the other discussions in this thread. 3). FWIW, I'm considering the share with icon should really be over on the right (if sharing feature are present). So the far right icon order would be share with, keep version, stop. Same here. Btw - we went at the moment for eben's design. Gary, we could use your design (with title entry in the top) and test it out, if you think it is worth doing comparing tests. Let's get feedback with what has been implemented so far and iterate on it if there are agreed issues. My main concern at the moment is that we have complicated the trivial Activity case, in that there is no longer an option for just providing a single main toolbar. Every Activity has to now deal with loss of canvas space and dynamic resizing caused by the secondary activity toolbar design (that's one reason I didn't like that path). Who is the poor soul that's going to have to sort out TamTamMini, I vote for alsroot ;-b Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How big might a full install of Fedora Sugar be?
2009/7/31 Mathieu Bridon (bochecha) boche...@fedoraproject.org: What about doing a F11 GNOME install to a large USB drive, yum installing Sugar stuff, removing the unwanted bits, resizing the partitions to desirable size, and then dd ing that to a desirable USB stick (marked bootable) as a master img? And do that process again each time you want to release an updated image ? Use a kickstart file, create the master image with pungi, then let it install itself automatically on the USB sticks. That's exactly what Sebastian has been doing with SoaS, except he created live images when you want installed systems. For the non-fedora people A kickstart file is a list of packages which you want to install. You first create the kickstart file using a tool called pungi. Then you put the kickstart file on your install DVD. So, whenever you do an install with that dvd you get the package set defined in the kickstart file. This is how the xs image is create. The xs team takes a few standard rpm files and modify them to meet the usecases intended for the xs and stick those file in a xs repo. Then they create a kickstart file listing the files that want to install. To save space they really limit the required packages. Then they tell kickstart to first in the xs repo and second in standard fedora repo for packages packages. There is a step of creating a special package to run post install configure scripts. But don't think too hard about that it is enough to make your head explode. So there is no 'set' size for an install hope that helps david Mathieu Bridon (bochecha) ___ 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] safer customization key (was Re: will the one true browse please stand up?)
2009/8/1 Tomeu Vizoso to...@sugarlabs.org: What do you propose doing? Leaving packaging to the experts (the distributions) and focusing on being a good upstream -- only stepping into the packaging areas where the distro people are lacking. I think activities should be packaged by distros and we should use their standard systems, which have already solved this class of problem 5 times over. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Sat, Aug 01, 2009 at 02:12:50PM +0100, Gary C Martin wrote: On 31 Jul 2009, at 10:54, Simon Schampijer wrote: 1). I was hoping for more feedback before we lock things down, but it's been pretty quiet. I was hoping to hack TurtleArt with a temporary toolbar imitation and get some real usability input from kids, but not sure we have the time? We land it today, Browse and Write are ready, so we can get feedback on them. From the schedule we still have a bit of time. So I am positive. 2). Is it possible to have the title entry input field default width set to allow for 9 icons on the right (this is the maximum needed for current Activity designs), then allow it scale down to some min width if extra icons are added? I would rather there was a little flexibility in the title entry rather than have the Stop and Keep buttons be the first to disappear. Looks like we are over this point, following the other discussions in this thread. 3). FWIW, I'm considering the share with icon should really be over on the right (if sharing feature are present). So the far right icon order would be share with, keep version, stop. Same here. Btw - we went at the moment for eben's design. Gary, we could use your design (with title entry in the top) and test it out, if you think it is worth doing comparing tests. Let's get feedback with what has been implemented so far and iterate on it if there are agreed issues. My main concern at the moment is that we have complicated the trivial Activity case, in that there is no longer an option for just providing a single main toolbar. Every Activity has to now deal with loss of canvas space and dynamic resizing caused by the secondary activity toolbar design (that's one reason I didn't like that path). Who is the poor soul that's going to have to sort out TamTamMini, I vote for alsroot ;-b Well, I have around 14(including TamTamMini) activities on git.sl.o to switch to new toolbars.. so you can wish me luck. Regards, --Gary -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How big might a full install of Fedora Sugar be?
What about doing a F11 GNOME install to a large USB drive, yum installing Sugar stuff, removing the unwanted bits, resizing the partitions to desirable size, and then dd ing that to a desirable USB stick (marked bootable) as a master img? And do that process again each time you want to release an updated image ? Use a kickstart file, create the master image with pungi, then let it install itself automatically on the USB sticks. That's exactly what Sebastian has been doing with SoaS, except he created live images when you want installed systems. For the non-fedora people A kickstart file is a list of packages which you want to install. You first create the kickstart file using a tool called pungi. Then you put the kickstart file on your install DVD. So, whenever you do an install with that dvd you get the package set defined in the kickstart file. Just to be the boring pedantic guy who loves correcting people: you actually first write the kickstart file (manually, or using system-config-kickstart) and then feed it to pungi who will take all the infos in the kickstart file and generate the isos. But the rest of your message still holds true :) This is how the xs image is create. The xs team takes a few standard rpm files and modify them to meet the usecases intended for the xs and stick those file in a xs repo. Then they create a kickstart file listing the files that want to install. To save space they really limit the required packages. Then they tell kickstart to first in the xs repo and second in standard fedora repo for packages packages. There is a step of creating a special package to run post install configure scripts. But don't think too hard about that it is enough to make your head explode. So there is no 'set' size for an install hope that helps -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Sat, Aug 01, 2009 at 03:19:46PM +0100, Gary C Martin wrote: On 1 Aug 2009, at 14:51, Aleksey Lim wrote: On Sat, Aug 01, 2009 at 02:12:50PM +0100, Gary C Martin wrote: On 31 Jul 2009, at 10:54, Simon Schampijer wrote: 1). I was hoping for more feedback before we lock things down, but it's been pretty quiet. I was hoping to hack TurtleArt with a temporary toolbar imitation and get some real usability input from kids, but not sure we have the time? We land it today, Browse and Write are ready, so we can get feedback on them. From the schedule we still have a bit of time. So I am positive. 2). Is it possible to have the title entry input field default width set to allow for 9 icons on the right (this is the maximum needed for current Activity designs), then allow it scale down to some min width if extra icons are added? I would rather there was a little flexibility in the title entry rather than have the Stop and Keep buttons be the first to disappear. Looks like we are over this point, following the other discussions in this thread. 3). FWIW, I'm considering the share with icon should really be over on the right (if sharing feature are present). So the far right icon order would be share with, keep version, stop. Same here. Btw - we went at the moment for eben's design. Gary, we could use your design (with title entry in the top) and test it out, if you think it is worth doing comparing tests. Let's get feedback with what has been implemented so far and iterate on it if there are agreed issues. My main concern at the moment is that we have complicated the trivial Activity case, in that there is no longer an option for just providing a single main toolbar. Every Activity has to now deal with loss of canvas space and dynamic resizing caused by the secondary activity toolbar design (that's one reason I didn't like that path). Who is the poor soul that's going to have to sort out TamTamMini, I vote for alsroot ;-b Well, I have around 14(including TamTamMini) activities on git.sl.o to switch to new toolbars.. so you can wish me luck. Good luck! Quick question: Are you going to try and support existing deployments and keep and maintain both toolbar implementations? That is certainly (but painfully) my plan, as that's where 99.9% of our users are. You might need to wish me luck as well, as I'm not half as code prolific as you ;-) I have secret weapon, sugar-port[1] for that purpose :) [1] http://wiki.sugarlabs.org/go/Development_Team/sugar-port Regards, --Gary -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On 1 Aug 2009, at 14:51, Aleksey Lim wrote: On Sat, Aug 01, 2009 at 02:12:50PM +0100, Gary C Martin wrote: On 31 Jul 2009, at 10:54, Simon Schampijer wrote: 1). I was hoping for more feedback before we lock things down, but it's been pretty quiet. I was hoping to hack TurtleArt with a temporary toolbar imitation and get some real usability input from kids, but not sure we have the time? We land it today, Browse and Write are ready, so we can get feedback on them. From the schedule we still have a bit of time. So I am positive. 2). Is it possible to have the title entry input field default width set to allow for 9 icons on the right (this is the maximum needed for current Activity designs), then allow it scale down to some min width if extra icons are added? I would rather there was a little flexibility in the title entry rather than have the Stop and Keep buttons be the first to disappear. Looks like we are over this point, following the other discussions in this thread. 3). FWIW, I'm considering the share with icon should really be over on the right (if sharing feature are present). So the far right icon order would be share with, keep version, stop. Same here. Btw - we went at the moment for eben's design. Gary, we could use your design (with title entry in the top) and test it out, if you think it is worth doing comparing tests. Let's get feedback with what has been implemented so far and iterate on it if there are agreed issues. My main concern at the moment is that we have complicated the trivial Activity case, in that there is no longer an option for just providing a single main toolbar. Every Activity has to now deal with loss of canvas space and dynamic resizing caused by the secondary activity toolbar design (that's one reason I didn't like that path). Who is the poor soul that's going to have to sort out TamTamMini, I vote for alsroot ;-b Well, I have around 14(including TamTamMini) activities on git.sl.o to switch to new toolbars.. so you can wish me luck. Good luck! Quick question: Are you going to try and support existing deployments and keep and maintain both toolbar implementations? That is certainly (but painfully) my plan, as that's where 99.9% of our users are. You might need to wish me luck as well, as I'm not half as code prolific as you ;-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] About the need for .xo bundles (again) (was Re: safer customization key (was Re: will the one true browse please stand up?))
On Sat, Aug 1, 2009 at 15:47, Daniel Draked...@laptop.org wrote: 2009/8/1 Tomeu Vizoso to...@sugarlabs.org: What do you propose doing? Leaving packaging to the experts (the distributions) and focusing on being a good upstream -- only stepping into the packaging areas where the distro people are lacking. I think activities should be packaged by distros and we should use their standard systems, which have already solved this class of problem 5 times over. They haven't solved the problems we want to solve and are probably not even interested in trying. I'm a bit suprised you are not aware of this, there was a whole session dedicated to this in the last FUDCon in boston. Anyone has a link to the minutes? Thanks, Tomeu Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Sat, Aug 1, 2009 at 16:33, Aleksey Limalsr...@member.fsf.org wrote: On Sat, Aug 01, 2009 at 03:19:46PM +0100, Gary C Martin wrote: On 1 Aug 2009, at 14:51, Aleksey Lim wrote: On Sat, Aug 01, 2009 at 02:12:50PM +0100, Gary C Martin wrote: On 31 Jul 2009, at 10:54, Simon Schampijer wrote: 1). I was hoping for more feedback before we lock things down, but it's been pretty quiet. I was hoping to hack TurtleArt with a temporary toolbar imitation and get some real usability input from kids, but not sure we have the time? We land it today, Browse and Write are ready, so we can get feedback on them. From the schedule we still have a bit of time. So I am positive. 2). Is it possible to have the title entry input field default width set to allow for 9 icons on the right (this is the maximum needed for current Activity designs), then allow it scale down to some min width if extra icons are added? I would rather there was a little flexibility in the title entry rather than have the Stop and Keep buttons be the first to disappear. Looks like we are over this point, following the other discussions in this thread. 3). FWIW, I'm considering the share with icon should really be over on the right (if sharing feature are present). So the far right icon order would be share with, keep version, stop. Same here. Btw - we went at the moment for eben's design. Gary, we could use your design (with title entry in the top) and test it out, if you think it is worth doing comparing tests. Let's get feedback with what has been implemented so far and iterate on it if there are agreed issues. My main concern at the moment is that we have complicated the trivial Activity case, in that there is no longer an option for just providing a single main toolbar. Every Activity has to now deal with loss of canvas space and dynamic resizing caused by the secondary activity toolbar design (that's one reason I didn't like that path). Who is the poor soul that's going to have to sort out TamTamMini, I vote for alsroot ;-b Well, I have around 14(including TamTamMini) activities on git.sl.o to switch to new toolbars.. so you can wish me luck. Good luck! Quick question: Are you going to try and support existing deployments and keep and maintain both toolbar implementations? That is certainly (but painfully) my plan, as that's where 99.9% of our users are. You might need to wish me luck as well, as I'm not half as code prolific as you ;-) I have secret weapon, sugar-port[1] for that purpose :) You mean each of those activities will ship with its own copy of the new toolbars? That's quite a bit scary from the support POV. Regards, Tomeu [1] http://wiki.sugarlabs.org/go/Development_Team/sugar-port Regards, --Gary -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Call for Help: SoaS Display Manager (Auto-Login)
On Fri, Jul 31, 2009 at 16:48, Sebastian Dziallassebast...@when.com wrote: Hi everybody, I could use a hand with auto-login on SoaS. We've been using slim so far but will switch in the near future (in fact, I already committed a change in GIT), as we also need to login automatically after killing / restarting X. Therefore, the most feasible solution seems to be olpc-dm from the olpc-utils right now. Unfortunately, I haven't been able to get it successfully to work and am lost with a black screen on tty1 so far. Looking at /var/log/message, the following stuff seems spurious: olpc-dm: Can't get tty name: inappropriate ioctl for device init: prefdm main process terminated with status 1 The occurs quite a few times and running initctl start prefdm manually from the console also gives a prefdm respawning too fast. On the other hand, running olpc-dm directly as root works, though. If anybody has an idea how to fix this, meaning to get auto-login to work again, any help is greatly appreciated. We can also provide the current snapshot pre-built as an .iso file, if required. Feel free to contact me directly, too. So did you got this working by yourself? Regards, Tomeu Thanks, --Sebastian Dziallas for the SoaS Team ___ 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] Initial implementation of toolbars design
On Sat, Aug 01, 2009 at 04:37:24PM +0200, Tomeu Vizoso wrote: On Sat, Aug 1, 2009 at 16:33, Aleksey Limalsr...@member.fsf.org wrote: On Sat, Aug 01, 2009 at 03:19:46PM +0100, Gary C Martin wrote: On 1 Aug 2009, at 14:51, Aleksey Lim wrote: On Sat, Aug 01, 2009 at 02:12:50PM +0100, Gary C Martin wrote: On 31 Jul 2009, at 10:54, Simon Schampijer wrote: 1). I was hoping for more feedback before we lock things down, but it's been pretty quiet. I was hoping to hack TurtleArt with a temporary toolbar imitation and get some real usability input from kids, but not sure we have the time? We land it today, Browse and Write are ready, so we can get feedback on them. From the schedule we still have a bit of time. So I am positive. 2). Is it possible to have the title entry input field default width set to allow for 9 icons on the right (this is the maximum needed for current Activity designs), then allow it scale down to some min width if extra icons are added? I would rather there was a little flexibility in the title entry rather than have the Stop and Keep buttons be the first to disappear. Looks like we are over this point, following the other discussions in this thread. 3). FWIW, I'm considering the share with icon should really be over on the right (if sharing feature are present). So the far right icon order would be share with, keep version, stop. Same here. Btw - we went at the moment for eben's design. Gary, we could use your design (with title entry in the top) and test it out, if you think it is worth doing comparing tests. Let's get feedback with what has been implemented so far and iterate on it if there are agreed issues. My main concern at the moment is that we have complicated the trivial Activity case, in that there is no longer an option for just providing a single main toolbar. Every Activity has to now deal with loss of canvas space and dynamic resizing caused by the secondary activity toolbar design (that's one reason I didn't like that path). Who is the poor soul that's going to have to sort out TamTamMini, I vote for alsroot ;-b Well, I have around 14(including TamTamMini) activities on git.sl.o to switch to new toolbars.. so you can wish me luck. Good luck! Quick question: Are you going to try and support existing deployments and keep and maintain both toolbar implementations? That is certainly (but painfully) my plan, as that's where 99.9% of our users are. You might need to wish me luck as well, as I'm not half as code prolific as you ;-) I have secret weapon, sugar-port[1] for that purpose :) You mean each of those activities will ship with its own copy of the new toolbars? That's quite a bit scary from the support POV. Well, not so much as you can think.. API for new toolbars won't be changed(I hope), so I need only `cp` proper sources from master repo(if it will contain fixed code) anyway I don't see another way except not using new toolbars at all. I'm personally dislike idea of having several branches in that particular case where there is no changes in activity code but only changes in 3rd party components. Regards, Tomeu [1] http://wiki.sugarlabs.org/go/Development_Team/sugar-port Regards, --Gary -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
On Sat, Aug 1, 2009 at 04:17, Samuel Kleinmeta...@gmail.com wrote: Journal needs to cover these features (whatever they resolve to be). Every activity author should not be inventing various implementations of a book shelf UI concepts for dealing with a monoculture 'collection' of objects. Imagine if I wanted to put together a 'collection' of Physics simulations to teach curriculum, or some Turtle Art projects teaching the idea of vectors, or a mix of both along with a book or two and a Labyrinth mind-map of topic notes. What happens if an Activity wants to use the ObjectChooser to pick an object buried in someone else's collection. On Fri, Jul 24, 2009 at 6:57 PM, Sayamindu Dasgupta sayami...@gmail.com wrote: I do agree with you that it is the Journal which should be doing this, and not Read (except for maybe accessing online catalogs - though I think James has a better approach with his Get IA Books activity. It's just that, I'm a bit frustrated with the current state of the journal (especially for handling collections), and while xol-s are a great idea in theory, the practice of jumping through the browser (especially if Rainbow is enabled) is extremely crappy, IMHO :-). However, after going through all the mails, especially the links which Aleksey sent, I think it may be worthwhile to devote my coding cycles to the Journal instead. I disagree here. In theory, it is nice to imagine you might only need to solve a large # of similar interface and design problems once for every situation. In practice, it is really difficult to design a smooth, fast, rewarding interface for a general problem : a focused use case, and the freedom to make something work brilliantly for that case without having to demonstrate that it is a good design decision for all other parallel use cases, helps get something useful. I would expect to regularly want my bookshelf to be able to browse through hundreds of files at once, searching and autocompleting through their specific index; sort by book-specific metadata fields; and handle a collection 90% of which I am not storing locally -- possibly requesting a book from a repository off-disk, possibly keeping a fixed size on-disk library and having a process for queueing old books for local removal. Yes, an Ideal Journal might include these features. But I expect a Read -- Get IA Books activity might deal with this over the next year or two much more effectively than an a Journal being pulled in many directions. I don't see much value right now in speculating whether those features will come first from the journal or from activities. I agree that it'd be best if they appeared in the journal, and also agree it's better that they appear first in activities rather than not having them at all. But it all will depend at the end on who is willing to do the work and at which level. Doing so in activities makes it less complicated for the lone coder because can just code it, upload the bundle to ASLO and announce it. Doing it in the journal will benefit more use cases, but agreement with the rest of the community is needed before it can be released. Regards, Tomeu S. ___ 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] Call for Help: SoaS Display Manager (Auto-Login)
Tomeu Vizoso wrote: On Fri, Jul 31, 2009 at 16:48, Sebastian Dziallassebast...@when.com wrote: Hi everybody, I could use a hand with auto-login on SoaS. We've been using slim so far but will switch in the near future (in fact, I already committed a change in GIT), as we also need to login automatically after killing / restarting X. Therefore, the most feasible solution seems to be olpc-dm from the olpc-utils right now. Unfortunately, I haven't been able to get it successfully to work and am lost with a black screen on tty1 so far. Looking at /var/log/message, the following stuff seems spurious: olpc-dm: Can't get tty name: inappropriate ioctl for device init: prefdm main process terminated with status 1 The occurs quite a few times and running initctl start prefdm manually from the console also gives a prefdm respawning too fast. On the other hand, running olpc-dm directly as root works, though. If anybody has an idea how to fix this, meaning to get auto-login to work again, any help is greatly appreciated. We can also provide the current snapshot pre-built as an .iso file, if required. Feel free to contact me directly, too. So did you got this working by yourself? Yup, fixed! :) Thanks, --Sebastian Regards, Tomeu Thanks, --Sebastian Dziallas for the SoaS Team ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Need Help: usb drive not visible in the journal
Sumit, I've experienced this on my own XO. One thing I've found that helps in this situation is to remove the hidden file that Sugar puts on the drive. I think it's named .olpc, but in any case it begins with a period. Sometimes if this file is present the thumb drive will not appear to be mounted in the Journal, and other times you may have new content on the drive copied from a non-Sugar environment and it won't show up in the Journal. Removing this file can fix both problems. In any case, it should not harm anything.You can use the Terminal Activity to do it. James Simmons Date: Sat, 1 Aug 2009 16:16:39 +0530 From: sumit singh sumit.co...@gmail.com Subject: [Sugar-devel] Need Help: usb drive not visible in the journal To: sugar-devel@lists.sugarlabs.org, de...@lists.laptop.org, Tomeu Vizoso to...@sugarlabs.org Message-ID: b694aa9e0908010346o43d6ed38i2bbf01afaf59b...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi all, I am facing a sort of weird problem at this point. On my xo, my usb drives are not visible in the journal. I mean the icons at the bottom of the journal are not visible. However, to my surprise my usb drives(pendrives) are mounted and I can access them from the terminal. I have tested it with 3 pen drives so I don't think its due to my pen drive. Moreover, these pen drives are not even visible in the objectChooser widget when I invoke it through any of the xo activities like write or paint. Can anybody please suggest me a solution. Moreover, is there any way to access the data in the journal through the terminal, I mean there are many activities which saves data into the journal and I am in severe need to access that data. Is there any way to do so. I got this link- http://wiki.laptop.org/go/Copy_to_and_from_the_Journal#Copy_from_Journal_script , but I think the names of files are hashed and I won't be able to recognize my file in this case. Kindly give your suggestions. Regards, sumit ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Maintaining activities for older releases (was Re: Initial implementation of toolbars design)
On Sat, Aug 1, 2009 at 16:48, Aleksey Limalsr...@member.fsf.org wrote: On Sat, Aug 01, 2009 at 04:37:24PM +0200, Tomeu Vizoso wrote: On Sat, Aug 1, 2009 at 16:33, Aleksey Limalsr...@member.fsf.org wrote: On Sat, Aug 01, 2009 at 03:19:46PM +0100, Gary C Martin wrote: On 1 Aug 2009, at 14:51, Aleksey Lim wrote: On Sat, Aug 01, 2009 at 02:12:50PM +0100, Gary C Martin wrote: On 31 Jul 2009, at 10:54, Simon Schampijer wrote: 1). I was hoping for more feedback before we lock things down, but it's been pretty quiet. I was hoping to hack TurtleArt with a temporary toolbar imitation and get some real usability input from kids, but not sure we have the time? We land it today, Browse and Write are ready, so we can get feedback on them. From the schedule we still have a bit of time. So I am positive. 2). Is it possible to have the title entry input field default width set to allow for 9 icons on the right (this is the maximum needed for current Activity designs), then allow it scale down to some min width if extra icons are added? I would rather there was a little flexibility in the title entry rather than have the Stop and Keep buttons be the first to disappear. Looks like we are over this point, following the other discussions in this thread. 3). FWIW, I'm considering the share with icon should really be over on the right (if sharing feature are present). So the far right icon order would be share with, keep version, stop. Same here. Btw - we went at the moment for eben's design. Gary, we could use your design (with title entry in the top) and test it out, if you think it is worth doing comparing tests. Let's get feedback with what has been implemented so far and iterate on it if there are agreed issues. My main concern at the moment is that we have complicated the trivial Activity case, in that there is no longer an option for just providing a single main toolbar. Every Activity has to now deal with loss of canvas space and dynamic resizing caused by the secondary activity toolbar design (that's one reason I didn't like that path). Who is the poor soul that's going to have to sort out TamTamMini, I vote for alsroot ;-b Well, I have around 14(including TamTamMini) activities on git.sl.o to switch to new toolbars.. so you can wish me luck. Good luck! Quick question: Are you going to try and support existing deployments and keep and maintain both toolbar implementations? That is certainly (but painfully) my plan, as that's where 99.9% of our users are. You might need to wish me luck as well, as I'm not half as code prolific as you ;-) I have secret weapon, sugar-port[1] for that purpose :) You mean each of those activities will ship with its own copy of the new toolbars? That's quite a bit scary from the support POV. Well, not so much as you can think.. API for new toolbars won't be changed(I hope), so I need only `cp` proper sources from master repo(if it will contain fixed code) anyway I don't see another way except not using new toolbars at all. I'm personally dislike idea of having several branches in that particular case where there is no changes in activity code but only changes in 3rd party components. What is usually done in FOSS projects is to keep adding features in each new release, but only backport bugfixes to past releases, and that only if there's enough resources and interest. This is because all projects have limited resources but also have plans to move forward and expand the work done in every release. If we tell our users that new versions of activities are going to run on all versions of Sugar, this means that with every release we are going to have less resources to work on new releases because the number of platforms we need to support keep growing. We would be putting a hard limit on Sugar's growth. Given that right now we aren't able to properly maintain a single release, I see as very bold trying maintain all past releases and at the same time doing excellent new releases. To be clear, I'm not saying that we should drop support for our current users. Rather that if we want to scale, live up to expectations and give a good experience to users of past releases (most users) then we should figure out how our resources can grow at least as fast as our needs. One common way is to let downstreams support their own users. It's very cool that Uruguay wants their kids to use Sugar, and obviously the Sugar Labs community will be thrilled to be able to contribute so children there have access to better learning. But we'll be doing them a disservice if we let their government believe that a bunch of hippies around the world is going to support the software they use in the field, the newer software releases, and also the releases that other countries have decided to use. How I would expect this to work is that if Uruguay is using 0.82 and wants
Re: [Sugar-devel] Need Help: usb drive not visible in the journal
Hello sir, Thank You for your reply. On Sat, Aug 1, 2009 at 5:44 PM, Walter Benderwalter.ben...@gmail.com wrote: What version of Sugar are you running? I am on sugar 0.82 ( 767 build). It was working fine since the last 4-5 months but the problem started suddenly yesterday. re copy-from-journal, if you use the -q flag, it will search on the title and description fields. copy-from-journal -q 'title of some journal object' filename with copy-to-journal, it is it important to use a -m flag copy to journal foo.png -m image/png Yes, this should be of gr8 help. Would soon be trying it on the xo. Regards, sumit ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] safer customization key (was Re: will the one true browse please stand up?)
On Sat, Aug 1, 2009 at 8:47 AM, Daniel Draked...@laptop.org wrote: 2009/8/1 Tomeu Vizoso to...@sugarlabs.org: What do you propose doing? Leaving packaging to the experts (the distributions) and focusing on being a good upstream -- only stepping into the packaging areas where the distro people are lacking. I think activities should be packaged by distros and we should use their standard systems, which have already solved this class of problem 5 times over. We need to be careful about considering what class of problem each packaging method is trying to solve. The goal for traditional packaging methods was to ensure dependencies were being met, turning 'config; make; install' into a simpler operation, and doing various pre and post install configuration. This goal is inline with a core set of sugar packages. The goals of .xo files are rather different. For standard .xo bundle all of the dependcies should already be met. 'Config, make, install' is handled by bundle registry. .Xo files never interact directly with the underlying system. They only use Sugar, gnome, python, apis which should be guaranteed present by the core sugar dependences. This is very similar to the notion of pearl and python modules. On the flip side, traditional distro package methods require root access. .xo bundles are install within sugar space. Thus they can be installed by the user. This is similar to Mozilla addons. Mozilla uses another class of 'packages' called plugins. These are a bit more complicated these are a bit more complicated because plugins add additional system level functionality. Plugins are usually repackaged for Linux by the distros to ensure dependences are met. Have you followed the work alsroot is doing on the bundle registry? It is starting to provide some very good and consistent APIs for working with bundles. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] safer customization key (was Re: will the one true browse please stand up?)
Daniel Drake wrote: 2009/8/1 Tomeu Vizoso to...@sugarlabs.org: What do you propose doing? Leaving packaging to the experts (the distributions) and focusing on being a good upstream -- only stepping into the packaging areas where the distro people are lacking. I think activities should be packaged by distros and we should use their standard systems, which have already solved this class of problem 5 times over. The distros have solved the problem of efficiently installing untrusted packages created, modified and shared by the users, without root privileges, across all architectures? No. They have solved the problem of installing platform-specific trusted binaries, provided in an unmodifiable form by a central source, with full system administration privileges. The problem we are trying to solve is not merely a standard package installation problem, because Sugar is not merely Linux. Sugar's goal is to empower students to dive in and change how the system works. Otherwise we might as well use XFCE. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar on a Stick File Structure - Summary of problems and potential solutions
Here is a summary of how I see the problems and the solutions we are evaluating. Let me know if this is correct. Problems we'd like solve: To be acceptable a solution should solve all of these problems. 1. Reduce the frequency of sticks not being bootable after usage 2. Allow a VM system to read user files and thus allow us to create a VM that can switch users 3. Allow a user to put the stick into a windows/mac/linux machine and find their files 4. Ready for Sept deployment at GPA Things we wish to optimized 1. Ability to work with poor quality sticks 2. Size of stick needed 3. Amount of abuse the stick can take and still work 4. Size of download to create the stick 5. Time it takes to create the stick 6. Easy user experience creating the stick 7. Speed of the stick in use 8. Minimize development time invested in the immediate future 9. Familiar and easy to understand We expect different solutions to be different in terms of how they do on these criteria Solutions currently being considered: 1. Fixing the current system in some way? (Do we have a plan that uses the current file structure and solves all of the problems?) 2. Full install of Fedora 3. Switch to OpenSuse 4. Create a stick using Fedora code in the same way that OpenSuse creates their stick? (Is this a possibility?) 5. Trying to find a file system expert to deploy some sort of journaling file structure that is designed for robustness. -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.85.3
Hi, this release includes the new toolbar design. Congratulations to everybody that worked together to accomplish this. Now let's fix the bugs :) == Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.85.3.tar.bz2 == Fixed tickets == * #1102 Make the unfullscreen go away after a timeout * #955 mimetype database only updated when installing activities ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.85.3
Hi, this Sugar release restores Rainbow support, meaning that you can try and give feedback after installing Rainbow. == Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.85.3.tar.bz2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: [pygtk] ANNOUNCE: the return of pygtkscintilla
Hi, this might be interesting to activity authors and also for editing source in the shell. Regards, Tomeu -- Forwarded message -- From: gabriele.lan...@gmail.com Date: Sat, Aug 1, 2009 at 19:20 Subject: [pygtk] ANNOUNCE: the return of pygtkscintilla To: py...@daa.com.au Hi all, I've done a preliminary wrapping of pygtkscinitilla, I can compile and run a scintilla widget compatible with pygtk. ( Scintilla is a text editor widget rich of functionalities like autocompletion, folding, syntax highlighting etc...) I'm writing because I was searching for collaborators, there's some work to do: - web site page - testing and debugging - tuning the interface (eventually doing a redesign of the standard behaviour of scintilla) - packaging - documentation Tell me if there's someone that want to help and partecipate to the project. The project is hosted by sourceforge.net at this page: http://sourceforge.net/projects/pygtksci/ If you just want to test it immediatly tell me because I haven't already wrote the building instructions. Bye Bye - Gabriele Lanaro gabriele.lan...@gmail.com ___ pygtk mailing list py...@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Call for Help: SoaS Display Manager (Auto-Login)
Regarding getting auto-login to work after restarting X. Yesterday I looked at the slim sources and it seems at first sight easy to add auto login of the default user after the first login. Any interest in me trying to implement this? If we use an extra option to slim we could push this change upstream to Fedora and then we do not have to maintain our own manager (olpc-dm). But maybe Sebastian is already happy with a working olpc-dm. Ton van Overbeek ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on a Stick File Structure - Summary of problems and potential solutions
On Sat, Aug 1, 2009 at 1:20 PM, Caroline Meekscarol...@solutiongrove.com wrote: Here is a summary of how I see the problems and the solutions we are evaluating. Let me know if this is correct. Problems we'd like solve: To be acceptable a solution should solve all of these problems. Reduce the frequency of sticks not being bootable after usage Allow a VM system to read user files and thus allow us to create a VM that can switch users Allow a user to put the stick into a windows/mac/linux machine and find their files Ready for Sept deployment at GPA Things we wish to optimized Ability to work with poor quality sticks Size of stick needed Amount of abuse the stick can take and still work Size of download to create the stick Time it takes to create the stick Easy user experience creating the stick Speed of the stick in use Minimize development time invested in the immediate future Familiar and easy to understand We expect different solutions to be different in terms of how they do on these criteria Solutions currently being considered: Not clear that any of these are solutions. We need to understand the root causes of failures and then propose solutions. For example, my mentioning openSUSE to you at the GPA the other day was not to propose it as a solution, but rather, as another control in our testing regime. Fixing the current system in some way? (Do we have a plan that uses the current file structure and solves all of the problems?) Full install of Fedora Switch to OpenSuse Create a stick using Fedora code in the same way that OpenSuse creates their stick? (Is this a possibility?) Trying to find a file system expert to deploy some sort of journaling file structure that is designed for robustness. -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [Bugs] #1117 NORM: Image collection from Museum of Fine Arts in Boston
On Sat, Aug 1, 2009 at 8:01 AM, Aleksey Limalsr...@member.fsf.org wrote: On Sat, Aug 01, 2009 at 12:58:09PM +, Aleksey Lim wrote: On Sat, Aug 01, 2009 at 12:33:22PM -, SugarLabs Bugs wrote: #1117: Image collection from Museum of Fine Arts in Boston +--- Reporter: walter | Owner: tomeu Type: enhancement | Status: new Priority: Normal | Milestone: Unspecified by Release Team Component: sugar | Version: Unspecified Severity: Unspecified | Keywords: Distribution: Unspecified | Status_field: Unconfirmed +--- If anyone is interested in taking it on, I have permission from the Museum of Fine Arts in Boston to distribute 100 pictures from their collection --kid-oriented images. We never finished packaging them while I was at OLPC, but it would make a nice content bundle to include. I will need to review the final packaging details with the Museum, but I suspect that they will be more than willing to let us distribute them as part of Sugar, not just part of OLPC. I guess we should speed up process of creating library.sugarlabs.org in that case. I see two points here: * merge(in some form) Objects Bundles [1] to last sugar and backport it to 0.84(0.82?) ..and of course we can use .xol bundles that should work on all sugars * choosing the way to deploy these Object Bundles [2] In case of [1], in email thread[3] there are suggestions to utilize existed(non-sugar) data formats to packages Objects Bundles, I think we can start from simple(and already utilized in sugar) INI .info format. Later(even in 0.86 release cycle), after getting feedback of using library.sugarlabs.org we can switch to something different. In case of [2], I've heard about two(?) options: * Moodle on XS * Mozilla framework which already using for ASLO OLE Nepal has been working on a a content management system called pustakalaya at http://www.pustakalaya.org/ At first glance it shows great promise. It scales from small enough to run on a school server to large enough to serve an entire country. It is based on fedora commons, which is pretty stable. On the other hand, it does not have the upload content features that moodle or ASLO have. david [1] http://wiki.sugarlabs.org/go/Features/Object_Bundles [2] http://wiki.sugarlabs.org/go/Features/Server_Objects_Sharing [3] http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06874.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Screen Reposition?
First of two responses: I've discovered a related problem: I accidentally booted my XO with an SoaS USB drive in one of its slots. I didn't expect it to boot - *unaided* - into SoaS (which it did). Is this expected? At any rate, I found ordinary text (such as on the Terminal and Logs activities) to be unreadable (*too* small). I needed to remove my glasses and move to six inches from the screen before I could focus. I then ran my activity (or, rather, was able to view some of it on-screen, as csound with python is not yet working). Instead of displaying nicely like it does on native XO, it too displays in tiny type in the upper left-hand corner. In other words, there is the same problem of screen formatting as on my desktop system. I note the icons and graphics are nicely sized; but all plain text apparently not? This is a real problem that, IMHO, renders SoaS (i.e., later versions of Sugar) fairly useless on the XO. Is this issue being addressed? (If so, I haven't seen discussion on this list recently. And what does this mean for the future viability of the XO?) Art Hunkins - Original Message - From: Tomeu Vizoso to...@sugarlabs.org To: Art Hunkins abhun...@uncg.edu Cc: sugar-devel@lists.sugarlabs.org Sent: Saturday, August 01, 2009 10:47 AM Subject: Re: [Sugar-devel] Screen Reposition? On Fri, Jul 31, 2009 at 21:13, Art Hunkinsabhun...@uncg.edu wrote: I finally managed to see a mockup of my XO Activity on one of my SoaS setups (large monitor). As I feared, everything displayed in the upper left corner of the screen. I know this issue has been frequently discussed here. Can someone point me to the simplest python code for placing an XO screen-full square in the middle of any monitor display? No resizing (at least, not necessarily), just placement in mid-screen (vertically and horizontally). I've got some general ideas, but am not a coder - and my knowledge of PyGTK is skin-deep. If I understood correctly what you are asking, it will depend on how you are doing your drawing. Maybe you have the code online somewhere where we can see it? Regards, Tomeu Art Hunkins ___ 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 mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on a Stick File Structure - Summary of problems and potential solutions
My original response went only to you (it seems like I'm having more and more of this, sorry about that) so you in turn only replied to me. Here it is for all the list to benefit :) On Sun, Aug 2, 2009 at 01:12, Caroline Meekscarol...@solutiongrove.com wrote: All, This was my attempt to put together a list from the brainstorming we have been doing so we can all look at it, generate more ideas and decide which ones we can eliminate. Hi Mathieu, Thanks, I didn't know that a full install still wouldn't be readable on a windows machine. I;d be interested if anyone has any ideas. Its not unusual for things you want to optimize to be correlated negatively or positively. Also the things to be optimized are not necessarily things that are wrong with the current system for instance it excels at size. Mathieu, can you tell me more or point me to documentation about the Overlay? Jeremy Katz, one of the Fedora devs that worked on the liveCD/USB technology we use in Fedora already answered and shared some light in the other thread where you were asking for more information (I had put him in CC). You should definitely bounce on his answer if you still need more, I think he's one of the people with the most knowledge on this matter :) Walter, We are clearly mis understanding each other somewhere. Would it help if I changed Solutions currently being considered: to Potential Solutions we are currently considering testing to see if they work and how they compare on the things we want to optimize for: I'll start another thread about failures and what we know about them within the next 48 hours. Walter, can your OpenSuse USB can be read by Windows? Except if the OpenSUSE key uses FAT32 (or NTFS) as a filesystem, I doubt it will (and I really doubt those are used on a Linux live system :) On Sat, Aug 1, 2009 at 6:46 PM, Mathieu Bridon (bochecha) boche...@fedoraproject.org wrote: Hi, To be acceptable a solution should solve all of these problems. 2. Allow a VM system to read user files and thus allow us to create a VM that can switch users 3. Allow a user to put the stick into a windows/mac/linux machine and find their files This is always going to be a problem. For exemple, the default Linux filesystem (at least on Fedora) is ext3 or ext4. Windows can't read those filesystems (without adding some experimental software), so even a full install will not solve this issue. Things we wish to optimized 1. Ability to work with poor quality sticks 3. Amount of abuse the stick can take and still work Those 2 seem rather contradictory, and I'm not sure there's a lot that can be done in software, at least in Sugar world :) 2. Size of stick needed 4. Size of download to create the stick 5. Time it takes to create the stick Those three are intimately related. If we can make the image as small as possible, it should be faster to create it. 6. Easy user experience creating the stick What exactly are the problems ? Speaking only for myself, I never had a problem creating a SoaS USB (but I might not be representative of your target population :). Were all usability issues reported upstream ? https://fedorahosted.org/liveusb-creator/ Live USB Creator works great! Its been a tremendous boon in getting people to try Sugar. I did report a bug, I think it was fixed. I don't know if you are behind the LiveUSB creator for windows but please tell whoever did it thank you! However, our Sugar on a Stick in a classroom use case will require us to create our own. We need something that lets a teacher pick what activities and language the kids should have and probably preload some content then clone sticks with all those settings but without the name and the key we use for collaboration. We'll want something that works from within Sugar. We'd love help with this project! A teacher will need to make 20-30 sticks or if they are the computer teacher for the whole school (this is common in the US) 100-300 sticks. We would thus like something that can use a standard cheap 4-8 USB port and create multiple USB sticks without user intervention between sticks. Do you know of any existing solutions for that? Solutions currently being considered: 2. Full install of Fedora As I said, this will not fix the issue of accessing files from Windows (no idea from Mac OS X). Darn! -- Mathieu Bridon (bochecha) -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax Best regards, -- Mathieu Bridon (bochecha) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Screen Reposition?
Second of two responses: Attached is my activity, OurMusic-1.xo. As it is, it gives a partial display on SoaS of the reduced screen layout (upper-left corner). The basic python script that illustrates my (very) basic coding is ourmusic.py. (Notice my dependence on text!) It, of course, doesn't actually work because of the problem of Csound with python. If you'd like to see it running as intended, install it on the XO - but first enable three lines in csndsugui.py: take out the leading #'s in these three spots: in the install csnd toward the beginning; in the two lines toward the end of the file. In terms of my coding style, except for the opening header text, it's basically boxes packed within boxes all the way through. FWIW, if the text remains the size it is (with SoaS on the XO), I'd guess this activity just wouldn't work in this context. I'd appreciate any and all suggestions/comments - of course, *especially* how best to deal with screen reposition (if not default type size). Art Hunkins - Original Message - From: Tomeu Vizoso to...@sugarlabs.org To: Art Hunkins abhun...@uncg.edu Cc: sugar-devel@lists.sugarlabs.org Sent: Saturday, August 01, 2009 10:47 AM Subject: Re: [Sugar-devel] Screen Reposition? On Fri, Jul 31, 2009 at 21:13, Art Hunkinsabhun...@uncg.edu wrote: I finally managed to see a mockup of my XO Activity on one of my SoaS setups (large monitor). As I feared, everything displayed in the upper left corner of the screen. I know this issue has been frequently discussed here. Can someone point me to the simplest python code for placing an XO screen-full square in the middle of any monitor display? No resizing (at least, not necessarily), just placement in mid-screen (vertically and horizontally). I've got some general ideas, but am not a coder - and my knowledge of PyGTK is skin-deep. If I understood correctly what you are asking, it will depend on how you are doing your drawing. Maybe you have the code online somewhere where we can see it? Regards, Tomeu Art Hunkins ___ 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 OurMusic-1.xo Description: Binary data ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Additional data for corrupted SoaS
On Sat, Aug 01, 2009 at 02:40:08PM +0200, Sascha Silbe wrote: BTW, the SoaS Caroline gave me on SugarCamp (thanks!) is quite unreliable in one of my computers (it also confirms my suspection about the trouble she was having with my Assimilator software: hardware flakeyness). If you're using this run of sticks at the GPA, you can add it to the list of potential causes for stick failure. As you're about to buy the next run: Do you have a sample model that you can try out in lots of different computers? Just run the following command in Linux, with only the to-be-tested USB stick plugged in: dd if=/dev/disk/by-id/usbpress TAB once of=/dev/null e.g. for the stick mentioned above: dd if=/dev/disk/by-id/usb-CHIPSBNK_USB_2.0_260917004B813900-0\:0 of=/dev/null If there's a problem, an error message will be printed as part of the output: sascha.si...@twin:~$ dd if=/dev/disk/by-id/usb-CHIPSBNK_USB_2.0_260917004B813900-0\:0 of=/dev/null dd: reading `/dev/disk/by-id/usb-CHIPSBNK_USB_2.0_260917004B813900-0:0': Input/output error 468448+0 records in 468448+0 records out 239845376 bytes (240 MB) copied, 14.7675 s, 16.2 MB/s sascha.si...@twin:~$ This means that a particular block could not be read from the device, either due to a communication problem between your CPU and the device, or because the device itself has the block marked as flawed. If the reading of the device fails at the same point each time, then the latter is more likely than the former. You may obtain more details on the event from the kernel message log, using dmesg. If it's sucessfull, the whole stick will have been read: Actually, it is better to say if it is successful then the return status will be zero. Judging only by the size of the data or the lack of error messages is not as reliable. An easy way to test for zero return status is to append echo something to the end of the shell command. If the previous command returns zero for success, then the something will be displayed. dd has a noerror flag that may be useful in testing ... it causes dd to report the error and try to proceed regardless. If from using noerror you find that only a small number of blocks are unreadable, then chances are the damage is localised. With USB flash devices that report an error in a small area on read, I've found that if you *write* that area, the error goes away. Cause of the flaw? Either a block has deteriorated to the point that it cannot be read (the lifetime is not infinite), or it was erased as part of being written but the write did not complete. -- 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] Sugar on a Stick File Structure - Summary of problems and potential solutions
On Sat, Aug 1, 2009 at 6:18 PM, Mathieu Bridon (bochecha)boche...@fedoraproject.org wrote: My original response went only to you (it seems like I'm having more and more of this, sorry about that) so you in turn only replied to me. Google was having trouble with the Reply-to-all default in gmail and removed it June 16 and have not replaced it yet:( So every once in a while an gmail addict, such as myself, forgets that clicking the button in the upper right corner now defaults to reply. david Here it is for all the list to benefit :) On Sun, Aug 2, 2009 at 01:12, Caroline Meekscarol...@solutiongrove.com wrote: All, This was my attempt to put together a list from the brainstorming we have been doing so we can all look at it, generate more ideas and decide which ones we can eliminate. Hi Mathieu, Thanks, I didn't know that a full install still wouldn't be readable on a windows machine. I;d be interested if anyone has any ideas. Its not unusual for things you want to optimize to be correlated negatively or positively. Also the things to be optimized are not necessarily things that are wrong with the current system for instance it excels at size. Mathieu, can you tell me more or point me to documentation about the Overlay? Jeremy Katz, one of the Fedora devs that worked on the liveCD/USB technology we use in Fedora already answered and shared some light in the other thread where you were asking for more information (I had put him in CC). You should definitely bounce on his answer if you still need more, I think he's one of the people with the most knowledge on this matter :) Walter, We are clearly mis understanding each other somewhere. Would it help if I changed Solutions currently being considered: to Potential Solutions we are currently considering testing to see if they work and how they compare on the things we want to optimize for: I'll start another thread about failures and what we know about them within the next 48 hours. Walter, can your OpenSuse USB can be read by Windows? Except if the OpenSUSE key uses FAT32 (or NTFS) as a filesystem, I doubt it will (and I really doubt those are used on a Linux live system :) On Sat, Aug 1, 2009 at 6:46 PM, Mathieu Bridon (bochecha) boche...@fedoraproject.org wrote: Hi, To be acceptable a solution should solve all of these problems. 2. Allow a VM system to read user files and thus allow us to create a VM that can switch users 3. Allow a user to put the stick into a windows/mac/linux machine and find their files This is always going to be a problem. For exemple, the default Linux filesystem (at least on Fedora) is ext3 or ext4. Windows can't read those filesystems (without adding some experimental software), so even a full install will not solve this issue. Things we wish to optimized 1. Ability to work with poor quality sticks 3. Amount of abuse the stick can take and still work Those 2 seem rather contradictory, and I'm not sure there's a lot that can be done in software, at least in Sugar world :) 2. Size of stick needed 4. Size of download to create the stick 5. Time it takes to create the stick Those three are intimately related. If we can make the image as small as possible, it should be faster to create it. 6. Easy user experience creating the stick What exactly are the problems ? Speaking only for myself, I never had a problem creating a SoaS USB (but I might not be representative of your target population :). Were all usability issues reported upstream ? https://fedorahosted.org/liveusb-creator/ Live USB Creator works great! Its been a tremendous boon in getting people to try Sugar. I did report a bug, I think it was fixed. I don't know if you are behind the LiveUSB creator for windows but please tell whoever did it thank you! However, our Sugar on a Stick in a classroom use case will require us to create our own. We need something that lets a teacher pick what activities and language the kids should have and probably preload some content then clone sticks with all those settings but without the name and the key we use for collaboration. We'll want something that works from within Sugar. We'd love help with this project! A teacher will need to make 20-30 sticks or if they are the computer teacher for the whole school (this is common in the US) 100-300 sticks. We would thus like something that can use a standard cheap 4-8 USB port and create multiple USB sticks without user intervention between sticks. Do you know of any existing solutions for that? Solutions currently being considered: 2. Full install of Fedora As I said, this will not fix the issue of accessing files from Windows (no idea from Mac OS X). Darn! -- Mathieu Bridon (bochecha) -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax Best regards, --
Re: [Sugar-devel] Screen Reposition?
Art, Would you mind taking a look at the bug tracker[1] and adding this issue as new bug if it is not already there. dev.sugarlabs.org david On Sat, Aug 1, 2009 at 6:23 PM, Art Hunkinsabhun...@uncg.edu wrote: Second of two responses: Attached is my activity, OurMusic-1.xo. As it is, it gives a partial display on SoaS of the reduced screen layout (upper-left corner). The basic python script that illustrates my (very) basic coding is ourmusic.py. (Notice my dependence on text!) It, of course, doesn't actually work because of the problem of Csound with python. If you'd like to see it running as intended, install it on the XO - but first enable three lines in csndsugui.py: take out the leading #'s in these three spots: in the install csnd toward the beginning; in the two lines toward the end of the file. In terms of my coding style, except for the opening header text, it's basically boxes packed within boxes all the way through. FWIW, if the text remains the size it is (with SoaS on the XO), I'd guess this activity just wouldn't work in this context. I'd appreciate any and all suggestions/comments - of course, *especially* how best to deal with screen reposition (if not default type size). Art Hunkins - Original Message - From: Tomeu Vizoso to...@sugarlabs.org To: Art Hunkins abhun...@uncg.edu Cc: sugar-devel@lists.sugarlabs.org Sent: Saturday, August 01, 2009 10:47 AM Subject: Re: [Sugar-devel] Screen Reposition? On Fri, Jul 31, 2009 at 21:13, Art Hunkinsabhun...@uncg.edu wrote: I finally managed to see a mockup of my XO Activity on one of my SoaS setups (large monitor). As I feared, everything displayed in the upper left corner of the screen. I know this issue has been frequently discussed here. Can someone point me to the simplest python code for placing an XO screen-full square in the middle of any monitor display? No resizing (at least, not necessarily), just placement in mid-screen (vertically and horizontally). I've got some general ideas, but am not a coder - and my knowledge of PyGTK is skin-deep. If I understood correctly what you are asking, it will depend on how you are doing your drawing. Maybe you have the code online somewhere where we can see it? Regards, Tomeu Art Hunkins ___ 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 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] sugar rawhide livecd image
On Sat, Aug 01, 2009 at 07:02:47PM +0100, Peter Robinson wrote: I've done a Fedora Rawhide based snapshot. Now that the mass rebuild is done for the step up it i686 I'd like to get some testing done so that we can see what impact, if any, we'll see on the XO-1 with its i586+cmov processor so that we can get bugs filed and things fixed as early in the current rawhide rotation to ensure we get a well supported F12 release. I get the impression this is something we can test on XO-1 laptops? Is that the case? What can I find an .img file I can flash? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Maintaining activities for older releases (was Re: Initial implementation of toolbars design)
On Sat, Aug 01, 2009 at 05:48:57PM +0200, Tomeu Vizoso wrote: On Sat, Aug 1, 2009 at 16:48, Aleksey Limalsr...@member.fsf.org wrote: On Sat, Aug 01, 2009 at 04:37:24PM +0200, Tomeu Vizoso wrote: On Sat, Aug 1, 2009 at 16:33, Aleksey Limalsr...@member.fsf.org wrote: On Sat, Aug 01, 2009 at 03:19:46PM +0100, Gary C Martin wrote: Good luck! Quick question: Are you going to try and support existing deployments and keep and maintain both toolbar implementations? That is certainly (but painfully) my plan, as that's where 99.9% of our users are. You might need to wish me luck as well, as I'm not half as code prolific as you ;-) I have secret weapon, sugar-port[1] for that purpose :) You mean each of those activities will ship with its own copy of the new toolbars? That's quite a bit scary from the support POV. Well, not so much as you can think.. API for new toolbars won't be changed(I hope), so I need only `cp` proper sources from master repo(if it will contain fixed code) anyway I don't see another way except not using new toolbars at all. I'm personally dislike idea of having several branches in that particular case where there is no changes in activity code but only changes in 3rd party components. What is usually done in FOSS projects is to keep adding features in each new release, but only backport bugfixes to past releases, and that only if there's enough resources and interest. This is because all projects have limited resources but also have plans to move forward and expand the work done in every release. If we tell our users that new versions of activities are going to run on all versions of Sugar, this means that with every release we are going to have less resources to work on new releases because the number of platforms we need to support keep growing. We would be putting a hard limit on Sugar's growth. Given that right now we aren't able to properly maintain a single release, I see as very bold trying maintain all past releases and at the same time doing excellent new releases. To be clear, I'm not saying that we should drop support for our current users. Rather that if we want to scale, live up to expectations and give a good experience to users of past releases (most users) then we should figure out how our resources can grow at least as fast as our needs. One common way is to let downstreams support their own users. It's very cool that Uruguay wants their kids to use Sugar, and obviously the Sugar Labs community will be thrilled to be able to contribute so children there have access to better learning. But we'll be doing them a disservice if we let their government believe that a bunch of hippies around the world is going to support the software they use in the field, the newer software releases, and also the releases that other countries have decided to use. How I would expect this to work is that if Uruguay is using 0.82 and wants a feature or bugfix that appeared in 0.86, then they would put the resources needed to make a new release for 0.82. They don't need to do it alone, they can do it as part of their involvement in Sugar Labs and can pool resources with other deployers of 0.82, but the key point is that it's not expected that a super-volunteer is going to keep sync'ed all activities for all versions. Apart from the practical issue of scalability, we should also remember that our mission is to improve the learning of _all_ children of the world, not just the ones currently using Sugar. Regards, Tomeu Well, absolutely agree.. I just mean that this the question is about balance i.e. having thin level(which supported by not activity author) of components that hide differences between several sugars(not all sugar, I think about at least 2 stable release cycles) could let activity developers way to write code for several sugars w/o dipping themselves to compatibility stuff. Regards, Tomeu [1] http://wiki.sugarlabs.org/go/Development_Team/sugar-port Regards, --Gary -- Aleksey -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
