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 One Laptop Per Child ___ 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] Paint: trying to fix #1771
On Fri, Jun 11, 2010 at 9:04 PM, James Cameron 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 > > 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] 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 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 > 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 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 > 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] GCompris packaging
On Fri, Jun 11, 2010 at 4:58 PM, Bruno Coudoin 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] 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:22 PM, Bruno Coudoin 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 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] Problems adapting activity
On 11 June 2010 08:43, Alberto Arruda de Oliveira 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 > 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] core maintainers
On Fri, Jun 11, 2010 at 12:39 PM, David Farning 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] core maintainers
On Fri, Jun 11, 2010 at 12:04 PM, Walter Bender wrote: > On Fri, Jun 11, 2010 at 12:39 PM, David Farning 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 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
[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] [DESIGN] Alerting users in case of write errors (sl#1842)
On Fri, Jun 11, 2010 at 17:46, Walter Bender wrote: > On Fri, Jun 11, 2010 at 5:11 AM, Tomeu Vizoso wrote: >> On Thu, Jun 10, 2010 at 20:56, Martin Abente >> 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 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 5:11 AM, Tomeu Vizoso wrote: > On Thu, Jun 10, 2010 at 20:56, Martin Abente > 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 >>> 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] [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] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 8, 2010 at 5:54 AM, Michael Stone 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. : > > 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
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 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 > 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] [DESIGN] Alerting users in case of write errors (sl#1842)
On Thu, Jun 10, 2010 at 20:56, Martin Abente 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 >> 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] [PATCH] Enhancements to Pippy UI
Looks like more extensive testing has unearthed an issue... (caused by a combination of loading examples and performing undo/redo in a shared Pippy session) The following assertion fails... GtkSourceView-CRITICAL **: gtk_source_undo_manager_undo: assertion `undo_action != NULL' failed Cheers, Anish On Fri, Jun 11, 2010 at 2:42 AM, Anish Mangal wrote: > Point taken :) > > Anish Mangal > > > > On Fri, Jun 11, 2010 at 2:41 AM, Benjamin M. Schwartz > wrote: >> Looks good to me, though I haven't tested it. A comment on "if not >> self.initiating", to explain the intent, might be nice. >> >> --Ben >> >> > ___ 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 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
[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