[Sugar-devel] Maze file structure different than others
Hi all, I am downloading the svg icons from http://git.sugarlabs.org/. I've noticed a minor issue, Maze has a different file structures from other activities. http://git.sugarlabs.org/projects/maze/repos/mainline/trees/master/Maze.activity/activity vs http://git.sugarlabs.org/projects/log/repos/mainline/blobs/master/activity/ Is this significant at all? @timClicks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] GetBooks version 4
Hello, I just released GetBooks version 4. Changes from previous release: * Large result-sets spanning multiple OPDS catalog files are now supported - the list gets populated incrementally as the user scrolls down. A busy-cursor is shown whenever a result-set is being fetched in the background. * Fix startup problem in OLPC XO OS 8.2.x builds * Let users cancel downloads in progress * Fixes to the removable device support code Known issues: * Removable devices are not detected on the fly when rainbow is enabled. (This is due to the fact that Rainbow does not give access permission to running activities when a new removable drive is added). Workaround for it is to start Get Books _after_ the device has been plugged in. * Multipage result-sets for the Internet Archive do not work (there seems to be a minor error in the OPDS catalog files) * A crash (segfault) occurs sometimes during acitvity shutdown. Not yet sure what is causing it. Download link: http://dev.laptop.org/~sayamindu/GetBooks-4.xo Please test this as much as possible, and if all goes well I'll create a separate git repository for it, and upload it to ASLO. Thanks, Sayamindu -- 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] Enhancement suggestion - Maze
Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. Any thoughts? @timClicks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancement suggestion - Maze
On 29/11/2009, at 8:15 PM, Tim McNamara wrote: Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. I agree, it might. I've seen the same uncertainty, and worked around it by trying to get the children into pairs, since they will usually know which icon is them. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
(Repost due to subscribers-only policy on sugar-devel) On Sun, Nov 29, 2009 at 12:53:48PM +0100, Jonas Smedegaard wrote: Please note that comparing the list of missing dependencies provided by Michael Stone with the components listed in the Sugar Platform page, only EToys is missing. That's good news. Which package does gst-plugins-espeak hide in? It's still on my to-do list for sugar-jhbuild. It is not (yet) packaged for Debian, I believe. Oh, sorry if I missed out on that one... Too bad, IIRC I had trouble building it from source. :-/ And you might have misunderstood: I did not mean to say that all is well except EToys. Just that the Sugar Platform page seems to be not enough to avoid surprises/frustrations. Example: When that page states that GStreamer can be expected, does that then mean core GStreamer infrastructure, core CStreamer + Python bindings, common GStreamer (whatever that really is) + Python bindings, or any and all weird GStreamer extensions (that is packaged for Fedora). You are absolutely right that the page is quite ambiguous in general. And like others parts of Sugar, there's still quite some Fedoraism. Help to fix that greatly appreciated. I'm moving the thread to sugar-devel for clarifications. I think the Sugar Platform page [1] should list upstream source packages; unless explicitly noted otherwise activity authors can expect that a) Python bindings, b) executables and c) data files provided by the (upstream-)default configuration are installed. Once 0install support gets merged, Sugar Platform should be enhanced to include build tools (autocrap, c(++) compiler, ...); in that case, activity authors can also rely on the corresponding -dev(el) packages (i.e. libraries, header files, etc.) to be installed as well. If there's anything most distros leave out that's included in the upstream defaults, it should be mentioned in the list (i.e. removed from the Sugar Platform). For a single distro (e.g. Debian disabling something Fedora ships) it should be discussed on sugar-devel first. As for the special case of gstreamer, I'd say it should include gstreamer-plugins-good (AFAICT that's an upstream distinction, so distro-agnostic), but not -bad or even -ugly. Especially MP3 support should be kept out (until after all patents have expired, whenever that might be) of the Sugar Platform, as it is a minefield of legal issues. (*) Python 2.5/2.6 Authors should then know that well-written implies must only use functions supported by *both* Python 2.5 and Python 2.6. Gtk+ 2.16 Debian have moved on to GTK+ 2.18 in Sid, and do not offer the older library as an alternative. [...] Personally I consider the list as minimum version, not exact version (given current distro practices it cannot be the latter). Yes, activity authors should be (made) aware of that and cater for the consequences (which isn't exactly easy, but a different topic). GStreamer 0.10 [...] gstreamer 0.10.14 Huh?!? I guess the capitalized is an ABI and the lowercased one is the actual implementation. So a Sugar Platform must include a specific micro version of the actual implementation of GStreamer?!? Looks like a mistake to me. [1] http://wiki.sugarlabs.org/go/0.86/Platform_Components (*) There is a way for individual users to legally acquire and use the Fluendo MP3 decoder, but not for (package / image / whatever) distributors (due to patent license restrictions). So as long as any MP3 patent is valid, SoaS cannot legally include an MP3 decoder (only an installer for it, which would require an internet connection during installation). 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] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
On Sun, Nov 29, 2009 at 03:02:15PM +0100, Sascha Silbe wrote: (Repost due to subscribers-only policy on sugar-devel) On Sun, Nov 29, 2009 at 12:53:48PM +0100, Jonas Smedegaard wrote: Please note that comparing the list of missing dependencies provided by Michael Stone with the components listed in the Sugar Platform page, only EToys is missing. That's good news. Which package does gst-plugins-espeak hide in? It's still on my to-do list for sugar-jhbuild. It is not (yet) packaged for Debian, I believe. Oh, sorry if I missed out on that one... Too bad, IIRC I had trouble building it from source. :-/ Ask me nice and I'll do it :-) Please ask at the Alioth list, not here. I think the Sugar Platform page [1] should list upstream source packages; unless explicitly noted otherwise activity authors can expect that a) Python bindings, b) executables and c) data files provided by the (upstream-)default configuration are installed. Makes sense to me: that is sufficient for arch-independent scripting code to work. Development headers are required only for _distro_ developers. I think, however, that it makes sense to explicitly list the Python bindings that are expected, as version numbers are often not in sync, and sometimes multiple incompatible wrappers exist. It might even make sense to *only* list the Python wrappers - their underlying libraries cannot be linked against directly arch-independently anyway. Once 0install support gets merged, Sugar Platform should be enhanced to include build tools (autocrap, c(++) compiler, ...); in that case, activity authors can also rely on the corresponding -dev(el) packages (i.e. libraries, header files, etc.) to be installed as well. I have not followed the discussions on 0install, but it surprises me that this should be mandatory - I always considered 0install as comparable to a distribution. I might loose interest in Sugar if 0install becomes integral part of core Sugar. But that's another discussion. If there's anything most distros leave out that's included in the upstream defaults, it should be mentioned in the list (i.e. removed from the Sugar Platform). For a single distro (e.g. Debian disabling something Fedora ships) it should be discussed on sugar-devel first. As for the special case of gstreamer, I'd say it should include gstreamer-plugins-good (AFAICT that's an upstream distinction, so distro-agnostic), but not -bad or even -ugly. Especially MP3 support should be kept out (until after all patents have expired, whenever that might be) of the Sugar Platform, as it is a minefield of legal issues. (*) Makes sense. And -good is also listed already, so I whined a bit too much. Python 2.5/2.6 Authors should then know that well-written implies must only use functions supported by *both* Python 2.5 and Python 2.6. Gtk+ 2.16 Debian have moved on to GTK+ 2.18 in Sid, and do not offer the older library as an alternative. [...] Personally I consider the list as minimum version, not exact version (given current distro practices it cannot be the latter). Yes, activity authors should be (made) aware of that and cater for the consequences (which isn't exactly easy, but a different topic). Makes sense to me. I have now updated the Sugar Platform page to say Minimum version and drop the superfluous/confusing newer versions mentioned for Python and CSound. GStreamer 0.10 [...] gstreamer 0.10.14 Huh?!? I guess the capitalized is an ABI and the lowercased one is the actual implementation. So a Sugar Platform must include a specific micro version of the actual implementation of GStreamer?!? Looks like a mistake to me. I've now merged those entries. [1] http://wiki.sugarlabs.org/go/0.86/Platform_Components (*) There is a way for individual users to legally acquire and use the Fluendo MP3 decoder, but not for (package / image / whatever) distributors (due to patent license restrictions). So as long as any MP3 patent is valid, SoaS cannot legally include an MP3 decoder (only an installer for it, which would require an internet connection during installation). CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Maze file structure different than others
Hi Tim, On 29 Nov 2009, at 08:47, Tim McNamara wrote: Hi all, I am downloading the svg icons from http://git.sugarlabs.org/. I've noticed a minor issue, Maze has a different file structures from other activities. http://git.sugarlabs.org/projects/maze/repos/mainline/trees/master/Maze.activity/activity vs http://git.sugarlabs.org/projects/log/repos/mainline/blobs/master/activity/ Is this significant at all? No I don't think so, just looks like Joshua decided to make the repository one directory level up than usual, holding some other misc files and directories. The repository is not the usual practice, extra misc doc items are usually kept under the top level of the activity, and the .xo bundles are not usually kept in the git repository at all (that's what ASLO is for). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
On Sun, Nov 29, 2009 at 05:37:44PM +0100, Jonas Smedegaard wrote: On Sun, Nov 29, 2009 at 03:02:15PM +0100, Sascha Silbe wrote: (Repost due to subscribers-only policy on sugar-devel) On Sun, Nov 29, 2009 at 12:53:48PM +0100, Jonas Smedegaard wrote: Please note that comparing the list of missing dependencies provided by Michael Stone with the components listed in the Sugar Platform page, only EToys is missing. That's good news. Which package does gst-plugins-espeak hide in? It's still on my to-do list for sugar-jhbuild. It is not (yet) packaged for Debian, I believe. Oh, sorry if I missed out on that one... Too bad, IIRC I had trouble building it from source. :-/ Ask me nice and I'll do it :-) Please ask at the Alioth list, not here. Just to avoid misunderstandings: I always enjoy working together with Sascha - above was just trying to make a joke, not a grumpy remark as I realize now that it could easily be misunderstood as. Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
On Sun, Nov 29, 2009 at 05:37:44PM +0100, Jonas Smedegaard wrote: On Sun, Nov 29, 2009 at 03:02:15PM +0100, Sascha Silbe wrote: Once 0install support gets merged, Sugar Platform should be enhanced to include build tools (autocrap, c(++) compiler, ...); in that case, activity authors can also rely on the corresponding -dev(el) packages (i.e. libraries, header files, etc.) to be installed as well. I have not followed the discussions on 0install, but it surprises me that this should be mandatory - I always considered 0install as comparable to a distribution. afaik there is no plans to switch to 0install, in my mind its an edition[1] to existed scheme(but if we accept this feature we should have 0install injector library in SP), so using 0install dependencies we won't extend Sugar Platform too much [1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Summary I might loose interest in Sugar if 0install becomes integral part of core Sugar. But that's another discussion. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
A problem with introducing dotted version numbers is that Sugar
versions 0.82-0.86 parse the activity version field using the Python
int() function.
a = int('100.3')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: invalid literal for int() with base 10: '100.3'
If we introduce periods into activity version strings, Sugar will
throw a MalformedBundleException when parsing activity.info. The
effect would be that Sugar would simply fail to register the activity;
it would not appear in the Home view etc.
So, introducing period syntax into an activity bundle automatically
makes it incompatible with Sugar versions 0.82 - 0.86.
This is too harsh for me, so like Gary I would just keep using integers.
On Tue, Nov 24, 2009 at 8:54 AM, Aleksey Lim alsr...@member.fsf.org wrote:
Yes, good point. We should revisit the current activities in Fructose
and think if it makes sense to keep them in Fructose. As you said, one
point is if an activity has dependencies on the platform itself like
Browse (Hulahop).
Has anyone looked into what would be needed to just make Browse work
with older versions of Hulahop?
Anecdote: My XO ran out of space over Thanksgiving and automatically
deleted Browse at boot time. I downloaded the latest version, but it
failed to launch as my XO is running the OLPC 8.2.0 build. This was
pretty annoying to me as I didn't have a web browser available to go
find out which version *would* work.
In mind thats wrong way, some activities have non-sugar SP dependencies
and can work fine with several SP releases, I guess its better to not add
additioanl complexity and use only one source for compatibility info -
on ASLO(moreove we have fructose activities on ASLO).
+1 to keeping activity version numbers totally separate from SP version.
BTW for 0.88 can exclude fructose from core packages at all and let
deployers decide what should be included to deployments.
I support this - ASLO works well enough that Fructose isn't strictly needed.
Wade
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Finance-3
Activity Homepage: http://activities.sugarlabs.org/addon/4040 Sugar Platform: 0.82 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26484/finance-3.xo Release notes: Updated translations. Fixed Keep error on recent Sugar versions. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancement suggestion - Maze
I love the faces! Joshua, what do you think about Gary's change? -Wade On Sun, Nov 29, 2009 at 2:05 PM, Gary C Martin g...@garycmartin.com wrote: Hi Tim, On 29 Nov 2009, at 09:15, Tim McNamara wrote: Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. Any thoughts? You could give it a quick try and see if it helps: 1) look in the directory ~/Activities/Maze.activity 2) edit the text file called player.py 3) at line 45 note the line that says border = size / 10. 5) change it to read something like border = size / 5. to double the thickness (see attached screen shot): Testing such changes on real children would be gold class feedback! :-) I'd like to suggest a different change to try. How about a simple face inside the circle to use more of the stroke colour? Here's my quick hack on the code, with screenshot, if you want to give it a try (if folks like this face idea, shout and I'll submit a proper patch): ___ 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] Enhancement suggestion - Maze
On 29 Nov 2009, at 19:17, Wade Brainerd wrote: I love the faces! Joshua, what do you think about Gary's change? -Wade OK, if faces get the +1, I'd like to also suggest that we vary the face design. It could just use some hash of the colour and/or user name, and then use this value to vary some base features like an identicon**, (square eyes, round eyes, several mouth shapes, noses, face shape, etc). That way we get colour identity reinforced by shape identity in an engaging way (get your friend to join your shared maze and see what funny face they have). ** such identicon type thoughts have been drifting about the Sugar UI, at one point Michael suggested to me activity icons could potentially use some such scheme to make Journal entries more unique. Buddy icon shapes are another obvious candidate. Perhaps we should make a standard 'funny face image avatar generator? ;-) (only half joking). Regards, --Gary On Sun, Nov 29, 2009 at 2:05 PM, Gary C Martin g...@garycmartin.com wrote: Hi Tim, On 29 Nov 2009, at 09:15, Tim McNamara wrote: Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. Any thoughts? You could give it a quick try and see if it helps: 1) look in the directory ~/Activities/Maze.activity 2) edit the text file called player.py 3) at line 45 note the line that says border = size / 10. 5) change it to read something like border = size / 5. to double the thickness (see attached screen shot): Testing such changes on real children would be gold class feedback! :-) I'd like to suggest a different change to try. How about a simple face inside the circle to use more of the stroke colour? Here's my quick hack on the code, with screenshot, if you want to give it a try (if folks like this face idea, shout and I'll submit a proper patch): ___ 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] Activity Versioning - Dotted Scheme
On 11/29/2009 07:23 PM, Wade Brainerd wrote:
A problem with introducing dotted version numbers is that Sugar
versions 0.82-0.86 parse the activity version field using the Python
int() function.
a = int('100.3')
Traceback (most recent call last):
File stdin, line 1, inmodule
ValueError: invalid literal for int() with base 10: '100.3'
If we introduce periods into activity version strings, Sugar will
throw a MalformedBundleException when parsing activity.info. The
effect would be that Sugar would simply fail to register the activity;
it would not appear in the Home view etc.
So, introducing period syntax into an activity bundle automatically
makes it incompatible with Sugar versions 0.82 - 0.86.
This is too harsh for me, so like Gary I would just keep using integers.
Well, if an activity will work for an older release is not only
determined by the activity version number. For example, activities that
moved to the new toolbar design are not working for older releases
0.86. I don't think we can always avoid breaking backwards compatibility.
As Aleksey stated, it is good to keep the dependencies at one place:
ASLO does this now (for the users that use it to install and update
activities).
If we conclude to remove Fructose, I guess the major-minor version
numbers makes only sense technically - easier to differentiate between
minor and major changes.
Regards,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] sunjammer: machine reboot, Nov 29 15:00 EST
We need to perform a reboot of sunjammer.sugarlabs.org required to fix the nfs server. The service outage should protract for just a few minutes. Apologies for any inconvenience, -- // 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] Activity Versioning - Dotted Scheme
On Sun, Nov 29, 2009 at 01:23:22PM -0500, Wade Brainerd wrote: Anecdote: My XO ran out of space over Thanksgiving and automatically deleted Browse at boot time. I downloaded the latest version, but it failed to launch as my XO is running the OLPC 8.2.0 build. This was pretty annoying to me as I didn't have a web browser available to go find out which version *would* work. Hmmm - I believe we were promised that ASLO would ensure that only Activities supported by the client branch of Sugar would be served. Was that a brain fart of mine, a single glitch in an otherwise reliable ASLO version handling, or whould we simply warn Sugar 0.82 users to *not* use ASLO? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Sun, Nov 29, 2009 at 3:28 PM, Jonas Smedegaard d...@jones.dk wrote: On Sun, Nov 29, 2009 at 01:23:22PM -0500, Wade Brainerd wrote: Anecdote: My XO ran out of space over Thanksgiving and automatically deleted Browse at boot time. I downloaded the latest version, but it failed to launch as my XO is running the OLPC 8.2.0 build. This was pretty annoying to me as I didn't have a web browser available to go find out which version *would* work. Hmmm - I believe we were promised that ASLO would ensure that only Activities supported by the client branch of Sugar would be served. Was that a brain fart of mine, a single glitch in an otherwise reliable ASLO version handling, or whould we simply warn Sugar 0.82 users to *not* use ASLO? ASLO does that by checking for the Browse user agent - in my situation, I had to use scp to download Browse from download.sugarlabs.org. Still, the latest Browse is only about 3400 lines of Python code - I wonder how hard it would be to make it backwards compatible with 0.82. Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Sun, Nov 29, 2009 at 03:38:26PM -0500, Wade Brainerd wrote: On Sun, Nov 29, 2009 at 3:28 PM, Jonas Smedegaard d...@jones.dk wrote: On Sun, Nov 29, 2009 at 01:23:22PM -0500, Wade Brainerd wrote: Anecdote: My XO ran out of space over Thanksgiving and automatically deleted Browse at boot time. I downloaded the latest version, but it failed to launch as my XO is running the OLPC 8.2.0 build. This was pretty annoying to me as I didn't have a web browser available to go find out which version *would* work. Hmmm - I believe we were promised that ASLO would ensure that only Activities supported by the client branch of Sugar would be served. Was that a brain fart of mine, a single glitch in an otherwise reliable ASLO version handling, or whould we simply warn Sugar 0.82 users to *not* use ASLO? ASLO does that by checking for the Browse user agent - in my situation, I had to use scp to download Browse from download.sugarlabs.org. Ahh, makes sense then :-) Still, the latest Browse is only about 3400 lines of Python code - I wonder how hard it would be to make it backwards compatible with 0.82. I'll leave that to the real programmers :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Sun, Nov 29, 2009 at 3:05 PM, Jonas Smedegaard d...@jones.dk wrote: On Sun, Nov 29, 2009 at 03:38:26PM -0500, Wade Brainerd wrote: On Sun, Nov 29, 2009 at 3:28 PM, Jonas Smedegaard d...@jones.dk wrote: On Sun, Nov 29, 2009 at 01:23:22PM -0500, Wade Brainerd wrote: Anecdote: My XO ran out of space over Thanksgiving and automatically deleted Browse at boot time. I downloaded the latest version, but it failed to launch as my XO is running the OLPC 8.2.0 build. This was pretty annoying to me as I didn't have a web browser available to go find out which version *would* work. Hmmm - I believe we were promised that ASLO would ensure that only Activities supported by the client branch of Sugar would be served. Was that a brain fart of mine, a single glitch in an otherwise reliable ASLO version handling, or whould we simply warn Sugar 0.82 users to *not* use ASLO? ASLO does that by checking for the Browse user agent - in my situation, I had to use scp to download Browse from download.sugarlabs.org. Ahh, makes sense then :-) Still, the latest Browse is only about 3400 lines of Python code - I wonder how hard it would be to make it backwards compatible with 0.82. I'll leave that to the real programmers :-) The other side of the equation depends on activity developers and editors testing their activities on the versions they identify as working on ASLO. I believe that the next batch of XO1.5s will continue to update from wiki.laptop.org over concern about developers correctly marking activity compatibility. david - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJLEuIhAAoJECx8MUbBoAEhhS4P/i3ImrYwKVar/OrD0dcEPtwL pOD1Z3X+p/CYjQcIqozmlh98pBGZrYW0jonYJU5500NzC0upn9kF3N6AzUSACkCe FgiFp++hIZfaGwp0qR/XC9GoXESjkqI7h70mVEntyhmmhrTWasy91uyx1S+5fJ1z poyH14yB/8i7/YbZZxd6cGyrsXP+winO+3478zBjt0mKOaUDYI4n/Wn85HmBkzlJ VrL2MEnN7NYLSg2Hr7sdUtF4RYr7vHKS0vTsHltXgzSQws84U5WF8Oz1vNvDpP+e p4mQYB7hgSXVgxUVTvVFUo00kL13VDN89PNhev77NkzUoffw1VdzyeBApje1HnGj uL+t9RvreP61E434SHHeEvQXwPYhvbf03e9Gv1EflGTUBtHCVRGsgNO6uqkjO0j0 rLwFyanMDleeM3YOiBNda7a0k4psx3ZfrGSiGRx4DiGcZwFwjvQnoiKiwC6JEYMr rp8WS8FD4glcHx4L6aJNINcb9hiHpTJd8fF5vqTJKXbakgIjVvuUxkCiZMgqgG69 LT66UIeUoS7AjoWN1Hxre7hZ96O7qMCHvkErJHeyfopgVD0nlf52E/LDLTAgSLVp YapJSqfNiqZUVLTPedHF0QRayPz04h/qtb9vNgl16jS6wz2aFwxErWh0CIGOo2sH Q0JIwGQJ9wQU/gOZ/L0c =b1Zt -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] Enhancement suggestion - Maze
The border size change sounds fine. Just check that it works okay when the maze is relatively large. (Hit + a bunch of times to get a large maze). When you use the other sets of keys to control your blip in the maze, you get other shapes (circle, triangle, etc). I tried a bunch of shapes, but even something like a star gets lost when the maze is even slightly large. Faces would probably get lost too. The face idea is pretty neat. My other activity, Speak, has a bunch of face editing stuff in it. I think that would be great to factor the face editor out into the Sugar layer (to the same place where you edit your colors). It would be more like the Mii editor in a Nintendo Wii - where your character shows up in whatever game you are playing. You can see a remake of it here: http://www.myavatareditor.com/ Hit the random button a few times :) I had not heard of identicons before - neat! -josh On Nov 29, 2009, at 11:39 AM, Gary C Martin wrote: On 29 Nov 2009, at 19:17, Wade Brainerd wrote: I love the faces! Joshua, what do you think about Gary's change? -Wade OK, if faces get the +1, I'd like to also suggest that we vary the face design. It could just use some hash of the colour and/or user name, and then use this value to vary some base features like an identicon**, (square eyes, round eyes, several mouth shapes, noses, face shape, etc). That way we get colour identity reinforced by shape identity in an engaging way (get your friend to join your shared maze and see what funny face they have). ** such identicon type thoughts have been drifting about the Sugar UI, at one point Michael suggested to me activity icons could potentially use some such scheme to make Journal entries more unique. Buddy icon shapes are another obvious candidate. Perhaps we should make a standard 'funny face image avatar generator? ;-) (only half joking). Regards, --Gary On Sun, Nov 29, 2009 at 2:05 PM, Gary C Martin g...@garycmartin.com wrote: Hi Tim, On 29 Nov 2009, at 09:15, Tim McNamara wrote: Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. Any thoughts? You could give it a quick try and see if it helps: 1) look in the directory ~/Activities/Maze.activity 2) edit the text file called player.py 3) at line 45 note the line that says border = size / 10. 5) change it to read something like border = size / 5. to double the thickness (see attached screen shot): Testing such changes on real children would be gold class feedback! :-) I'd like to suggest a different change to try. How about a simple face inside the circle to use more of the stroke colour? Here's my quick hack on the code, with screenshot, if you want to give it a try (if folks like this face idea, shout and I'll submit a proper patch): ___ 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] [ASLO] Release Read-78
Activity Homepage: http://activities.sugarlabs.org/addon/4028 Sugar Platform: 0.86 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26486/read-78.xo Release notes: * Make footnotes and intra-document links work in EPUB Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Please test out Read 78 and 69
Hello, Apologies for the cross-posting yet again, but I just released Read 69 for Sugar 0.84 based systems and Read 0.78 for Sugar 0.86 based systems. Both contain important fixes for handling footnotes in EPUB files (examples of such files can be seen downloaded from http://www.feedbooks.com/book/2750 and http://www.epubbooks.com/book/24/gulliver's-travels). Footnote support in EPUB has been a subject of debate (google for epub footnote to see some of the discussions), and hence this has not got much testing. If possible, please download these two files and let me know if anything odd happens. Read can be downloaded from http://activities.sugarlabs.org/ Thanks in advance, Sayamindu -- 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] [ASLO] Release Visual Match-5
Activity Homepage: http://activities.sugarlabs.org/addon/4246 Sugar Platform: 0.82 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26488/visual_match-5.xo Release notes: * added search button Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Implode-9
Activity Homepage: http://activities.sugarlabs.org/addon/4086 Sugar Platform: 0.82 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26481/implode-9.xo Release notes: Adds a help window and displays an additional option when the player gets stuck. Allows newer versions of Sugar to use new toolbars. Fixes JSON-related saving errors. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Image Viewer-8
Activity Homepage: http://activities.sugarlabs.org/addon/4032 Sugar Platform: 0.82 - 0.84 Download Now: http://activities.sugarlabs.org/downloads/file/26485/image_viewer-8.xo Release notes: * Backported fixes from master Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] MIT Media Lab comm.unity project as inspiration for Sugar's group / friends view?
Hi all, while watching the latest episode of the MIT Media Lab's Labcast ( http://labcast.media.mit.edu/?p=111) on a project called Comm.unity ( http://nadav.media.mit.edu/Projects/CommUnity) I couldn't help but think of Sugar's still largely unutilized group / friends view. Since I saw that working on this aspect of the experience is a consideration for the 0.88 / 0.90 timeframe I thought that it might be worth contacting the people behind comm.unity because I'm sure one could learn a lot about their design, issues they're running into, etc. Cheers, Christoph -- 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
[Sugar-devel] [ASLO] Release Visual Match-6
Activity Homepage: http://activities.sugarlabs.org/addon/4246 Sugar Platform: 0.82 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26489/visual_match-6.xo Release notes: * fixed selection bug * new icon Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] MIT Media Lab comm.unity project as inspiration for Sugar's group / friends view?
I am not convinced that the Group view lies fallow due to lack of ideas (and I wasn't able to glean any new ideas from the Comm.unity project). The issue is simple one of having someone step up to do the work. -walter On Sun, Nov 29, 2009 at 7:04 PM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, while watching the latest episode of the MIT Media Lab's Labcast (http://labcast.media.mit.edu/?p=111) on a project called Comm.unity (http://nadav.media.mit.edu/Projects/CommUnity) I couldn't help but think of Sugar's still largely unutilized group / friends view. Since I saw that working on this aspect of the experience is a consideration for the 0.88 / 0.90 timeframe I thought that it might be worth contacting the people behind comm.unity because I'm sure one could learn a lot about their design, issues they're running into, etc. Cheers, Christoph -- 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 -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Backwards compatible Browse
I cloned Browse v114 and spent a few hours hacking on backwards compatibility. I added compatibility fallbacks for the toolbars and a few other modules. The repository is here: http://git.sugarlabs.org/projects/browse/repos/backwards-compatibility On OLPC build 8.2.0, the patched Browse v114 starts and basically works. A few features like typeahead find are broken and beyond my ability to trivially fix, but someone with more experience hacking XPCOM could probably figure it out quickly. Is there any interest in re-forging the compatibility chain, so that the latest Browse will work on old versions of Sugar? Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Please test out Read 78 and 69
On Mon, Nov 30, 2009 at 03:27:08AM +0530, Sayamindu Dasgupta wrote:
Hello,
Apologies for the cross-posting yet again, but I just released Read 69
for Sugar 0.84 based systems and Read 0.78 for Sugar 0.86 based
systems. Both contain important fixes for handling footnotes in EPUB
files (examples of such files can be seen downloaded from
http://www.feedbooks.com/book/2750 and
http://www.epubbooks.com/book/24/gulliver's-travels). Footnote support
in EPUB has been a subject of debate (google for epub footnote to see
some of the discussions), and hence this has not got much testing.
If possible, please download these two files and let me know if
anything odd happens.
Read can be downloaded from http://activities.sugarlabs.org/
Read v78 fails on Debian, seemingly due to requiring Python 2.6 (Debian
use Python 2.5:
Traceback (most recent call last):
File /usr/lib/python2.5/site-packages/sugar/activity/activity.py,
line 433, in __canvas_map_cb
self.read_file(self._jobject.file_path)
File /usr/share/sugar/activities/Read.activity/readactivity.py, line
595, in read_file
self._load_document('file://' + self._tempfile)
File /usr/share/sugar/activities/Read.activity/readactivity.py, line
797, in _load_document
self._document = epubadapter.EpubDocument(self._view,
filepath.replace('file://', ''))
File /usr/share/sugar/activities/Read.activity/epubadapter.py, line
47, in __init__
epubview.Epub.__init__(self, docpath)
File /usr/share/sugar/activities/Read.activity/epubview/epub.py,
line 36, in __init__
if not self._verify():
File /usr/share/sugar/activities/Read.activity/epubview/epub.py,
line 111, in _verify
mtypefile = self._zobject.open('mimetype')
AttributeError: ZipFile instance has no attribute 'open'
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Sliderule-7
Activity Homepage: http://activities.sugarlabs.org/addon/4222 Sugar Platform: 0.82 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26490/sliderule-7.xo Release notes: * added indicator for pi and e Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancement suggestion - Maze
Hi Josh, On 29 Nov 2009, at 21:22, Joshua Minor wrote: The border size change sounds fine. Just check that it works okay when the maze is relatively large. (Hit + a bunch of times to get a large maze). When you use the other sets of keys to control your blip in the maze, you get other shapes (circle, triangle, etc). I tried a bunch of shapes, but even something like a star gets lost when the maze is even slightly large. Faces would probably get lost too. I did try a number of Maze levels to check how well the face details scaled. Here's a more exhaustive set, it's a pity pygame doesn't seem to offer too much in terms of anti-aliasing, but I think the face still survived the scaling pretty well (and could fit in a cube/triangle if needed): inline: maze_face_size_test.png The face idea is pretty neat. My other activity, Speak, has a bunch of face editing stuff in it. I think that would be great to factor the face editor out into the Sugar layer (to the same place where you edit your colors). It would be more like the Mii editor in a Nintendo Wii - where your character shows up in whatever game you are playing. You can see a remake of it here: http://www.myavatareditor.com/ Hit the random button a few times :) I'm not sure we would want to introduce a more complicated Sugar UI for this. If you take the current buddy colour picker and have it just generate different face shapes along with the two random colours, kids could just click through until they find a colour and face shape avatar that they like. Walter recently posted an 0.88 working feature proposal that allows undo for the buddy colour picker (actually more like previous -- large current icon -- next), so as not to be frustrating when if you pass over one you liked and want to go back. That would work well if face shape was added to the identity mix. I had not heard of identicons before - neat! Lots of different types out there based on hashes of either IP addresses or email addresses. Mainly tessellated/rotated geometric designs, but there are a few examples of monsters and faces (though too fussy for my liking, they would need to be clean/strong stroke/fill designs for Sugar UI use). Just bouncing ideas about to see if anything sticks :-) Regards, --Gary -josh On Nov 29, 2009, at 11:39 AM, Gary C Martin wrote: On 29 Nov 2009, at 19:17, Wade Brainerd wrote: I love the faces! Joshua, what do you think about Gary's change? -Wade OK, if faces get the +1, I'd like to also suggest that we vary the face design. It could just use some hash of the colour and/or user name, and then use this value to vary some base features like an identicon**, (square eyes, round eyes, several mouth shapes, noses, face shape, etc). That way we get colour identity reinforced by shape identity in an engaging way (get your friend to join your shared maze and see what funny face they have). ** such identicon type thoughts have been drifting about the Sugar UI, at one point Michael suggested to me activity icons could potentially use some such scheme to make Journal entries more unique. Buddy icon shapes are another obvious candidate. Perhaps we should make a standard 'funny face image avatar generator? ;-) (only half joking). Regards, --Gary On Sun, Nov 29, 2009 at 2:05 PM, Gary C Martin g...@garycmartin.com wrote: Hi Tim, On 29 Nov 2009, at 09:15, Tim McNamara wrote: Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. Any thoughts? You could give it a quick try and see if it helps: 1) look in the directory ~/Activities/Maze.activity 2) edit the text file called player.py 3) at line 45 note the line that says border = size / 10. 5) change it to read something like border = size / 5. to double the thickness (see attached screen shot): Testing such changes on real children would be gold class feedback! :-) I'd like to suggest a different change to try. How about a simple face inside the circle to use more of the stroke colour? Here's my quick hack on the code, with screenshot, if you want to give it a try (if folks like this face idea, shout and I'll submit a proper patch): ___ 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] Enhancement suggestion - Maze
Looks great to me. Can you wrangle doing a release? My dev/testing environment is way out of date. -josh On Nov 29, 2009, at 8:32 PM, Gary C Martin wrote: Hi Josh, On 29 Nov 2009, at 21:22, Joshua Minor wrote: The border size change sounds fine. Just check that it works okay when the maze is relatively large. (Hit + a bunch of times to get a large maze). When you use the other sets of keys to control your blip in the maze, you get other shapes (circle, triangle, etc). I tried a bunch of shapes, but even something like a star gets lost when the maze is even slightly large. Faces would probably get lost too. I did try a number of Maze levels to check how well the face details scaled. Here's a more exhaustive set, it's a pity pygame doesn't seem to offer too much in terms of anti-aliasing, but I think the face still survived the scaling pretty well (and could fit in a cube/triangle if needed): maze_face_size_test.png The face idea is pretty neat. My other activity, Speak, has a bunch of face editing stuff in it. I think that would be great to factor the face editor out into the Sugar layer (to the same place where you edit your colors). It would be more like the Mii editor in a Nintendo Wii - where your character shows up in whatever game you are playing. You can see a remake of it here: http://www.myavatareditor.com/ Hit the random button a few times :) I'm not sure we would want to introduce a more complicated Sugar UI for this. If you take the current buddy colour picker and have it just generate different face shapes along with the two random colours, kids could just click through until they find a colour and face shape avatar that they like. Walter recently posted an 0.88 working feature proposal that allows undo for the buddy colour picker (actually more like previous -- large current icon -- next), so as not to be frustrating when if you pass over one you liked and want to go back. That would work well if face shape was added to the identity mix. I had not heard of identicons before - neat! Lots of different types out there based on hashes of either IP addresses or email addresses. Mainly tessellated/rotated geometric designs, but there are a few examples of monsters and faces (though too fussy for my liking, they would need to be clean/strong stroke/fill designs for Sugar UI use). Just bouncing ideas about to see if anything sticks :-) Regards, --Gary -josh On Nov 29, 2009, at 11:39 AM, Gary C Martin wrote: On 29 Nov 2009, at 19:17, Wade Brainerd wrote: I love the faces! Joshua, what do you think about Gary's change? -Wade OK, if faces get the +1, I'd like to also suggest that we vary the face design. It could just use some hash of the colour and/or user name, and then use this value to vary some base features like an identicon**, (square eyes, round eyes, several mouth shapes, noses, face shape, etc). That way we get colour identity reinforced by shape identity in an engaging way (get your friend to join your shared maze and see what funny face they have). ** such identicon type thoughts have been drifting about the Sugar UI, at one point Michael suggested to me activity icons could potentially use some such scheme to make Journal entries more unique. Buddy icon shapes are another obvious candidate. Perhaps we should make a standard 'funny face image avatar generator? ;-) (only half joking). Regards, --Gary On Sun, Nov 29, 2009 at 2:05 PM, Gary C Martin g...@garycmartin.com wrote: Hi Tim, On 29 Nov 2009, at 09:15, Tim McNamara wrote: Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. Any thoughts? You could give it a quick try and see if it helps: 1) look in the directory ~/Activities/Maze.activity 2) edit the text file called player.py 3) at line 45 note the line that says border = size / 10. 5) change it to read something like border = size / 5. to double the thickness (see attached screen shot): Testing such changes on real children would be gold class feedback! :-) I'd like to suggest a different change to try. How about a simple face inside the circle to use more of the stroke colour? Here's my quick hack on the code, with screenshot, if you want to give it a try (if folks like this face idea, shout and I'll submit a proper patch): ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
