[Sugar-devel] [ASLO] TuxPaint-5 experimental release
Hi all, Activity Homepage: http://activities.sugarlabs.org/addon/4088 Sugar Platform: 0.84 - 0.88 Download Now: http://activities.sugarlabs.org/en-US/sugar/downloads/file/26946/tux_paint-5.xo Release notes: * Release contains only i486 binaries * Revert save button to save current image (not keep) * Revert open button to import image from the Journal * Save image preview in Journal objects * Set correct MIME type for created Journal objects * List of MIME types supported my activity -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GCompris packaging
On Thu, Jun 10, 2010 at 11:56:32PM +, Aleksey Lim wrote: On Fri, Jun 11, 2010 at 01:18:34AM +0200, Bastien wrote: Hi Bernie and all, Adding Bruno to the conversation -- he's the main developer of Gcompris (outside Sugar) and I'm not 100% sure he's on this list. He is... but at this moment he could be trying to figure out how to use gimp to change the walls texture IRL to refresh his apartment :) He might have ideas about this. Best, Bernie Innocenti ber...@codewiz.org writes: (copying the tecnologia@ and sugar-devel@ lists for their information) Pacita, meet Aleksey, a very active contributor of Sugar, maintainer of the Sugar Labs activity library (ASLO) and packager of GCompris. Aleksey, meet Pacita, the lead of the education team of Paraguay Educa, who has a very strong background on pedagogy and teaching materials. The old monolithic bundle of GCompris was 70MB so big that it was causing problems at all levels with the limited disk space of the XO-1. The new strategy of pulverizing GCompris into a hundred tiny bundles made it unmanageable with the current shell (updater, launcher, switcher, etc). After separate discussions with Pacita and Aleksey, we all seem to agree that GCompris needs to be repackaged differently. From a technical standpoint, breaking GCompris into 4-5 activities would be ideal. However, it's not clear yet how the break should be done to make it more useful in the classroom: by subject? by age group? by curriculum? Educators can offer important input on this. Pacita, what about this workflow: * teacher creates new GCompris Administration[1] activity object, to * add change content of Classes, Groups and Profiles; different Administration instances will share this data to not recreate it every time * set activities list for this particular GCompris Administration object * teacher saves and shares GCompris Administration object * students join this object and follow regular GC workflow * teacher in runtime mode, can observe results in Reports tab in GCompris Administration There is also another point to consider - Journal objects. I've added Journal integration (store documents created within GC activities in Journal) to Wordprocessor, Anim and Draw activities (I guess there are no other activities that create documents). In these activities I hide regular load/save buttons (that open regular fs tree dialog), so user all time is working with the same document (which is common for other sugar activities). But since there is a plan to have single GC, I have to store documents from GC activities in the same Journal entry (which is unusual for sugar but since it is not about adding new workflow but reusing existed GC's, I guess it is ok). So, the question, are you considering workflows with creating documents within GC activities and what is preferable way (within sugar)? In my mind it could be something like: any joined user (including teacher), for activities that create documents, can open regular sugar object chooser (instead of fs tree dialog) to import files from local Journal, also import document that are created by joined users within this GC session (could be useful e.g. to see what student did). [1] http://gcompris.net/wiki/index.php?title=Manual#Administering_GCompris -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Alerting users in case of write errors (sl#1842)
On Thu, Jun 10, 2010 at 20:56, Martin Abente mabe...@paraguayeduca.org wrote: We really really really ... need a general notification system. :D You may not believe it, but the shell has an implementation of http://www.galago-project.org/specs/notification/ . We need more activities to use it and also improve the implementation. Regards, Tomeu On Thu, 2010-06-10 at 14:39 -0400, Frederick Grose wrote: On Thu, Jun 10, 2010 at 2:13 PM, Anish Mangal anishmangal2...@gmail.com wrote: I was planning on fixing sl#1842 [1] but I'm not sure what should be the correct method of alerting users incase a write error does occur. Should I popup a dialog box, or use alerts like the one used in chat, sugar-commander? Suggestions welcome. [1] http://bugs.sugarlabs.org/ticket/1842, An alert like a chat or Activity sharing invitation would be nice, but one with a more visible signal is needed. I imagine an alert icon that rises out of the Frame, enlarges and glows for a few moments, then settles back to the Frame, but then shows a glowing edge or corona and bumps up slightly every 15 or 30 seconds in case the learner was focused on another Activity at the time the alert was first displayed (or just decided to postpone attention to the alert and then forgot about the pending need for attention). Of course, the icon should be clickable and reveal a useful palette of actions at any point in its lifetime. New alerts with behavior like the above would be welcome for invitations as well as errors. Thanks! --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Problems adapting activity
Here's the log my activity generated. 1276255872.662322 WARNING root: Bundle Blocos: invalid entry in MANIFEST: COPYING 1276255872.664506 WARNING root: Bundle Blocos: MANIFEST includes itself: MANIFEST aviso! imagem 'null.png' nao encontrada Traceback (most recent call last): File /usr/bin/sugar-activity, line 136, in module create_activity_instance(activity_constructor, activity_handle) File /usr/bin/sugar-activity, line 36, in create_activity_instance activity = constructor(handle) File /home/amarcorin/Activities/Blocos.activity/Blocos.py, line 99, in __init__ self.generate_blocklist() File /home/amarcorin/Activities/Blocos.activity/Blocos.py, line 420, in generate_blocklist self.add_block_tree( self.treeList[0], None, on_block() ) File /home/amarcorin/Activities/Blocos.activity/Blocos.py, line 395, in add_block_tree if block.get_width() self.maxblockwidth: File /home/amarcorin/Activities/Blocos.activity/blockcanvas/block.py, line 599, in get_width return self.get_image()[0].get_width() AttributeError: 'NoneType' object has no attribute 'get_width' Seems like the main problem is the MANIFEST thing. Also, a lot of stuff that seems related to the code itself, although, most of them are pretty strange, since I didn't really change anything within the code besides importing the sugar class and doing the changes related to it. Also, any way to solve the MANIFEST problem, besides getting the patch? Thank you. 2010/6/9 James Cameron qu...@laptop.org On Wed, Jun 09, 2010 at 10:50:02PM -0300, Alberto Arruda de Oliveira wrote: But one error I remember, and that draw my attention is that the log said that the MANIFEST file was missing, even though I had it on my activity folder. Anyone knows why this could be happening? Yes, it means you haven't got the patch that removes MANIFEST support. I don't think that has been accepted yet. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 8, 2010 at 5:54 AM, Michael Stone mich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15. you: your patch series here Comments? Additions? Substitutions? Deletions? Michael, thanks for stepping up to be the 0.90 development manager :-P Peter PS I'm sure Walter will back me up here! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Sucrose 0.88.1 Final Release
Dear Sugar Community, This is the first bug fix release last after the final 0.88 release - see http://sugarlabs.org/go/0.88/Roadmap#Schedule for more details. Please use the instructions for your distribution (Fedora, Ubuntu, Debian etc) of choice to upgrade to this release. Note that it may take a while until the release is packaged for each distribution. Please stay tuned for distribution specific announcements and watch out for updates at http://wiki.sugarlabs.org/go/Downloads. Thanks everyone for your great contributions! In behalf of the sugar community, Your Release Team == Modules that changed == * http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.88.1.tar.bz2 * http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.88.1.tar.bz2 * http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.88.1.tar.bz2 == Glucose news == === sugar-artwork === * GTK deprecated API troubles #1899 Aleksey Lim, Bernie Innocenti, Benjamin Berg === sugar-toolkit === * bundlebuilder should not use locale name #1968 Walter Bender * Race condition with name widget in the activity toolbar #1948 Aleksey Lim * Cannot delete stalled download from journal #1987 Aleksey Lim * Japanese translations: 40 strings translated Korakurider === sugar === * keyboard control panel chokes on non-empty option group #2022 Sascha Silbe * once we fail to launch Xephyr, successive launches fail #1860 Tomeu Vizoso * Failure to cleanup temporary files after filesystem full errors #1876 Aleksey Lim * resume journal entry race may duplicate resumed activity id #1719 Aleksey Lim * sugar-emulator: better error message if X server is unreachable #1755 Sascha Silbe * doesn't automatically connect to network at startup anymore (on XO-1) #1883 Simon Schampijer * broken log statement in OlpcMeshManager._activate_connection() #1890 Sascha Silbe * Register menu item does not disappear after successful registration #1837 Kenny Meyer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Alerting users in case of write errors (sl#1842)
On Fri, Jun 11, 2010 at 5:11 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Jun 10, 2010 at 20:56, Martin Abente mabe...@paraguayeduca.org wrote: We really really really ... need a general notification system. :D You may not believe it, but the shell has an implementation of http://www.galago-project.org/specs/notification/ . We need more activities to use it and also improve the implementation. Is there a good example somewhere we can highlight for activity developers? regards. -walter Regards, Tomeu On Thu, 2010-06-10 at 14:39 -0400, Frederick Grose wrote: On Thu, Jun 10, 2010 at 2:13 PM, Anish Mangal anishmangal2...@gmail.com wrote: I was planning on fixing sl#1842 [1] but I'm not sure what should be the correct method of alerting users incase a write error does occur. Should I popup a dialog box, or use alerts like the one used in chat, sugar-commander? Suggestions welcome. [1] http://bugs.sugarlabs.org/ticket/1842, An alert like a chat or Activity sharing invitation would be nice, but one with a more visible signal is needed. I imagine an alert icon that rises out of the Frame, enlarges and glows for a few moments, then settles back to the Frame, but then shows a glowing edge or corona and bumps up slightly every 15 or 30 seconds in case the learner was focused on another Activity at the time the alert was first displayed (or just decided to postpone attention to the alert and then forgot about the pending need for attention). Of course, the icon should be clickable and reveal a useful palette of actions at any point in its lifetime. New alerts with behavior like the above would be welcome for invitations as well as errors. Thanks! --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Alerting users in case of write errors (sl#1842)
On Fri, Jun 11, 2010 at 17:46, Walter Bender walter.ben...@gmail.com wrote: On Fri, Jun 11, 2010 at 5:11 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Jun 10, 2010 at 20:56, Martin Abente mabe...@paraguayeduca.org wrote: We really really really ... need a general notification system. :D You may not believe it, but the shell has an implementation of http://www.galago-project.org/specs/notification/ . We need more activities to use it and also improve the implementation. Is there a good example somewhere we can highlight for activity developers? I added support for it to XOIrc but I'm not sure if I managed to have that patch accepted back then. Regards, Tomeu regards. -walter Regards, Tomeu On Thu, 2010-06-10 at 14:39 -0400, Frederick Grose wrote: On Thu, Jun 10, 2010 at 2:13 PM, Anish Mangal anishmangal2...@gmail.com wrote: I was planning on fixing sl#1842 [1] but I'm not sure what should be the correct method of alerting users incase a write error does occur. Should I popup a dialog box, or use alerts like the one used in chat, sugar-commander? Suggestions welcome. [1] http://bugs.sugarlabs.org/ticket/1842, An alert like a chat or Activity sharing invitation would be nice, but one with a more visible signal is needed. I imagine an alert icon that rises out of the Frame, enlarges and glows for a few moments, then settles back to the Frame, but then shows a glowing edge or corona and bumps up slightly every 15 or 30 seconds in case the learner was focused on another Activity at the time the alert was first displayed (or just decided to postpone attention to the alert and then forgot about the pending need for attention). Of course, the icon should be clickable and reveal a useful palette of actions at any point in its lifetime. New alerts with behavior like the above would be welcome for invitations as well as errors. Thanks! --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- 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] core maintainers
Over the past couple of months it has appeared that the ramp up of deployment submitted patches has stretched the core maintainers rather short. I would like to consider having Deployment Support Network developers start accepting additional maintainership responsibility and authority. Specifically, I am interested in which core activities are in need of a maintainer and which core modules are up for adoption. With this information, I can start identifying and recruiting potential maintainers. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] core maintainers
On Fri, Jun 11, 2010 at 12:39 PM, David Farning dfarn...@gmail.com wrote: Over the past couple of months it has appeared that the ramp up of deployment submitted patches has stretched the core maintainers rather short. I would like to consider having Deployment Support Network developers start accepting additional maintainership responsibility and authority. Specifically, I am interested in which core activities are in need of a maintainer and which core modules are up for adoption. Perhaps an ignorant question: What is Deployment Support Network? -walter With this information, I can start identifying and recruiting potential maintainers. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] core maintainers
On Fri, Jun 11, 2010 at 12:04 PM, Walter Bender walter.ben...@gmail.com wrote: On Fri, Jun 11, 2010 at 12:39 PM, David Farning dfarn...@gmail.com wrote: Over the past couple of months it has appeared that the ramp up of deployment submitted patches has stretched the core maintainers rather short. I would like to consider having Deployment Support Network developers start accepting additional maintainership responsibility and authority. Specifically, I am interested in which core activities are in need of a maintainer and which core modules are up for adoption. Perhaps an ignorant question: What is Deployment Support Network? Over the past couple of months, Activity Central has been establishing a network of developers to provide service and support for deployments. A number of these developer have been working on fixing Sugar related bugs. Sugar Labs has expressed the importance of more code contributions from deployments. Deployments have expressed an interest in fixing their own bugs. The Deployment Support Network fills that gap. Initial, I had reservations about the maintainship roles these developers would hold at Sugar Labs. In light of the current backlog of patches and the heavy burden a few core developers are holding, I would like work with the Sugar Labs development team to determine the process for experienced developers to become maintainers. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] core maintainers
On Fri, Jun 11, 2010 at 12:39 PM, David Farning dfarn...@gmail.com wrote: Over the past couple of months it has appeared that the ramp up of deployment submitted patches has stretched the core maintainers rather short. How about the old classic of F/OSS: whoever is doing the most good work on a particular part of the code... is the maintainer! The linux kernel and all the successful projects I've done work with use this fluid notion. Whenever I wonder who's the maintainer for something I use git log path/to/dir/or/file. Easy. Direct. Low bureacracy. Low-flammage (relatively ;-)). m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Problems adapting activity
On 11 June 2010 08:43, Alberto Arruda de Oliveira alberto.a.o...@gmail.com wrote: Here's the log my activity generated. 1276255872.662322 WARNING root: Bundle Blocos: invalid entry in MANIFEST: COPYING 1276255872.664506 WARNING root: Bundle Blocos: MANIFEST includes itself: MANIFEST aviso! imagem 'null.png' nao encontrada Traceback (most recent call last): File /usr/bin/sugar-activity, line 136, in module create_activity_instance(activity_constructor, activity_handle) File /usr/bin/sugar-activity, line 36, in create_activity_instance activity = constructor(handle) File /home/amarcorin/Activities/Blocos.activity/Blocos.py, line 99, in __init__ self.generate_blocklist() File /home/amarcorin/Activities/Blocos.activity/Blocos.py, line 420, in generate_blocklist self.add_block_tree( self.treeList[0], None, on_block() ) File /home/amarcorin/Activities/Blocos.activity/Blocos.py, line 395, in add_block_tree if block.get_width() self.maxblockwidth: File /home/amarcorin/Activities/Blocos.activity/blockcanvas/block.py, line 599, in get_width return self.get_image()[0].get_width() AttributeError: 'NoneType' object has no attribute 'get_width' Seems like the main problem is the MANIFEST thing. Also, a lot of stuff that seems related to the code itself, although, most of them are pretty strange, since I didn't really change anything within the code besides importing the sugar class and doing the changes related to it. The MANIFEST thing is unrelated and harmless. I guess your error is that the activity cannot locate null.png Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GCompris packaging
Le jeudi 10 juin 2010 à 15:49 -0400, Bernie Innocenti a écrit : (copying the tecnologia@ and sugar-devel@ lists for their information) The new strategy of pulverizing GCompris into a hundred tiny bundles made it unmanageable with the current shell (updater, launcher, switcher, etc). It's always the same with technology, going back and forth, full versus bundle, thin client versus fat... So far GCompris could be package in multi activity bundles without problem. It already support this, you can just test it by running gcompris -l /math, it will show you all the activities under the /math menu. All we miss is a way to create such bundles where all the resources of a bundle group are together. After separate discussions with Pacita and Aleksey, we all seem to agree that GCompris needs to be repackaged differently. From a technical standpoint, breaking GCompris into 4-5 activities would be ideal. We could follow the top level organisation of GCompris in which we have 8 sections: computer discovery experience fun math puzzle reading strategy However, it's not clear yet how the break should be done to make it more useful in the classroom: by subject? by age group? by curriculum? Any other splitting is fine for me. We already embed a difficulty level (1 to 6) that could be use to create bundles. I have not yet checked Aleksey work on bunding GCompris on Sugar so we have to check how hard it would be to update the bundling process. -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GCompris packaging
On Fri, Jun 11, 2010 at 4:22 PM, Bruno Coudoin bruno.coud...@free.fr wrote: Le jeudi 10 juin 2010 à 15:49 -0400, Bernie Innocenti a écrit : (copying the tecnologia@ and sugar-devel@ lists for their information) The new strategy of pulverizing GCompris into a hundred tiny bundles made it unmanageable with the current shell (updater, launcher, switcher, etc). It's always the same with technology, going back and forth, full versus bundle, thin client versus fat... So far GCompris could be package in multi activity bundles without problem. It already support this, you can just test it by running gcompris -l /math, it will show you all the activities under the /math menu. All we miss is a way to create such bundles where all the resources of a bundle group are together. After separate discussions with Pacita and Aleksey, we all seem to agree that GCompris needs to be repackaged differently. From a technical standpoint, breaking GCompris into 4-5 activities would be ideal. We could follow the top level organisation of GCompris in which we have 8 sections: computer discovery experience fun math puzzle reading strategy However, it's not clear yet how the break should be done to make it more useful in the classroom: by subject? by age group? by curriculum? Any other splitting is fine for me. We already embed a difficulty level (1 to 6) that could be use to create bundles. I have not yet checked Aleksey work on bunding GCompris on Sugar so we have to check how hard it would be to update the bundling process. -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Maybe a checkbox system to let a teach customize a collection for a class/grade-level across curricula areas and leave the individual activities available for download for children who want more? -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GCompris packaging
Le vendredi 11 juin 2010 à 16:30 -0400, Walter Bender a écrit : Maybe a checkbox system to let a teach customize a collection for a class/grade-level across curricula areas and leave the individual activities available for download for children who want more? This is another option but it will require some computing power to prepare the bundles server side. -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GCompris packaging
On Fri, Jun 11, 2010 at 4:58 PM, Bruno Coudoin bruno.coud...@free.fr wrote: Le vendredi 11 juin 2010 à 16:30 -0400, Walter Bender a écrit : Maybe a checkbox system to let a teach customize a collection for a class/grade-level across curricula areas and leave the individual activities available for download for children who want more? This is another option but it will require some computing power to prepare the bundles server side. I was assuming it would be a very occasional process where ALSO is used to augment the precomputed collections. (Also, once a collection is assembled, it can be used by others.) -walter -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] core maintainers
On Fri, Jun 11, 2010 at 01:58:32PM -0500, David Farning wrote: Over the past couple of months, Activity Central has been establishing a network of developers to provide service and support for deployments. I assume they're paid, otherwise why would you (Activity Central) not just establish such people into the normal SugarLabs network. On Fri, Jun 11, 2010 at 12:04 PM, Walter Bender walter.ben...@gmail.com wrote: What is Deployment Support Network? Sugar Labs has expressed the importance of more code contributions from deployments. Deployments have expressed an interest in fixing their own bugs. The Deployment Support Network fills that gap. What gap? The gap between getting code from deployments and... deployments who want to write code? What is Deployment Support Network? In particular, who are they and how/why are they distict from Sugar Labs members (basically anyone who wants to submit a patch or write an email to sugar-devel@)? Initial, I had reservations about the maintainship roles these developers would hold at Sugar Labs. In light of the current backlog of patches and the heavy burden a few core developers are holding, I would like work with the Sugar Labs development team to determine the process for experienced developers to become maintainers. You've totally avoided Walter's question (AFAICS) and then gingerly formulated an missive that, despite some mysterious reservations, seems to imply that you think the [SL] development team will resist having experienced developers [...become] maintainers. Why would you think that? david Martin pgpWhefMh5YAK.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Paint: trying to fix #1771
On Fri, Jun 11, 2010 at 01:25:06AM -0300, Gonzalo Odiard wrote:
I think it works, but i don't know if the right thing to do.
From 97fb2adb1ea97a472e020244ae7a2d22c7a94db3 Mon Sep 17 00:00:00 2001
From: Gonzalo Odiard godi...@gmail.com
Date: Fri, 11 Jun 2010 01:22:36 -0300
Subject: [PATCH] fix #1771 - paint overwrites file type instead of creating
new file
Your patch was missing an explanation in the commit message, but during
review I tried to make an explanation. I'll put the explanation here
and ask you to review it:
Paint only writes type image/png. It can load other types, but
overwrites as image/png. This patch detects reading a type that is not
image/png, and forgets the association between the image being edited
and the journal entry that was read, so that the original journal entry
is not overwritten.
Does that match your understanding?
http://bugs.sugarlabs.org/ticket/1771
---
OficinaActivity.py |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/OficinaActivity.py b/OficinaActivity.py
index c72576a..78bc8cf 100644
--- a/OficinaActivity.py
+++ b/OficinaActivity.py
@@ -140,8 +140,8 @@ class OficinaActivity(activity.Activity):
def read_file(self, file_path):
'''Read file from Sugar Journal.'''
+print 'reading file', file_path, mime_type, self.metadata
['mime_type']
-logging.debug('reading file %s', file_path)
Why did you change this to print? If it was only temporary, change it
back. If it is of use, change the logging.debug line.
Hint: since the logging level can't be changed once Sugar is started, I
change debug to error while I am testing code, and then change it
back to debug before committing the patch.
pixbuf = gtk.gdk.pixbuf_new_from_file(file_path)
@@ -155,6 +155,9 @@ class OficinaActivity(activity.Activity):
self._setup_handle = self.fixed.connect('size_allocate',
size_allocate_cb)
+if self.metadata['mime_type'] != image/png:
+self._jobject.object_id = None
+
A comment would be useful here, because reading the code doesn't explain
why it is happening. Something like:
# disassociate with journal entry to avoid overwrite (SL #1771)
def write_file(self, file_path):
'''Save file on Sugar Journal. '''
--
1.6.6.1
--
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] core maintainers
On Fri, Jun 11, 2010 at 03:29:44PM -0400, Martin Langhoff wrote:
The linux kernel and all the successful projects I've done work with
use this fluid notion. Whenever I wonder who's the maintainer for
something I use git log path/to/dir/or/file.
And a MAINTAINER{S,} file.
--
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Paint: trying to fix #1771
On Fri, Jun 11, 2010 at 9:04 PM, James Cameron qu...@laptop.org wrote:
On Fri, Jun 11, 2010 at 01:25:06AM -0300, Gonzalo Odiard wrote:
I think it works, but i don't know if the right thing to do.
From 97fb2adb1ea97a472e020244ae7a2d22c7a94db3 Mon Sep 17 00:00:00 2001
From: Gonzalo Odiard godi...@gmail.com
Date: Fri, 11 Jun 2010 01:22:36 -0300
Subject: [PATCH] fix #1771 - paint overwrites file type instead of
creating new file
Your patch was missing an explanation in the commit message, but during
review I tried to make an explanation. I'll put the explanation here
and ask you to review it:
Paint only writes type image/png. It can load other types, but
overwrites as image/png. This patch detects reading a type that is not
image/png, and forgets the association between the image being edited
and the journal entry that was read, so that the original journal entry
is not overwritten.
Does that match your understanding?
Yes, it's ok.
http://bugs.sugarlabs.org/ticket/1771
---
OficinaActivity.py |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/OficinaActivity.py b/OficinaActivity.py
index c72576a..78bc8cf 100644
--- a/OficinaActivity.py
+++ b/OficinaActivity.py
@@ -140,8 +140,8 @@ class OficinaActivity(activity.Activity):
def read_file(self, file_path):
'''Read file from Sugar Journal.'''
+print 'reading file', file_path, mime_type, self.metadata
['mime_type']
-logging.debug('reading file %s', file_path)
Why did you change this to print? If it was only temporary, change it
back. If it is of use, change the logging.debug line.
Hint: since the logging level can't be changed once Sugar is started, I
change debug to error while I am testing code, and then change it
back to debug before committing the patch.
Was temporary, but your idea is better for debugging.
pixbuf = gtk.gdk.pixbuf_new_from_file(file_path)
@@ -155,6 +155,9 @@ class OficinaActivity(activity.Activity):
self._setup_handle = self.fixed.connect('size_allocate',
size_allocate_cb)
+if self.metadata['mime_type'] != image/png:
+self._jobject.object_id = None
+
A comment would be useful here, because reading the code doesn't explain
why it is happening. Something like:
# disassociate with journal entry to avoid overwrite (SL #1771)
def write_file(self, file_path):
'''Save file on Sugar Journal. '''
--
1.6.6.1
I was thinking change the title also, because is unclear when you see two
inputs in the journal with the same name but there are two different files.
May be changing the extension or setting the title empty. I don't know what
it's better.
--
James Cameron
http://quozl.linux.org.au/
--
Gonzalo Odiard
Responsable de Desarrollo
Sistemas Australes
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Paint: trying to fix #1771
On Fri, Jun 11, 2010 at 10:05:42PM -0300, Gonzalo Odiard wrote: I was thinking change the title also, because is unclear when you see two inputs in the journal with the same name but there are two different files. May be changing the extension or setting the title empty. I don't know what it's better. The MIME type is not exposed to the user in 0.84, so yes, it is unclear to the user why they have a new journal entry with the same name, where one is SVG and the other is PNG. I don't know what to do about it though, sorry. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
Hi, Why it is just a pipe dream? 1. Python does not have anything like the DALVIK virtual machine so every Python process consumes a lot of memory. Because of this, implementing the above infrastructure would consume all available RAM and so would not work. Linux memory management shares identical pages between processes. - Chris. -- 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
