[Sugar-devel] how to pick older version of an activity for a custom sugar spin
Hello, I am creating custom spins from strawberry branch with sugar 0.84 and I have modified the kickstart file (soas-sugar.ks) to get the latest versions of the activites from activities.sugarlabs.org. The problem is that some of the latest activities are no longer compatible with 0.84 and now work with 0.86. Is there a way for me to tell the kickstart file to get to 0.84 compatible version of the activity instead of the latest version of the activity? Thanks in advance for any help. Best, Hamilton ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Error running socialcalc on sugar live cd
On Sun, Sep 27, 2009 at 23:47, vijit singh vijitthetopco...@gmail.com wrote: Hello all, Some of my co-developers are facing some issues running socialcalc on sugar live cd. A ZipExtractException is being reported in the log. I am attaching a photo log with this mail. Kindly give your suggestions about what could be the possible reasons. Also, has anybody faced any such problem while running any activity on the sugar live cd. I would also be checking it myself on the sugar live cd today, am downloading the live cd iso file with my poor net connection currently. Hi, can you check you can write to /home/olpc/Activities? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Ubuntu compatibility test stick
Hi! Just seen mentioned in the Ubuntu Weekly News: Ubuntu had a test stick at the Atlanta Linux Fest that tried out the usual problematic features (WiFi, sound, etc.) with the user answering whether it worked or not [1]. So the user could determine whether Ubuntu should work properly. All test results were collected by Canonical. Something like this for SoaS would be really great. [1] http://www.workswithu.com/2009/09/23/will-ubuntu-910-work-on-your-pc/ 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] how to pick older version of an activity for a custom sugar spin
On Mon, Sep 28, 2009 at 06:17:59PM +0800, Hamilton Chua wrote: Hello, I am creating custom spins from strawberry branch with sugar 0.84 and I have modified the kickstart file (soas-sugar.ks) to get the latest versions of the activites from activities.sugarlabs.org. The problem is that some of the latest activities are no longer compatible with 0.84 and now work with 0.86. Is there a way for me to tell the kickstart file to get to 0.84 compatible version of the activity instead of the latest version of the activity? For now, SugarPlatform version is hardcoded in .ks, see http://git.sugarlabs.org/projects/soas/repos/mainline/blobs/master/soas-aslo-and-content.ks#line61 so, you just need to change it to 0.84 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Activity version compatibility
(moving to devel list) I thought that's what host_version is for? - Bert - On 28.09.2009, at 02:40, Wade Brainerd wrote: Tentative patches posted to http://dev.sugarlabs.org/ticket/1442. An Alert when attempting to install the .xo bundle would be really nice, but this at least prevents the activity from appearing in the list. It also adds the raw data, which could be displayed in the bundle's metadata. -Wade On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd wad...@gmail.com wrote: This might be a good time to introduce an optional sugar_version=... field into activity.info, so we can display a human readable error message when this mistake happens. The activity will not launch unless Sugar's version is greater than or equal to the activity.info field. Most activities will not need it, but in case of using non-backwards compatible APIs it will be handy. Is this too big a change to patch 0.84 and 0.86 with? It will take at least two releases before it can have any real benefit. Regards, -Wade On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin g...@garycmartin.com wrote: Hi Gerald, Many thanks for the feedback. On 27 Sep 2009, at 02:52, Gerald Ardito wrote: Gary, This image came from Caroline Meeks at Solution Grove. It came as part of a version of SOAS that she put together for me. Gerald OK, looks like a SoaS build mistake. Caroline, just a quick ping. Checking activities.sugarlabs.org, it tells me Write-63 was the last version compatible with Sugar 0.84.x. I believe Aleksey started working on the new 0.85.x toolbar code as of version 64, breaking compatibility with earlier versions of Sugar: http://activities.sugarlabs.org/en-US/sugar/addons/versions/ 4201 Regards, --Gary ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] how to pick older version of an activity for a custom sugar spin
Hi Aleksey, Thanks for pointing this out. This change eluded me as I am still using the code tagged strawberry but this looks easy enough to backport and include into the kickstart files I am using. Thanks ! Hamilton For now, SugarPlatform version is hardcoded in .ks, see http://git.sugarlabs.org/projects/soas/repos/mainline/blobs/master/soas-aslo-and-content.ks#line61 so, you just need to change it to 0.84 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ubuntu compatibility test stick
Bulletproof boot will assure the success of Sugar on a Stick beyond geeks and even geeky teachers. The installation barrier is what holds back widespread GNU/Linux installs over another OS; SoaS overcomes that. We don't have a hardware compatibility matrix yet, but we should, and ideally the data could come from Sugar boot attempt logs. I have half a dozen netbooks I will video booting and tag them Sugar boots! but a boot time generated log would be even better. I wondered about this in February (http://lists.sugarlabs.org/archive/sugar-devel/2009-February/011804.html) but visibly, a major part of the problem is running down who could things that could go wrong - distro side, networking configuration, Activities. It may well be that technical problem X implies filing a bug ticket, but teachers won't bother doing that if they are evaluating SoaS. They'll just shrug and think it's not ready. if they check back a few months later and still can't get it to work, they'll just mention to their colleagues how unreliable it is. An automatically generated log of what works/doesn't which phones home to us would yield precious data about what's going wrong. I understand this would be quite difficult to code though. And of course, with no network, no phoning - although an access through the Sugar Control Panel could at least make copy/paste into a mail to feedb...@sugarlabs.org possible. Sean On Mon, Sep 28, 2009 at 12:48 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Hi! Just seen mentioned in the Ubuntu Weekly News: Ubuntu had a test stick at the Atlanta Linux Fest that tried out the usual problematic features (WiFi, sound, etc.) with the user answering whether it worked or not [1]. So the user could determine whether Ubuntu should work properly. All test results were collected by Canonical. Something like this for SoaS would be really great. [1] http://www.workswithu.com/2009/09/23/will-ubuntu-910-work-on-your-pc/ CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJKwJSKAAoJELpz82VMF3DaSgkH/1d6AxtFtkr/U7JjfbZaHJK+ bbyMAtIm/Ax+5MQlwLW1/LJ8KW84P2KVJs/c5FgLaR5NsZ3gHWUxi+rbcnvW4Nvc XVL8oepeKikiZ1khDTh7JkpF4ojUVhv9be9Jah9W4J0hJimCU5Pk8deTMYbi4+xq vXViTtPjSrPRBBpMX8i370Y3TWwll8xMEXoZJCyogKPYIgQiDHYqrWQ85E8pU9x2 gZtIF41xJf6D8kJReoma9DTUoItelIgWi9bunWptIp5fxbG+EGm8uOVfa/m3SClL z8EGcBd54MT68pfLkduVu1gDPg6UR2H7A0umJ5REn7IFNSD1d6eTFfE3GHgzvLs= =eq3w -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] Ubuntu compatibility test stick
[Dropped out soas@ because I don't think I can post there] On Mon, Sep 28, 2009 at 01:57:49PM +0200, Sean DALY wrote: And of course, with no network, no phoning That's an advantage of Canonical using a USB stick to do it: You can just store it on the stick and retrieve all logs after the show. For decentralized testing an upload form explaining how to locate the USB stick (mount point / drive letter) and the file on it (file name) might do the trick. 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] [IAEP] Activity version compatibility
Hey Bert, I wasn't aware of host_version - it looks like it's supported for content bundles, with any value other than 1 (hardcoded) raising a MalformedBundleException. It's ignored for activity bundles. So basically it was written into the spec and then dropped. I suppose we could resurrect host_version, or else add the new field. I'm open to either avenue. (Though I feel like just using the Sugar version as the value would be simpler than maintaining an independent version number) -Wade On Mon, Sep 28, 2009 at 7:43 AM, Bert Freudenberg b...@freudenbergs.dewrote: (moving to devel list) I thought that's what host_version is for? - Bert - On 28.09.2009, at 02:40, Wade Brainerd wrote: Tentative patches posted to http://dev.sugarlabs.org/ticket/1442. An Alert when attempting to install the .xo bundle would be really nice, but this at least prevents the activity from appearing in the list. It also adds the raw data, which could be displayed in the bundle's metadata. -Wade On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd wad...@gmail.com wrote: This might be a good time to introduce an optional sugar_version=... field into activity.info, so we can display a human readable error message when this mistake happens. The activity will not launch unless Sugar's version is greater than or equal to the activity.info field. Most activities will not need it, but in case of using non-backwards compatible APIs it will be handy. Is this too big a change to patch 0.84 and 0.86 with? It will take at least two releases before it can have any real benefit. Regards, -Wade On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin g...@garycmartin.com wrote: Hi Gerald, Many thanks for the feedback. On 27 Sep 2009, at 02:52, Gerald Ardito wrote: Gary, This image came from Caroline Meeks at Solution Grove. It came as part of a version of SOAS that she put together for me. Gerald OK, looks like a SoaS build mistake. Caroline, just a quick ping. Checking activities.sugarlabs.org, it tells me Write-63 was the last version compatible with Sugar 0.84.x. I believe Aleksey started working on the new 0.85.x toolbar code as of version 64, breaking compatibility with earlier versions of Sugar: http://activities.sugarlabs.org/en-US/sugar/addons/versions/4201 Regards, --Gary ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ubuntu compatibility test stick
Yes, if the task is simple and clear enough, motivated teachers and parents will try to do that I think. And even slightly geeky people will be able to do it no problem... Sean On Mon, Sep 28, 2009 at 2:20 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: [Dropped out soas@ because I don't think I can post there] On Mon, Sep 28, 2009 at 01:57:49PM +0200, Sean DALY wrote: And of course, with no network, no phoning That's an advantage of Canonical using a USB stick to do it: You can just store it on the stick and retrieve all logs after the show. For decentralized testing an upload form explaining how to locate the USB stick (mount point / drive letter) and the file on it (file name) might do the trick. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJKwKogAAoJELpz82VMF3Darn8IALAPhqdTLPOsx9ELMLuSNzdD VltIKoydIeKkmjQPca7yLbH7EnmKsS1yX4m2QRP3rCFTwcQ8bi3Opmb0e4ncr1rg Rt52ByGsZ7f4BfXhqV3bV3TMHa3SmGuUIKiBBXIWp9d96FrGcyjj6qr9CV8lh4TM h1rhhalrg/4PKpp/wIcTsN3NhFCRz0Sn5pHujgYcVdigjz+L7WGNs0DRZHo1+d3z /zM20ic4cTRVxu+sti03oHMBBeNodvBjiuvJQtJKblUH6zxQ8tShAgTaQk6BCxUi cxWV1NYrfHoaaEE+06pa6QJCy07vMSn6kQety6UBp8g+xnXrdKQVkrRRGaMWzF4= =KlSO -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] Error running socialcalc on sugar live cd
Tomeu, I am not having access to the live cd today as I am not having a good net connection here. I would let you know about it 2morrow as soon as I will get the live cd. Regards, VIJIT aka sumit On Mon, Sep 28, 2009 at 4:17 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, Sep 27, 2009 at 23:47, vijit singh vijitthetopco...@gmail.com wrote: Hello all, Some of my co-developers are facing some issues running socialcalc on sugar live cd. A ZipExtractException is being reported in the log. I am attaching a photo log with this mail. Kindly give your suggestions about what could be the possible reasons. Also, has anybody faced any such problem while running any activity on the sugar live cd. I would also be checking it myself on the sugar live cd today, am downloading the live cd iso file with my poor net connection currently. Hi, can you check you can write to /home/olpc/Activities? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ubuntu compatibility test stick
ok lets try to get Skype working tonight. thanks On Mon, Sep 28, 2009 at 8:38 AM, Sean DALY sdaly...@gmail.com wrote: Yes, if the task is simple and clear enough, motivated teachers and parents will try to do that I think. And even slightly geeky people will be able to do it no problem... Sean On Mon, Sep 28, 2009 at 2:20 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: [Dropped out soas@ because I don't think I can post there] On Mon, Sep 28, 2009 at 01:57:49PM +0200, Sean DALY wrote: And of course, with no network, no phoning That's an advantage of Canonical using a USB stick to do it: You can just store it on the stick and retrieve all logs after the show. For decentralized testing an upload form explaining how to locate the USB stick (mount point / drive letter) and the file on it (file name) might do the trick. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJKwKogAAoJELpz82VMF3Darn8IALAPhqdTLPOsx9ELMLuSNzdD VltIKoydIeKkmjQPca7yLbH7EnmKsS1yX4m2QRP3rCFTwcQ8bi3Opmb0e4ncr1rg Rt52ByGsZ7f4BfXhqV3bV3TMHa3SmGuUIKiBBXIWp9d96FrGcyjj6qr9CV8lh4TM h1rhhalrg/4PKpp/wIcTsN3NhFCRz0Sn5pHujgYcVdigjz+L7WGNs0DRZHo1+d3z /zM20ic4cTRVxu+sti03oHMBBeNodvBjiuvJQtJKblUH6zxQ8tShAgTaQk6BCxUi cxWV1NYrfHoaaEE+06pa6QJCy07vMSn6kQety6UBp8g+xnXrdKQVkrRRGaMWzF4= =KlSO -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 -- 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
Re: [Sugar-devel] [IAEP] Activity version compatibility
On Mon, Sep 28, 2009 at 7:43 AM, Bert Freudenberg b...@freudenbergs.de wrote: (moving to devel list) I thought that's what host_version is for? I asked that exact question seven days ago: http://lists.sugarlabs.org/archive/sugar-devel/2009-September/019643.html I'm copying the relevant part of that message below. My suggested design appears to be similar to Wade's with two major differences: 1. I suggested hijacking host_version instead of creating a new field. 2. I suggested adding an API so that an activity could query the actual version and adapt itself to the underlying functionality. Bill Bogstad Here's the excerpt: The lack of good dependency reporting and version tracking for Activities makes this difficult. Something like XO bundles could work better for for some scenarios though. For example, has anyone ever done anything with the 'host_version' field in the Activities *.info file? Maybe it could be hijacked for Sugar library dependencies. Not as remotely capable as full dependency checking, but core Sugar (glucose) could at least use this for direct Activity dependency issues. Preferentially with a pop-up telling people there may be incompatibilities. Activities that stick with direct Sugar supplied functionality would be safe. Glucose would know what range of values it supports and would alert if an Activity is outside of that range. Activities would request the minimum value that works for them in their info file. Perhaps Activities could also query for the maximum value supported and change their behavior based on it. (This assumes that Glucose functionality is monotonically increasing and the cost of retaining compatibility with older versions of the Glucose API is reasonable for at least a few releases.) I - Bert - On 28.09.2009, at 02:40, Wade Brainerd wrote: Tentative patches posted to http://dev.sugarlabs.org/ticket/1442. An Alert when attempting to install the .xo bundle would be really nice, but this at least prevents the activity from appearing in the list. It also adds the raw data, which could be displayed in the bundle's metadata. -Wade On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd wad...@gmail.com wrote: This might be a good time to introduce an optional sugar_version=... field into activity.info, so we can display a human readable error message when this mistake happens. The activity will not launch unless Sugar's version is greater than or equal to the activity.info field. Most activities will not need it, but in case of using non-backwards compatible APIs it will be handy. Is this too big a change to patch 0.84 and 0.86 with? It will take at least two releases before it can have any real benefit. Regards, -Wade On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin g...@garycmartin.com wrote: Hi Gerald, Many thanks for the feedback. On 27 Sep 2009, at 02:52, Gerald Ardito wrote: Gary, This image came from Caroline Meeks at Solution Grove. It came as part of a version of SOAS that she put together for me. Gerald OK, looks like a SoaS build mistake. Caroline, just a quick ping. Checking activities.sugarlabs.org, it tells me Write-63 was the last version compatible with Sugar 0.84.x. I believe Aleksey started working on the new 0.85.x toolbar code as of version 64, breaking compatibility with earlier versions of Sugar: http://activities.sugarlabs.org/en-US/sugar/addons/versions/ 4201 Regards, --Gary ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ 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] [IAEP] A Virtual Box solution that works with Sticks
Hi, I'm trying to understand this. Is it possible to use the booting method Bill found, where we boot one kernal in Virtual Box, then that Linux mounts the USB and then it boots the Sugar kernal on the stick? On Wed, Sep 23, 2009 at 10:19 PM, Gary C Martin g...@garycmartin.comwrote: Hi Dave, On 24 Sep 2009, at 01:55, Dave Bauer wrote: Last I checked virtualbox could not boot from USB on a Mac. This may have changed in a more recent version. Yep correct, that is still the case**. But, we were not talking about booting USB. Just mounting it and using the data-store from there, tweaking a VM for deployment 'should' be small change. This of course runs into all the 'what version of Sugar is installed in the VM' vs. 'what version of data-store is installed on the stick' but for a small deployment with control over both, and with specific HW needs, I don't see this as an issue. Additionally, if some data-store validation checks could be put in place I could even see this being a very positive feature for Soas and/ or upstream Sugar; an ideal little solvable issue for the two to resolve in a way that would benefit any deployments with old or not currently compatible hardware (where either the OS or a VM has to be run from the physical machine). ** unless you put the whole damn vdi on the stick and forgo the idea of booting the stick independently as a normal OS, though there could be room to investigate booting of a small partition with a reliable host OS that did nothing but dive right into the VM for those cases. Seems doable, but scary. Would much rather spend effort in finding a way to boot a USB directly – likely requires providing a Mac only image, though they can quite happily boot from USB, they just require correct boot formats (EFI for Intel Macs) but current Linux's seems well behind that curve. Most other HW manufacturers are still on old BIOS set-ups, Macs can support this for booting, Boot Camp does just this, but not for booting from USB devices unfortunately. Regards, --Gary Dave On Wed, Sep 23, 2009 at 8:12 PM, Gary C Martin g...@garycmartin.com wrote: Hi Bill, On 24 Sep 2009, at 00:17, Bill Bogstad wrote: On Wed, Sep 23, 2009 at 4:26 PM, Gary C Martin g...@garycmartin.com wrote: Sure, you could just link the ~/default/datastore directory on the VM to the matching location on the stick. I'm not sure how the pretty way to do this would be (likely at this moment in time would be just tweaking the VMs to assume the stick was there). Pop stick in, then run the VM would be the workflow once set-up. From a future stand point, you'd likely want to push upstream for a feature where Sugar checked for valid (and correct version) data-stores on start-up (perhaps with a UI if more than one valid data-store was found), so any external media device, or perhaps even mounted network volume could become the default data-store for that session. Could you clarify what you are suggesting? Most VMs (including VirtualBox) typically use large files within the host environment to provide the contents of virtual disks to the OS running under virtualization. By default VirtualBox uses a format that dynamically allocates in the real filesystem as the guest OS actually writes to the virtual disk. I don't think this file is going to be directly compatible with any file (or filesystem image) that SoaS is storing on a USB stick. If you were thinking of something else, please let me know. Yes, I routinely use the Shared Folders feature for VirtualBox on the Mac :-) Every thing Sugar flavour I work on resides there for easy access between different VMs. VirtualBox treats this as a device (after installing guest additions) so after a reboot I run: sudo mount -o uid=500 -t vboxsf name_you_give_share name_of_intended_mount_point ...which should should do the trick. Also be aware that you need to tell VirtualBox it's allowed to use USB, I think it defaults to allow, but you can also filter for named devices if that makes more sense in a deployment. I would also want to sanity check the shut down process to make sure we didn't bork users sticks at the end of a session. Ping if you'd like to work this through, should be easy enough for me to set up a test cycle here if you think this is valuable. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax
Re: [Sugar-devel] [IAEP] A Virtual Box solution that works with Sticks
On Mon, Sep 28, 2009 at 10:45 AM, Caroline Meeks carol...@solutiongrove.com wrote: Hi, I'm trying to understand this. Is it possible to use the booting method Bill found, where we boot one kernal in Virtual Box, then that Linux mounts the USB and then it boots the Sugar kernal on the stick? I'm not even proposing that. :-) I would have to think about it a while to see if there were even any advantages. I think the fundamental problem here is that the people who are commenting (including myself) have never seen the actual problem occur. The hardware/software resources available as well as the minimum functionality (use cases) are still hazy to me as well. Could you clarify what you want to accomplish and leave anything out that isn't essential? For example, does it have to be VirtualBox (or even virtualization)? If something isn't required don't mention it except in the list of resource you know you have available to solve your problem. Thanks, Bill Bogstad P.S. I'm cc'ing this note to s...@lists.sugarlabs.org as it clearly is about SoaS Strawberry and has literally nothing to do with Sugar development. It's a more generic 'my machine won't boot Linux' problem. Where the Linux in question is SoaS Strawberry. I'm leaving sugar-devel on the cc line for now, but will probably drop it if this thread continues and certainly will for any future threads on similar topics. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Announcing the creation of a SoaS Decision Panel
Hi all, In Friday's SLOBs meeting, we approved the creation of a decision panel, with the following people eligible to join the panel: Sebastian Dziallas Luke Faraone Martin Dengler Bill Bogstad Faisal Khan Benjamin M. Schwartz Samuel Klein Sean Daly Tabitha Roder Caryl Bigenho Daniel Drake Abhishek Indoria (If anyone else had volunteered but is missing from the list, the group is welcome to add them in too.) The approved scope for the Decision Panel is large. We decided to describe it as: Investigate the situation of how SoaS should be treated by Sugar Labs, and related questions, including answers to the following: * Should Sugar Labs be a GNU/Linux distributor, rather than just an upstream producing Sugar releases? * Should SL be neutral about distributions containing Sugar, and refuse to endorse one over another? * Should 'Sugar on a Stick' be a phrase that SL asks its community to avoid using unless they refer to the SoaS-Fedora distribution? * Any other question the Decision Panel deems required to provide an answer to the original question: Is the current SoaS going to be the primary way Sugar Labs distributes a Sugar-centric GNU/Linux distribution? How the panel proceeds to organize themselves and answer these questions is entirely up to them. Once a report is ready, SLOBs will review it and vote on ratifying its suggestions. Thanks, - Chris, for SLOBs. -- Chris Ball c...@laptop.org One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Announcing the creation of a SoaS Decision Panel [organization process started]
On Mon, Sep 28, 2009 at 12:48 PM, Chris Ball c...@laptop.org wrote: Hi all, In Friday's SLOBs meeting, we approved the creation of a decision panel, with the following people eligible to join the panel: Can I take it that SLOB is not formally requesting a two week deadline to report back as was suggested on the wiki minutes? Thanks, Bill Bogstad P.S. We have already started organizing ourselves based on the minutes. We will conduct any public discussions in the s...@lists.sugarlabs.org mailing list with a subject line tagged with [DP]. Individuals not on the panel who want to follow those discussions should subscribe to that list. We may make announcements/request for input to other lists, but will not conduct discussions in them or in all likelihood consider comments that are only sent to those lists. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Activity version compatibility
Hi Wade, On 28 Sep 2009, at 13:26, Wade Brainerd wrote: Hey Bert, I wasn't aware of host_version - it looks like it's supported for content bundles, with any value other than 1 (hardcoded) raising a MalformedBundleException. It's ignored for activity bundles. So basically it was written into the spec and then dropped. I suppose we could resurrect host_version, or else add the new field. I'm open to either avenue. (Though I feel like just using the Sugar version as the value would be simpler than maintaining an independent version number) My main concern is, how will most developers know what versions of Sugar their activity will work under? This is going to be an ever growing .info string that will need constant maintenance once added. Will it be a white list of sugar versions, a black list of sugar versions, a combination of both, with omissions assuming it works, or fails? So we end up with something like this in the .info that we may need to update on every release: host_version = +0.82; -0.83; +0.84; +0.86 If we only have this detection back ported for 0.84 and 0.86 I guess the 0.82 is irrelevant even though that's what the majority of Sugar users are currently using. I'd be likely to leave this line out and accept any bug reports as feedback for 'please fix your activity to work with this version of Sugar'. I'd much rather put the effort into fixing the launch pulsing window, so it is not so stupid. It needs to recognise when a process failed to start, and, at the very least, exit quickly back to the rest of the UI. It could (at a later date) be extended to do something smart with the fail case; report the error to the user somehow – nice pretty error graphic, the original mac bomb icon was a legend in its time, perhaps a large bug icon [1] for 5 seconds ;-) – rather than just 'not starting'; the UI could potentially lead folks to the crash log, or just allow revealing the last traceback (if found) for manual reporting (or debugging); the UI could potentially allow (only if connected to the internet) the bug to be automatically posted back to SL/developer for some automatic data mining to help decide which fail cases folks hist most. [1] I cleaned up Walters TA bug icon for use in the new Log toolbar, but it didn't make it in this time around http://wiki.sugarlabs.org/go/File:Toolbar-bug.png Sorry to be seeming to rain a little on the idea of release version checking, but I'm not sure most developers will ever fill this out correctly, and we're better of just being smarter about catching Activity (start-up) tracebacks quickly. And happy to help in this area if folks think this a good direction. Regards, --Gary -Wade On Mon, Sep 28, 2009 at 7:43 AM, Bert Freudenberg b...@freudenbergs.de wrote: (moving to devel list) I thought that's what host_version is for? - Bert - On 28.09.2009, at 02:40, Wade Brainerd wrote: Tentative patches posted to http://dev.sugarlabs.org/ticket/1442. An Alert when attempting to install the .xo bundle would be really nice, but this at least prevents the activity from appearing in the list. It also adds the raw data, which could be displayed in the bundle's metadata. -Wade On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd wad...@gmail.com wrote: This might be a good time to introduce an optional sugar_version=... field into activity.info, so we can display a human readable error message when this mistake happens. The activity will not launch unless Sugar's version is greater than or equal to the activity.info field. Most activities will not need it, but in case of using non-backwards compatible APIs it will be handy. Is this too big a change to patch 0.84 and 0.86 with? It will take at least two releases before it can have any real benefit. Regards, -Wade On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin g...@garycmartin.com wrote: Hi Gerald, Many thanks for the feedback. On 27 Sep 2009, at 02:52, Gerald Ardito wrote: Gary, This image came from Caroline Meeks at Solution Grove. It came as part of a version of SOAS that she put together for me. Gerald OK, looks like a SoaS build mistake. Caroline, just a quick ping. Checking activities.sugarlabs.org, it tells me Write-63 was the last version compatible with Sugar 0.84.x. I believe Aleksey started working on the new 0.85.x toolbar code as of version 64, breaking compatibility with earlier versions of Sugar: http://activities.sugarlabs.org/en-US/sugar/addons/versions/4201 Regards, --Gary ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [Sugar-devel] Activity version compatibility
- Original Message - From: Gary C Martin g...@garycmartin.com To: Wade Brainerd wad...@gmail.com Cc: sugar-devel Devel sugar-devel@lists.sugarlabs.org Sent: Monday, September 28, 2009 3:42 PM Subject: Re: [Sugar-devel] [IAEP] Activity version compatibility Hi Wade, On 28 Sep 2009, at 13:26, Wade Brainerd wrote: Hey Bert, I wasn't aware of host_version - it looks like it's supported for content bundles, with any value other than 1 (hardcoded) raising a MalformedBundleException. It's ignored for activity bundles. So basically it was written into the spec and then dropped. I suppose we could resurrect host_version, or else add the new field. I'm open to either avenue. (Though I feel like just using the Sugar version as the value would be simpler than maintaining an independent version number) My main concern is, how will most developers know what versions of Sugar their activity will work under? This is going to be an ever growing .info string that will need constant maintenance once added. Will it be a white list of sugar versions, a black list of sugar versions, a combination of both, with omissions assuming it works, or fails? So we end up with something like this in the .info that we may need to update on every release: host_version = +0.82; -0.83; +0.84; +0.86 If we only have this detection back ported for 0.84 and 0.86 I guess the 0.82 is irrelevant even though that's what the majority of Sugar users are currently using. I'd be likely to leave this line out and accept any bug reports as feedback for 'please fix your activity to work with this version of Sugar'. I'd much rather put the effort into fixing the launch pulsing window, so it is not so stupid. It needs to recognise when a process failed to start, and, at the very least, exit quickly back to the rest of the UI. It could (at a later date) be extended to do something smart with the fail case; report the error to the user somehow – nice pretty error graphic, the original mac bomb icon was a legend in its time, perhaps a large bug icon [1] for 5 seconds ;-) – rather than just 'not starting'; the UI could potentially lead folks to the crash log, or just allow revealing the last traceback (if found) for manual reporting (or debugging); the UI could potentially allow (only if connected to the internet) the bug to be automatically posted back to SL/developer for some automatic data mining to help decide which fail cases folks hist most. [1] I cleaned up Walters TA bug icon for use in the new Log toolbar, but it didn't make it in this time around http://wiki.sugarlabs.org/go/File:Toolbar-bug.png Sorry to be seeming to rain a little on the idea of release version checking, but I'm not sure most developers will ever fill this out correctly, and we're better of just being smarter about catching Activity (start-up) tracebacks quickly. And happy to help in this area if folks think this a good direction. Yes. IMO, this is the right direction. And yes, all developers should be strongly encouraged to make their activities work on as many versions of Sugar as possible. At the same time, it would behoove system developers to keep their improvements/enhancements when possible from breaking established code. (Activity developers have better things to do.) Art Hunkins Regards, --Gary -Wade On Mon, Sep 28, 2009 at 7:43 AM, Bert Freudenberg b...@freudenbergs.de wrote: (moving to devel list) I thought that's what host_version is for? - Bert - On 28.09.2009, at 02:40, Wade Brainerd wrote: Tentative patches posted to http://dev.sugarlabs.org/ticket/1442. An Alert when attempting to install the .xo bundle would be really nice, but this at least prevents the activity from appearing in the list. It also adds the raw data, which could be displayed in the bundle's metadata. -Wade On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd wad...@gmail.com wrote: This might be a good time to introduce an optional sugar_version=... field into activity.info, so we can display a human readable error message when this mistake happens. The activity will not launch unless Sugar's version is greater than or equal to the activity.info field. Most activities will not need it, but in case of using non-backwards compatible APIs it will be handy. Is this too big a change to patch 0.84 and 0.86 with? It will take at least two releases before it can have any real benefit. Regards, -Wade On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin g...@garycmartin.com wrote: Hi Gerald, Many thanks for the feedback. On 27 Sep 2009, at 02:52, Gerald Ardito wrote: Gary, This image came from Caroline Meeks at Solution Grove. It came as part of a version of SOAS that she put together for me. Gerald OK, looks like a SoaS build mistake. Caroline, just a quick ping. Checking activities.sugarlabs.org, it tells me Write-63 was the last version compatible with Sugar 0.84.x. I believe Aleksey started working on
[Sugar-devel] Xoos Special Interest Group
As promised, we have started work on the XO operating system SIG at Sugar Labs. The SIG pages are at http://wiki.sugarlabs.org/go/Xoos . Based on feedback from the current developers working in this space, the most valuable starting point will be to start making daily Xoos builds. The next step will be to work with others in this space to create a release cycle which includes alphas, betas, and final releases. These releases will enable more users and testers to participate in the development cycle. Initially, communication will happen on the de...@lists.laptop.org, sugar-...@lists.sugarlabs.org, and fedora-olpc-l...@redhat.com mailing lists. We have received initial support from the OLPC contributor program in the form of developer machines. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Activity version compatibility
On Mon, Sep 28, 2009 at 3:42 PM, Gary C Martin g...@garycmartin.com wrote: My main concern is, how will most developers know what versions of Sugar their activity will work under? This is going to be an ever growing .info string that will need constant maintenance once added. Will it be a white list of sugar versions, a black list of sugar versions, a combination of both, with omissions assuming it works, or fails? So we end up with something like this in the .info that we may need to update on every release: host_version = +0.82; -0.83; +0.84; +0.86 In the patch I posted, I assume that activities pick the oldest version of Sugar they are compatible with. For example, new Toolbar classes were introduced in 0.86, so the latest Terminal will write: host_version = 0.86.0 If you are a lazy activity developer, you simply write the version that you tested the activity for. There is no + or -, since we assume that Sugar will not break old versions of activities with new releases. This is not a new concept; we have always had the monotonically incrementing host_version. It's just never been incremented (or properly supported) before. I arrived here from a pragmatic place: I cloned Terminal from Gitorious and realized it doesn't launch on my version of Sugar (SoaS Strawberry). I briefly looked into fixing it, but didn't see the immediate way to do that. That left me with two options: 1) Do the work to maintain backwards compatibility 2) Accept that users will experience crashes I'd much rather have a third option, especially if we plan to make further additions to the sugar toolkit along the lines of the new toolbars. (Aleksey's sugar-ports library does go a long way towards making 1 easier - way to go!) I'd much rather put the effort into fixing the launch pulsing window, so it is not so stupid. It needs to recognise when a process failed to start, and, at the very least, exit quickly back to the rest of the UI. I have a prototype patch which fixes the launch window and adds an error message. I'll try to get it posted soon. [1] I cleaned up Walters TA bug icon for use in the new Log toolbar, but it didn't make it in this time around http://wiki.sugarlabs.org/go/File:Toolbar-bug.png Awesome! Mind if I use this in http://wiki.sugarlabs.org/go/Features/Problem_Reports? Sorry to be seeming to rain a little on the idea of release version checking, but I'm not sure most developers will ever fill this out correctly, and we're better of just being smarter about catching Activity (start-up) tracebacks quickly. And happy to help in this area if folks think this a good direction. I agree that it's not likely that developers will fill it out consistently, but at least they don't ever need to if they don't care about it. It's just a way for activity developers like me who want to inform users that their activities have a limit w.r.t. backwards compatibility. Best, -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Announcing the creation of a SoaS Decision Panel [organization process started]
On Mon, Sep 28, 2009 at 14:05, Sean McGrath s...@manybits.net wrote: Bill Bogstad wrote: We will conduct any public discussions in the s...@lists.sugarlabs.org mailing list with a subject line tagged with [DP]. Suggestion: As a favor to the mailing list archive searcher of the future, consider a tag [in addition to,instead of] DP. The DP process may be repeated for different issues in the future. Maybe [DP-1] or [SDP-1]? -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Activity version compatibility
Hi Wade, On 28 Sep 2009, at 21:59, Wade Brainerd wrote: On Mon, Sep 28, 2009 at 3:42 PM, Gary C Martin g...@garycmartin.com wrote: My main concern is, how will most developers know what versions of Sugar their activity will work under? This is going to be an ever growing .info string that will need constant maintenance once added. Will it be a white list of sugar versions, a black list of sugar versions, a combination of both, with omissions assuming it works, or fails? So we end up with something like this in the .info that we may need to update on every release: host_version = +0.82; -0.83; +0.84; +0.86 In the patch I posted, I assume that activities pick the oldest version of Sugar they are compatible with. For example, new Toolbar classes were introduced in 0.86, so the latest Terminal will write: host_version = 0.86.0 If you are a lazy activity developer, you simply write the version that you tested the activity for. There is no + or -, since we assume that Sugar will not break old versions of activities with new releases. This is not a new concept; we have always had the monotonically incrementing host_version. It's just never been incremented (or properly supported) before. Hmmm. So what happens when Sugar depreciates some API and breaks old activities? Say in a year or so when the core folks decide to remove the old toolbar API code? Or perhaps some of Telepathy and its API which is getting rather overdue for a fix'er'upper effort? I arrived here from a pragmatic place: I cloned Terminal from Gitorious and realized it doesn't launch on my version of Sugar (SoaS Strawberry). I briefly looked into fixing it, but didn't see the immediate way to do that. That left me with two options: 1) Do the work to maintain backwards compatibility See this is where I'm at. I'm very tempted to go back and add the old toolbar support back into Write (I already did this for Calculate and it's not too painful, working on the same for Labyrinth just now). The core devs don't think this is worth the effort, because they want folks to move up to newer versions of Sugar (and get to use all the great new features they have worked on), but the Activity developers also want their activities to be a maximum benefit right now, which means supporting 0.82 for the ~98% of our user base right now. 2) Accept that users will experience crashes I'd much rather have a third option, especially if we plan to make further additions to the sugar toolkit along the lines of the new toolbars. (Aleksey's sugar-ports library does go a long way towards making 1 easier - way to go!) I'd much rather put the effort into fixing the launch pulsing window, so it is not so stupid. It needs to recognise when a process failed to start, and, at the very least, exit quickly back to the rest of the UI. I have a prototype patch which fixes the launch window and adds an error message. I'll try to get it posted soon. Cool :-) [1] I cleaned up Walters TA bug icon for use in the new Log toolbar, but it didn't make it in this time around http://wiki.sugarlabs.org/go/File:Toolbar-bug.png Awesome! Mind if I use this in http://wiki.sugarlabs.org/go/Features/Problem_Reports? Sure go for it, here's the SVG: inline: toolbar-bug.svg Sorry to be seeming to rain a little on the idea of release version checking, but I'm not sure most developers will ever fill this out correctly, and we're better of just being smarter about catching Activity (start-up) tracebacks quickly. And happy to help in this area if folks think this a good direction. I agree that it's not likely that developers will fill it out consistently, but at least they don't ever need to if they don't care about it. It's just a way for activity developers like me who want to inform users that their activities have a limit w.r.t. backwards compatibility. If it's just for developers that want to specifically warn that their activity won't work. Why not let them just pop in a try/except around the sensitive API and show an alert within their Activity? If they already know enough to know it will fail, they'll know where and why. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] ~30 NEW XO-1.5 beta laptops now available free !
Can't be true? MAD (Make A Difference) It is! Twitter them Masses now http://blog.laptop.org Want to join the OLPC/Sugar volunteer team deciding who the luckiest, most talented 30 contributors will be? Yes You Can :) http://wiki.laptop.org/go/Support_Gang ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Activity version compatibility
Hey Gary, On Mon, Sep 28, 2009 at 8:15 PM, Gary C Martin g...@garycmartin.com wrote: Hmmm. So what happens when Sugar depreciates some API and breaks old activities? Say in a year or so when the core folks decide to remove the old toolbar API code? Or perhaps some of Telepathy and its API which is getting rather overdue for a fix'er'upper effort? Yikes I really hope this never happens - the old toolbar code just depends on GTK, right? And if we drop some part of the collaboration API, couldn't the Sugar team at least include a compatibility shim? I guess it'll always come down to a decision about how many activities are being broken and how likely they are to be fixed. 1) Do the work to maintain backwards compatibility See this is where I'm at. I'm very tempted to go back and add the old toolbar support back into Write (I already did this for Calculate and it's not too painful, working on the same for Labyrinth just now). The core devs don't think this is worth the effort, because they want folks to move up to newer versions of Sugar (and get to use all the great new features they have worked on), but the Activity developers also want their activities to be a maximum benefit right now, which means supporting 0.82 for the ~98% of our user base right now. Ok then, I'm inspired :) Is there a list of the activities that have been ported to the new toolbar design somewhere, which need compatibility code written? It didn't seem trivial for Terminal, but it's only a few dozen lines of code after all. If it's just for developers that want to specifically warn that their activity won't work. Why not let them just pop in a try/except around the sensitive API and show an alert within their Activity? If they already know enough to know it will fail, they'll know where and why. Yep - an alert would work, or if there were a way for the activity to pass a human readable launch failure message back to the launcher window we would be all set. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] sugar-pippy dependencies
Hello, the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples. So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB). The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package. Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame. -- // 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] sugar-pippy dependencies
I wouldn't mind seeing a custom PyGame for Sugar (let's call it sugargame). Ryan Gordon made a GTK backend for SDL which would allow the PyGame display to coexist with GTK widgets[1]. Also, Nirav Patel has written a sweet PyGame camera module which supports object tracking etc. There's probably a bunch of other useful stuff that could be rolled into PyGame beyond what the (unmaintained) OLPCGames wrapper provides. -Wade [1] - http://lists.laptop.org/pipermail/games/2007-April/89.html http://lists.laptop.org/pipermail/games/2007-April/89.html On Mon, Sep 28, 2009 at 9:33 PM, Bernie Innocenti ber...@codewiz.orgwrote: Hello, the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples. So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB). The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package. Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame. -- // 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] Physics Activity stopped after startup
I guess the other better/simpler option would be to A) remember the state of the stop/start button, B) encourage the use of the 'Keep' button. That way you could stop the simulation, build your experiment, and then hit 'Keep' before starting the simulation again. That way you could always resume the previously kept version and edit it some more if needed. That also makes good use of the Journal metaphor rather than adding more 'save states' into the activity itself. H, I'm rather liking this option... ;-) I like this one better as well. Keeps the activity simple. I would be glad to fix this but I'll be busy for a couple of week. If it's not done when I'm free I'll give it a go. if we agree, a ticket should be created. We could do a composite solution where you can load a contraption from the journal by clicking on a snapshot (maybe from a sidebar). Anyway, the short term thing to do is to save the stop/start state. Anything else would get done after we upgrade the UI which I guess will be in a long time. Greetings, Asaf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
