Re: [Sugar-devel] Bug tracker enhancements
On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote: Hi, Our current trac instance is missing some basic functionality: - versions per component: a really simple enhancement would be to have a text field (maybe some versions (sugar core) you can select from) but that we do not have to keep the list updated for each activity - milestones should be on a component basis as well (similar to versions) - I want to make certain fields only being available with certain permissions (a milestone and priority can only be set by the mainteiner, the severity by the bugsquad (see new fedora policy)) - having a clear separation from the Soas component - if we have the things from above this is maybe not as critical, otherwise I would suggest to get a new instance for Soas Can someone help to get there? Is trac giving us that functionality? Other trac software we should consider (besides bugzilla :)? redmine,redmine,redmine much easier to set up, maintain, administer than trac and has a much more active community developing useful plugins Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Paint improvements?
On Wed, Jul 08, 2009 at 07:41:33PM -0400, Caroline Meeks wrote: Nod, I've done that for Memorize and maybe we will for Paint too. It will take some thought to get it right and I've got a lot on my plate right now. Worth it if it turns into code but right now I'm wondering what is the best path forward? Sugarizing Tux, Improving Paint or adding features to Colors? It mostly depends on what programmers out there are interested. If Tuxpaint satisfies all needs and new features list for Paint and Colors! is not short, I guess its much easier to add save-to-journal feature to Tuxpaint. I just spent some time with Tuxpaint. I like it much better then paint. More features and they are easier to use. We asked the students to create a picture for vocabulary words. I think some of the stamp features and such in Tuxpaint would have helped some of the kids without as much native atistic talent to still produce recognizable results. I think the artists are going to go wild with some of the magic features. It really looks like fun. I don't know how well it will work on a small screen like an XO or netbook. Maybe someone else can take a look? its easy to test in sugar-emulator: $ sugar-emulator -i 640x480 I run Tuxpaint in 640x480 and it looks nice(Tuxpaint scales pretty well) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on a Stick - and Csound
On Tue, Jun 30, 2009 at 03:48, Aleksey Limalsr...@member.fsf.org wrote: On Mon, Jun 29, 2009 at 08:14:26PM -0400, Art Hunkins wrote: Does anyone have insight concerning this response from Victor Lazzarini of the csound-devel listserv? (Victor wrote the csndsugui activity for Sugar and is responsible for the Csound 5.08.91 rpm package.) My USB drive has nothing on it but Sugar, and we've no idea what module Python is trying to load that might be absent. Thanks for any ideas. (Of course, when Csound 5.10 appears as a Sugar update, I'll be installing it to see if this helps.) just an option, rebuild _csnd module in soas environment and it should fix problem anyway Have filed https://bugzilla.redhat.com/show_bug.cgi?id=510423 about this. Regards, Tomeu -- Aleksey ___ 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] Bug tracker enhancements
On 07/09/2009 08:06 AM, Bryan Berry wrote: On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote: Hi, Our current trac instance is missing some basic functionality: - versions per component: a really simple enhancement would be to have a text field (maybe some versions (sugar core) you can select from) but that we do not have to keep the list updated for each activity - milestones should be on a component basis as well (similar to versions) - I want to make certain fields only being available with certain permissions (a milestone and priority can only be set by the mainteiner, the severity by the bugsquad (see new fedora policy)) - having a clear separation from the Soas component - if we have the things from above this is maybe not as critical, otherwise I would suggest to get a new instance for Soas Can someone help to get there? Is trac giving us that functionality? Other trac software we should consider (besides bugzilla :)? redmine,redmine,redmine much easier to set up, maintain, administer than trac and has a much more active community developing useful plugins Does redmine solve the cases I described above? Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] prep for an article
On Thu, Jul 9, 2009 at 02:57, Eduardo H. Silvahoboprim...@gmail.com wrote: 2009/7/8 Jeff Elkner j...@elkner.net: Ann, Luke tells me that: 1. The chats are stored in the journal, but we don't know if there is an easy way to move them to a flash drive (Luke is trying as I type). Chat entries in the journal can be opened with Write.. Or any other text editor. You can put them into a usb stick by dragging the journal entry to the stick icon in the bottom. Regards, Tomeu 2. Alt-1 puts a screen shot in the journal. We can drag it to a USB stick from there. Good questions... Thanks! jeff On Wed, Jul 8, 2009 at 4:42 PM, a k a.akenn...@gmail.com wrote: Jeff, Two quick questions: 1) can we capture the text of the chats the students are having? (I'd like to do a linguistic analysis--ESPECIALLY if they chat after class--WILL THEY DISCUSS Scratch procedures? 2) can we capture a photo (a still) of a Scratch screen? (to illustrate) hasta manana, aa ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Nobody understands Keep
Hi, Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. Even with all the expertise on-site they seem to have been advising the (incorrect) use of the Keep button here: http://lists.sugarlabs.org/archive/iaep/2009-July/007038.html and then they wondered why they had 2 copies in the Journal. I have seen misuse of this button by the country teams in Ethiopia and Paraguay, in both cases they were giving teacher training and teaching the teachers the wrong thing... Perhaps it's time for a rethink/redesign. This functionality could be moved to the journal itself, in a place where it can be presented with more context, something like Create duplicate copy. Or even some kind of visual feedback (to appear after clicking Keep) that makes it pretty obvious that you've just forked your work - that way you'd quickly learn the true functionality and know when and when not to use it. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands Keep
On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Perhaps it's time for a rethink/redesign. This functionality could be moved to the journal itself, in a place where it can be presented with more context, something like Create duplicate copy. Or even some kind of visual feedback (to appear after clicking Keep) that makes it pretty obvious that you've just forked your work - that way you'd quickly learn the true functionality and know when and when not to use it. Yes, 100% agree. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands Keep
On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. That's not far from the truth, right? At least in any work-losing or surprising way... In case anyone lacks context, here's what the HIG says about keep: it's saving a copy/backup file: activities can ... specify keep-hints which prompt the system to keep a copy. ... a child may choose to invoke a keep-hint by selecting the keep in journal button ... -- http://wiki.sugarlabs.org/go/Design_Team/Human_Interface_Guidelines#The_Notion_of_.22Keeping.22 Are there any other discussions like activity versioning and datastore versioning that are relevant that people could share for context? some kind of visual feedback (to appear after clicking Keep) that makes it pretty obvious that you've just forked your work - that way you'd quickly learn the true functionality and know when and when not to use it. Good idea. Daniel Martin pgpWE2MkPSaZP.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands Keep
On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. That's not far from the truth, right? At least in any work-losing or surprising way... It's far from the truth in that it's not normally what you want to do. To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands Keep
On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. That's not far from the truth, right? At least in any work-losing or surprising way... It's far from the truth in that it's not normally what you want to do. My quoting-foo is bad, so I've caused confusion (in myself, too :)). To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. This is a great explanation -- it should be in the HIG or something. Daniel Martin pgpWVf3l0Cxrl.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracker enhancements
Adding Chris Rowe (also using Redmine) and Noah coderanger Kantrowitz, of Trac fame. On Thu, 2009-07-09 at 10:42 +0200, Simon Schampijer wrote: On 07/09/2009 08:06 AM, Bryan Berry wrote: On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote: Hi, Our current trac instance is missing some basic functionality: - versions per component: a really simple enhancement would be to have a text field (maybe some versions (sugar core) you can select from) but that we do not have to keep the list updated for each activity - milestones should be on a component basis as well (similar to versions) - I want to make certain fields only being available with certain permissions (a milestone and priority can only be set by the mainteiner, the severity by the bugsquad (see new fedora policy)) - having a clear separation from the Soas component - if we have the things from above this is maybe not as critical, otherwise I would suggest to get a new instance for Soas Can someone help to get there? Is trac giving us that functionality? Other trac software we should consider (besides bugzilla :)? redmine,redmine,redmine much easier to set up, maintain, administer than trac and has a much more active community developing useful plugins Does redmine solve the cases I described above? Simon -- // 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] css selector
jQuery uses Sizzle, which uses native selectors whenever it can. You can see in that graph the green bar (jQuery 1.2.7 experimental) is only a sliver slower than native selectors, when available. Even without native selectors, Sizzle is very fast and I doubt it'll be a bottleneck for you. If I were you, I'd stick to jQuery or use Sizzle directly if jQuery is inappropriate for some other reason. 2009/7/9 Bryan Berry br...@olenepal.org: for our code, i would prefer to use jquery selectors, it will make our code a lot more portable Also, for the purpose of getting translation strings, speed not so important. On Thu, 2009-07-09 at 01:53 -0500, Felipe López Toledo wrote: Hi Byan. Since I'm printing everything that seems useful, I found this: http://hacks.mozilla.org/2009/06/dom-selectors-api/ summary: native css selectors are faster than other css selectors maybe it's not important.. but (for a moment) I was thinking jQuery css selector vs native css selectors: what do we must use? felipe -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracker enhancements
here is the main features page for redmine http://www.redmine.org/wiki/redmine/Features On Thu, 2009-07-09 at 10:42 +0200, Simon Schampijer wrote: On 07/09/2009 08:06 AM, Bryan Berry wrote: On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote: Hi, If u make each component a subproject, u can set individual milestones, and milestones for the larger project - I want to make certain fields only being available with certain permissions (a milestone and priority can only be set by the mainteiner, the severity by the bugsquad (see new fedora policy) users can have different roles in different projects/components there is reporter, developer, administrator each w/ different rights but u can also create custom roles, like in this image http://www.redmine.org/screenshots/role_permissions.png - having a clear separation from the Soas component - if we have the things from above this is maybe not as critical, otherwise I would suggest to get a new instance for Soas Most definitely in this case. Another nice feature is that u can embed a google calendar into redmine, w/ important dates, not necessarily code related, such as linux tag, SoAS demos, community events. There is also a neat Vote plugin which lets users http://www.redmine.org/boards/3/topics/5506 vote to indicate that particular issues are important to them. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] prep for an article
On Thu, Jul 9, 2009 at 6:04 AM, Martin Dengler mar...@martindengler.comwrote: On Wed, Jul 08, 2009 at 05:54:35PM -0400, Jeff Elkner wrote: On Wed, Jul 8, 2009 at 4:42 PM, a k a.akenn...@gmail.com wrote: 1) can we capture the text of the chats the students are having? (I'd like to do a linguistic analysis--ESPECIALLY if they chat after class--WILL THEY DISCUSS Scratch procedures? 1. The chats are stored in the journal, but we don't know if there is an easy way to move them to a flash drive (Luke is trying as I type). Are you going to tell the kids you're spying on their Chats? :( Of course we are, Martin! In fact, I plan to use this opportunity as a teachable moment to discuss the difference between public speech and private speech and the implications of things like recorded chat files as they impact privacy in the 21st century. jeff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracker enhancements
On Thu, 2009-07-09 at 16:56 +0545, Bryan Berry wrote: here is the main features page for redmine http://www.redmine.org/wiki/redmine/Features On Thu, 2009-07-09 at 10:42 +0200, Simon Schampijer wrote: On 07/09/2009 08:06 AM, Bryan Berry wrote: On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote: Hi, If u make each component a subproject, u can set individual milestones, and milestones for the larger project - I want to make certain fields only being available with certain permissions (a milestone and priority can only be set by the mainteiner, the severity by the bugsquad (see new fedora policy) users can have different roles in different projects/components there is reporter, developer, administrator each w/ different rights but u can also create custom roles, like in this image http://www.redmine.org/screenshots/role_permissions.png Very interesting. We have a demo redmine instance here: http://prj.sugarlabs.org/ Would you like to help configure it to give us an idea of how it would work in practice? -- // 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] Datastore redesign
On Mon, Jul 6, 2009 at 16:33, Eben Eliasone...@laptop.org wrote: On Mon, Jul 6, 2009 at 10:02 AM, Sascha Silbesascha-ml-ui-sugar-de...@silbe.org wrote: On Mon, Jul 06, 2009 at 12:29:53PM +0200, Tomeu Vizoso wrote: Agreed. I have to say that your proposal is excellent, congratulations! Thanks, I'm flattered. :) Is the asynchronous API design useful enough to warrant more complex implementation? I'm not sure, but I think that whatever decision we take should be made based on actual usage of the DS. What about proposing an example of how an existing activity would be modified to use the new API? OK, will work on one. - For save() calls activity needs to wait for result (containing new version_id) before it can invoke save() again for the same object which can take quite some time if save() is sync - especially if other activities are saving at the same time. What about having a separate call that returns synchronously a new tree_id and/or version_id? Interesting idea, need to think about it. As we're going to use UUIDs not using requested versions shouldn't be an issue (for other version number schemes like the one you propose below holes in the numbering could be troublesome). I think holes can be expected, so we should definitely be prepared for them. Making the API fully asynchronous is the cause for much of the complexity of my proposal, but if we eliminate the queueing the response times for write accesses and checkout() can be very long even for unrelated operations. Why for unrelated operations? Because we're serializing VCS operations. They are IO bound (more specifically: disk bound) and parallelisation would only lead to IO starvation, especially for HDDs. # do we want an optimized way to determine (only) the branch HEADs of a given tree_id? This depends on the intended UI. My opinion is that if we branch at every interesting modification (triggered by the activity detecting an interesting change or by the user clicking on the Keep button), we I don't think we need to branch in these instances. These events should create new versions, but not necessarily new branches. In my proposal, branch is not a concept directly exposed to the user. Is just an artefact that allows the journal to display the relevant info to an user. If we branch at the following events, displaying only HEADs of branches in the journal list view makes sense for the user: - new tree_id, - resume entry, - keep button, - after a big change in the activity model (user deletes the whole drawing, etc). There are other ways to manage what we want, but this approach made it very easy to implement. Just to make sure I'm understood, I see why using branches this way may seem conceptually wrong, it's not how we would work in a VCS or CMS. But by creating new branches at those points and displaying only HEADs of branches in the list view is the simplest way I found of displaying the relevant entries in a robust way (resisting activity crashes). would like to display in the object list all the HEADs of each branch in each tree_id. In that case yes, we need a way to retrieve that list that is fast on both the client and the server side. My imagined usage of branches was to create them automatically upon altering a non-HEAD version. This makes sense to me, personally. A user basing off an old version could mean the newer version is broken (in that case promoting the new version to the HEAD of the current branch makes more sense) or that (s)he uses the older version as a kind of template to create derivates (so creating a branch would make most sense). But I'm open to alternative suggestions. We'd most likely need a way to explicitly create branches then. # using symlink instead of hardlink for incoming queue since we want to support directory trees, not just files What justifies this new requirement? That it's a) of use to activities (IIRC some of them use ZIP files right instead now), This has its own merits, though. Encapsulating the related files as a single archive makes transporting the file around, or sending it to a friend, trivial. It's good for the same reason that activity bundles are good. But this may be considered an internal implementation detail of the DS, unless we want to support users directly browsing the DS backend. b) easy enough to achieve with the new design and c) leads to better delta compression and thus disk space effiency. # since an index rebuild can take a lot of time we need to provide UI feedback while doing that Any I/O operation can potentially take a lot of time, but with the current version of the DS rebuilding an index with a few thousands of entries is not so slow on the XO. We should never need to rebuild the index, so this new requirement might not be justified (given the current resources, all the other work we need to do, etc). OK, good to know index rebuilding is fast. So the simple,
Re: [Sugar-devel] Nobody understands Keep
On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote: On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. That's not far from the truth, right? At least in any work-losing or surprising way... It's far from the truth in that it's not normally what you want to do. My quoting-foo is bad, so I've caused confusion (in myself, too :)). To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. This is a great explanation -- it should be in the HIG or something. But the biggest problem is how do we explain this to users without them having to read the HIG (or manual)? Should be called Keep a copy? Regards, Tomeu Daniel Martin ___ 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] Bug tracker enhancements
sure, i can work on it. i can try to put a couple hours into it tomorrow. can u send me the passwd in a pm? On Thu, 2009-07-09 at 07:40 -0400, Bernie Innocenti wrote: On Thu, 2009-07-09 at 16:56 +0545, Bryan Berry wrote: here is the main features page for redmine http://www.redmine.org/wiki/redmine/Features On Thu, 2009-07-09 at 10:42 +0200, Simon Schampijer wrote: On 07/09/2009 08:06 AM, Bryan Berry wrote: On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote: Hi, If u make each component a subproject, u can set individual milestones, and milestones for the larger project - I want to make certain fields only being available with certain permissions (a milestone and priority can only be set by the mainteiner, the severity by the bugsquad (see new fedora policy) users can have different roles in different projects/components there is reporter, developer, administrator each w/ different rights but u can also create custom roles, like in this image http://www.redmine.org/screenshots/role_permissions.png Very interesting. We have a demo redmine instance here: http://prj.sugarlabs.org/ Would you like to help configure it to give us an idea of how it would work in practice? -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracker enhancements
On Thu, 2009-07-09 at 07:40 -0400, Bernie Innocenti wrote: On Thu, 2009-07-09 at 16:56 +0545, Bryan Berry wrote: Would you like to help configure it to give us an idea of how it would work in practice? bernie: to be productive i will occasionally need your help. What times will u be online tomorrow? It would help if u r using the latest stable version 0.8.4, which I believe uses a newish version of rails http://rubyforge.org/frs/?group_id=1850 -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracker enhancements
On Thu, 2009-07-09 at 17:53 +0545, Bryan Berry wrote: sure, i can work on it. i can try to put a couple hours into it tomorrow. You should have received login info by email. -- // 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] Bug tracker enhancements
On Thu, 2009-07-09 at 18:01 +0545, Bryan Berry wrote: On Thu, 2009-07-09 at 07:40 -0400, Bernie Innocenti wrote: On Thu, 2009-07-09 at 16:56 +0545, Bryan Berry wrote: Would you like to help configure it to give us an idea of how it would work in practice? bernie: to be productive i will occasionally need your help. What times will u be online tomorrow? Today I plan to be online all day. Tomorrow I will be with a customer all day, probably online but distracted and unresponsive. -- // 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] Nobody understands Keep
On Thu, Jul 09, 2009 at 02:03:06PM +0200, Tomeu Vizoso wrote: On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote: On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. This is a great explanation -- it should be in the HIG or something. But the biggest problem is how do we explain this to users without them having to read the HIG (or manual)? Of course. Should be called Keep a copy? Backup? Daniel Martin Regards, Tomeu Martin pgpSt5Tw3PtSc.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore redesign
On Thu, Jul 9, 2009 at 8:00 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Mon, Jul 6, 2009 at 16:33, Eben Eliasone...@laptop.org wrote: On Mon, Jul 6, 2009 at 10:02 AM, Sascha Silbesascha-ml-ui-sugar-de...@silbe.org wrote: On Mon, Jul 06, 2009 at 12:29:53PM +0200, Tomeu Vizoso wrote: Agreed. I have to say that your proposal is excellent, congratulations! Thanks, I'm flattered. :) Is the asynchronous API design useful enough to warrant more complex implementation? I'm not sure, but I think that whatever decision we take should be made based on actual usage of the DS. What about proposing an example of how an existing activity would be modified to use the new API? OK, will work on one. - For save() calls activity needs to wait for result (containing new version_id) before it can invoke save() again for the same object which can take quite some time if save() is sync - especially if other activities are saving at the same time. What about having a separate call that returns synchronously a new tree_id and/or version_id? Interesting idea, need to think about it. As we're going to use UUIDs not using requested versions shouldn't be an issue (for other version number schemes like the one you propose below holes in the numbering could be troublesome). I think holes can be expected, so we should definitely be prepared for them. Making the API fully asynchronous is the cause for much of the complexity of my proposal, but if we eliminate the queueing the response times for write accesses and checkout() can be very long even for unrelated operations. Why for unrelated operations? Because we're serializing VCS operations. They are IO bound (more specifically: disk bound) and parallelisation would only lead to IO starvation, especially for HDDs. # do we want an optimized way to determine (only) the branch HEADs of a given tree_id? This depends on the intended UI. My opinion is that if we branch at every interesting modification (triggered by the activity detecting an interesting change or by the user clicking on the Keep button), we I don't think we need to branch in these instances. These events should create new versions, but not necessarily new branches. In my proposal, branch is not a concept directly exposed to the user. Is just an artefact that allows the journal to display the relevant info to an user. If we branch at the following events, displaying only HEADs of branches in the journal list view makes sense for the user: - new tree_id, - resume entry, - keep button, - after a big change in the activity model (user deletes the whole drawing, etc). There are other ways to manage what we want, but this approach made it very easy to implement. Just to make sure I'm understood, I see why using branches this way may seem conceptually wrong, it's not how we would work in a VCS or CMS. But by creating new branches at those points and displaying only HEADs of branches in the list view is the simplest way I found of displaying the relevant entries in a robust way (resisting activity crashes). That's fine, assuming these are actually the entries we want to show, but I'm not sure that's always the case. For instance, we might show only the most recent version in the object view, while showing each version within the action view. If we store action-objects as Ben proposed, we may have an entirely different way of querying what should be shown in the actions view anyway. We've also had some ideas on how to expose the branching structure within the version popup, in which case branching as one would in a VCS would make more sense. Eben would like to display in the object list all the HEADs of each branch in each tree_id. In that case yes, we need a way to retrieve that list that is fast on both the client and the server side. My imagined usage of branches was to create them automatically upon altering a non-HEAD version. This makes sense to me, personally. A user basing off an old version could mean the newer version is broken (in that case promoting the new version to the HEAD of the current branch makes more sense) or that (s)he uses the older version as a kind of template to create derivates (so creating a branch would make most sense). But I'm open to alternative suggestions. We'd most likely need a way to explicitly create branches then. # using symlink instead of hardlink for incoming queue since we want to support directory trees, not just files What justifies this new requirement? That it's a) of use to activities (IIRC some of them use ZIP files right instead now), This has its own merits, though. Encapsulating the related files as a single archive makes transporting the file around, or sending it to a friend, trivial. It's good for the same reason that activity bundles are good. But this may be considered an internal implementation detail of the DS, unless we want to support users directly
Re: [Sugar-devel] SoAS Testing with XS
It was worth a try but I see exactly the same behavior on the media lab jabber server. One thing I think I am noticing. It seems like one machine at a time is connected to the Jabber Server. What happens when a machine connects? Is there anyway that one machine connecting could cause another to disconnect? Are these machines in some way replicating something about them when the server things it should be unique? Could there be some sort of firewall or a caching service that decides its a duplicate and cuts one of them off? On Wed, Jul 8, 2009 at 11:17 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Caroline Meeks wrote: 1. Fix Jabber collaboration - We have a mysterious bug (that is also being worked on in parallel) that keeps dropping the connection to the externally hosted Jabber Server (jabber.sl.org) That's irritating. Have you tried other servers? For example, schoolserver.media.mit.edu has been very reliable for me. OLPC ran collaboration jabber servers for very large numbers of people following G1G1, and the only major problem was server overload (when serving far more than 18 users). It is possible, and maybe the people who built those servers have some advice. --Ben -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands Keep
On Thu, Jul 9, 2009 at 8:03 AM, Gary C Marting...@garycmartin.com wrote: On 9 Jul 2009, at 11:29, Martin Dengler wrote: On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. +1 That's not far from the truth, right? At least in any work-losing or surprising way... It's far from the truth in that it's not normally what you want to do. My quoting-foo is bad, so I've caused confusion (in myself, too :)). To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/ reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. Exactly. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. Not exactly. This would work, but I wouldn't call this a recommended use. To start a new document from a template, it would be more appropriate to Create a copy (which should exist in the Journal itself), or Keep a copy (which would do the same thing, but from within the activity) This is a great explanation -- it should be in the HIG or something. Hmmm, this still does not cover the special behaviour that Sugar now treats those Journal entries with. All these entries will have the same activity_id, Sugar shell uses this ID to know if it already has Yes, that's intended. Keep actually means Keep a new version We don't have proper versions yet, but that's the model. an Activity resumed. If an Activity with a matching activity_id is already instanced, resuming one of the older/newer entries will just switch you to the existing instance (with no change of content). Collaborating, with the Sugar shell treating any single entry in this long chain of entries as the same, is likely to cause quite some confusion for those involved as well... Perhaps visually showing all 'kept' entries as one single block (not multiple entries), with the past ones visually 'depreciated' in some This was our thought behind the design mockups for the object view. There would be one entry per object in the list, with a way to expand or reveal past versions. The opposite, however, is true of the design for the action list. Each version is created as part of a unique activity session, so each of these would be recorded as a distinct action, and refer to the associated version. way (like old undo states), might help? Perhaps the keep button is just wrong altogether. I think it's really important to have a manual method of invoking the equivalent of saving. Maybe labeling the Keep button something like Keep extra version would help. Maybe Sascha's GSoC version work will help us sort out the correct behaviour here. Yes, it may. Eben Regards, --Gary ___ 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] Nobody understands Keep
On Thu, Jul 9, 2009 at 8:03 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote: On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. That's not far from the truth, right? At least in any work-losing or surprising way... It's far from the truth in that it's not normally what you want to do. My quoting-foo is bad, so I've caused confusion (in myself, too :)). To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. This is a great explanation -- it should be in the HIG or something. But the biggest problem is how do we explain this to users without them having to read the HIG (or manual)? Should be called Keep a copy? Careful, here. keep a copy really is a fundamentally different action. Keeping a copy will result in a new tree_id; Just keeping (or keeping a new version) will only result in a new version_id. We need to find a way to make these actions distinct. Eben Regards, Tomeu Daniel Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: SoAS Testing with XS
Sorry, this was meant to go to the list no just Caroline. Begin forwarded message: From: Gary C Martin g...@garycmartin.com Date: 9 July 2009 15:54:34 BST To: Caroline Meeks carol...@solutiongrove.com Subject: Re: [Sugar-devel] SoAS Testing with XS On 9 Jul 2009, at 15:19, Caroline Meeks wrote: It was worth a try but I see exactly the same behavior on the media lab jabber server. One thing I think I am noticing. It seems like one machine at a time is connected to the Jabber Server. What happens when a machine connects? Is there anyway that one machine connecting could cause another to disconnect? Are these machines in some way replicating something about them when the server things it should be unique? Could there be some sort of firewall or a caching service that decides its a duplicate and cuts one of them off? Ohh geeezz... How did you make the sticks? Did you boot one and tweak it, then clone that one? There are all sorts of files generated when you boot a system that make it unique that would need to be very carefully erased to make the stick image was 'fresh'. No one has a full list of all these files and their various interactions, though I think some have tried. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Paint improvements?
On Thu, Jul 09, 2009 at 07:28:09AM -0500, David Farning wrote: On Wed, Jul 8, 2009 at 5:41 PM, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 08, 2009 at 06:26:00PM -0400, Caroline Meeks wrote: Nod, I've done that for Memorize and maybe we will for Paint too. It will take some thought to get it right and I've got a lot on my plate right now. Worth it if it turns into code but right now I'm wondering what is the best path forward? Sugarizing Tux, Improving Paint or adding features to Colors? It mostly depends on what programmers out there are interested. If Tuxpaint satisfies all needs and new features list for Paint and Colors! is not short, I guess its much easier to add save-to-journal feature to Tuxpaint. I am in occasional contact with Bill Kendrick the lead developer for tuxpaint. I try to reach out to him and the rest of the tuxpaint team to work more closely with Sugar Labs. The save-to-journal feature shouldn't be a problem(since this will be local change in Tuxpaint's code). The relly hard problem is sharing mode in Tuxpaint. There is a ticket for this reason - #887 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on a Stick - and Csound
On Thu, Jul 9, 2009 at 17:29, Peter Robinsonpbrobin...@gmail.com wrote: Hi, Does your action on Tomeu's filing mean that this Python bindings issue is now fixed? No it doesn't, its just what I suspect is the issue. I don't currently have time to investigate it further so I put the note on the bug so if anyone else has the time it might provide direction for them. I unfortunately also don't have time now, but from the look of it I think Peter is on the right track. If so, any idea: 1) when an SoaS update might be available? 2) when it would be incorporated into Strawberry? I can't answer either of those. You should get into contact with the SoaS team, I'm forwarding it again to sugar-devel. Please keep conversations on-list so everybody benefits from this info. Regards, Tomeu I'm anxious to test it. Thanks to both of you for your help. Art Hunkins Peter - Original Message - From: Tomeu Vizoso to...@sugarlabs.org To: Aleksey Lim alsr...@member.fsf.org Cc: Art Hunkins abhun...@uncg.edu; sugar-devel@lists.sugarlabs.org Sent: Thursday, July 09, 2009 4:16 AM Subject: Re: [Sugar-devel] Sugar on a Stick - and Csound On Tue, Jun 30, 2009 at 03:48, Aleksey Limalsr...@member.fsf.org wrote: On Mon, Jun 29, 2009 at 08:14:26PM -0400, Art Hunkins wrote: Does anyone have insight concerning this response from Victor Lazzarini of the csound-devel listserv? (Victor wrote the csndsugui activity for Sugar and is responsible for the Csound 5.08.91 rpm package.) My USB drive has nothing on it but Sugar, and we've no idea what module Python is trying to load that might be absent. Thanks for any ideas. (Of course, when Csound 5.10 appears as a Sugar update, I'll be installing it to see if this helps.) just an option, rebuild _csnd module in soas environment and it should fix problem anyway Have filed https://bugzilla.redhat.com/show_bug.cgi?id=510423 about this. Regards, Tomeu -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Paint improvements?
On Thu, Jul 9, 2009 at 11:46 AM, Aleksey Limalsr...@member.fsf.org wrote: On Thu, Jul 09, 2009 at 07:28:09AM -0500, David Farning wrote: On Wed, Jul 8, 2009 at 5:41 PM, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 08, 2009 at 06:26:00PM -0400, Caroline Meeks wrote: Nod, I've done that for Memorize and maybe we will for Paint too. It will take some thought to get it right and I've got a lot on my plate right now. Worth it if it turns into code but right now I'm wondering what is the best path forward? Sugarizing Tux, Improving Paint or adding features to Colors? It mostly depends on what programmers out there are interested. If Tuxpaint satisfies all needs and new features list for Paint and Colors! is not short, I guess its much easier to add save-to-journal feature to Tuxpaint. I am in occasional contact with Bill Kendrick the lead developer for tuxpaint. I try to reach out to him and the rest of the tuxpaint team to work more closely with Sugar Labs. The save-to-journal feature shouldn't be a problem(since this will be local change in Tuxpaint's code). The relly hard problem is sharing mode in Tuxpaint. There is a ticket for this reason - #887 -- Aleksey As someone who has hacked on Albert Cahalan's original XO-1 port of Tuxpaint (see the tuxpaint entry on http://wiki.laptop.org/go/Activities/All) I'd be glad to help with further sugarizing tuxpaint. What I did was to adapt it to the rainbow requirements for the XO-1 (store data in the right directories, etc.) and proper startup from the ring. No integration with the journal or implementation of sharing. Note that a full installation of tuxpaint is very big, due to all the examples and translations. Probably too big for a 1G stick SoaS. Aleksey, what are your ideas about integration with the journal? Provide a python glue layer? Or implement it directly in C? Anyway, let me know what I can do. Ton van Overbeek ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands Keep
Hi All, 8 months in the tank at 1CC sitting next to Eben, you'd think I know how this was designed to work ;-( I've actually read the HIG too! I see two case here: Case 1 - Create something in one activity and then use it right away another. I forgot that switching to a new activity puts a copy of the old one on the Journal (20+ e-mails on that subject alone last year!). I'll try Paint then just switch to Memorize next time I'm in a class and see if that works and makes sense to the kids. One additional confusion is that Memorize has Save Game and Load Game options. You need to create a game then save it then load it from the Journal to play a new game you just created. Looks like the programmer for Memorize didn't grok the HIG details on Keep either, or did they? Case 2 - Create something in one activity then create something else in the same activity. The launch, create, quit, launch again work flow seems inelegant to say the least. A New button which saves the current file and opens a new blank file sounds like nice way to make this easier. BTW everyone I have seen use Sugar has trouble finding the Stop button. FYI my philosophy is that the user is never wrong. They may do something which results in unanticipated consequences or they may do something which the programmer didn't intend, but its never wrong. If they click a few extra times or lose their data until they figure out a way to do what they want, so be it. The tools are there to be used as they see fit. The trainer on the other hand should know better... Thanks, Greg S ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: SoAS Testing with XS
On Thu, Jul 9, 2009 at 11:00 AM, Gary C Marting...@garycmartin.com wrote: Sorry, this was meant to go to the list no just Caroline. Begin forwarded message: From: Gary C Martin g...@garycmartin.com Date: 9 July 2009 15:54:34 BST To: Caroline Meeks carol...@solutiongrove.com Subject: Re: [Sugar-devel] SoAS Testing with XS On 9 Jul 2009, at 15:19, Caroline Meeks wrote: It was worth a try but I see exactly the same behavior on the media lab jabber server. One thing I think I am noticing. It seems like one machine at a time is connected to the Jabber Server. What happens when a machine connects? Is there anyway that one machine connecting could cause another to disconnect? Are these machines in some way replicating something about them when the server things it should be unique? Could there be some sort of firewall or a caching service that decides its a duplicate and cuts one of them off? Ohh geeezz... How did you make the sticks? Did you boot one and tweak it, then clone that one? There are all sorts of files generated when you boot a system that make it unique that would need to be very carefully erased to make the stick image was 'fresh'. No one has a full list of all these files and their various interactions, though I think some have tried. The jabber id is generated from ~/.sugar/owner.key. Removing ~/.sugar/owner.key and ~/.sugar/owner.key.pub generates a new key after reboot and the jabber id is reset. Dave Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Paint improvements?
On Thu, Jul 09, 2009 at 12:07:11PM -0400, Ton van Overbeek wrote: On Thu, Jul 9, 2009 at 11:46 AM, Aleksey Limalsr...@member.fsf.org wrote: On Thu, Jul 09, 2009 at 07:28:09AM -0500, David Farning wrote: On Wed, Jul 8, 2009 at 5:41 PM, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 08, 2009 at 06:26:00PM -0400, Caroline Meeks wrote: Nod, I've done that for Memorize and maybe we will for Paint too. It will take some thought to get it right and I've got a lot on my plate right now. Worth it if it turns into code but right now I'm wondering what is the best path forward? Sugarizing Tux, Improving Paint or adding features to Colors? It mostly depends on what programmers out there are interested. If Tuxpaint satisfies all needs and new features list for Paint and Colors! is not short, I guess its much easier to add save-to-journal feature to Tuxpaint. I am in occasional contact with Bill Kendrick the lead developer for tuxpaint. I try to reach out to him and the rest of the tuxpaint team to work more closely with Sugar Labs. The save-to-journal feature shouldn't be a problem(since this will be local change in Tuxpaint's code). The relly hard problem is sharing mode in Tuxpaint. There is a ticket for this reason - #887 -- Aleksey As someone who has hacked on Albert Cahalan's original XO-1 port of Tuxpaint (see the tuxpaint entry on http://wiki.laptop.org/go/Activities/All) I'd be glad to help with further sugarizing tuxpaint. What I did was to adapt it to the rainbow requirements for the XO-1 (store data in the right directories, etc.) and proper startup from the ring. No integration with the journal or implementation of sharing. Note that a full installation of tuxpaint is very big, due to all the examples and translations. Probably too big for a 1G stick SoaS. Aleksey, what are your ideas about integration with the journal? Provide a python glue layer? Or implement it directly in C? I kept in mind implementing it in Tuxpaint's code in C, since DS API is just dbus API(the good example is etoys) but I didnt think about it yet. Anyway, let me know what I can do. maybe implementing save-to-Journal feature ;) if you are interested in sent me your nick on git.sl.o and I'll add you to commiter list of http://git.sugarlabs.org/projects/tux-paint. I keep upstream code in upstream branch(now its 0.9.20), you would want to switch it to new release or trunk, then just rewrite upstream branch(I guess its not worth keeping all upstream commits) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Please use Feature 0.86 category for all 0.86 features
Hi all, I think having all 0.86 features in one category Feature 0.86 makes process easier(for developers and users). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [Marketing] netbook as terminology
Dave Bauer dave.ba...@gmail.com writes: On Fri, Jul 3, 2009 at 12:19 PM, Bastien bastiengue...@googlemail.com wrote: Yes. In the meantime, I would *love* to see the XS server running, and a tutorial on how to use Sugar with non-XO computers connected thru a XS server... IMHO it's a promise that OLPC/Sugar cannot afford to bypass. This is already working. For example, if you use Sugar on a Stick you are using an XS that can work with XO and non-XO computers today. This is 0.5.2 XS installed from the ISO and regularly updated via yum. If you take any installation of Sugar and set the collaboration server to jabber.sugarlabs.org it should work. No special configuration is needed to support Sugar on non-XO computers that I am aware of. Thanks. But that's when the Sugar machines are connected to the internet, right? What I was looking for is a How to set up a school server? when you don't have internet - i.e. when you need to use the server as an access point. This might be of interest in some of the french school we plan to deploy Soas. -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Switching between activities? (was Re: Nobody understands Keep)
Hi all, Greg Smith gregsmit...@gmail.com writes: I forgot that switching to a new activity puts a copy of the old one on the Journal (20+ e-mails on that subject alone last year!). This comment and Daniel's ones about the Keep button just make me wonder why Sugar should allow several activities to be open at the same time. Any strong case where this can be relevant? Actually I'm not suggesting to ditch switching itself, I just realized that switching could be quit-and-fetch-another-activity-from-journal. Then it would make sense to have another instance of the activity stored in the journal when switching to an activity. FYI my philosophy is that the user is never wrong. I have the same. And I've seen many instances with the XO where I had to explain why children shouldn't launch more than 3 or 4 activities. Hence this proposal. Perhaps you considered this idea before - in that case I'm interested in reading thru the discussion. Thanks, -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Switching between activities? (was Re: Nobody understands Keep)
The biggest downside is that some activities are very slow to launch... especially on the XO. -walter On Thu, Jul 9, 2009 at 7:30 PM, Bastien bastiengue...@googlemail.comwrote: Hi all, Greg Smith gregsmit...@gmail.com writes: I forgot that switching to a new activity puts a copy of the old one on the Journal (20+ e-mails on that subject alone last year!). This comment and Daniel's ones about the Keep button just make me wonder why Sugar should allow several activities to be open at the same time. Any strong case where this can be relevant? Actually I'm not suggesting to ditch switching itself, I just realized that switching could be quit-and-fetch-another-activity-from-journal. Then it would make sense to have another instance of the activity stored in the journal when switching to an activity. FYI my philosophy is that the user is never wrong. I have the same. And I've seen many instances with the XO where I had to explain why children shouldn't launch more than 3 or 4 activities. Hence this proposal. Perhaps you considered this idea before - in that case I'm interested in reading thru the discussion. Thanks, -- Bastien ___ 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] Switching between activities?
Walter Bender walter.ben...@gmail.com writes: The biggest downside is that some activities are very slow to launch... especially on the XO. I guess the downside for children to get stuck with too many open activities on their XO is bigger than that of waiting for an activity to launch -- especially when using the computer for learning purpose, where you don't really need to switch between many activities. This argument holds /a fortiori/ on other hardware, where launchtime is better. Anyway, was just a thought. -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] GPA collaboration Issues - owner key theory
We will delete ~/.sugar/owner.key and ~/.sugar/owner.key.pub when we reburn the sticks on Monday. However, my problem with this theory is that l've been cloning pretty much the same Stick from FOSSVT on. Other places we have multiple people using the same stick without this problem. However, we have mostly be using wireless not wired. Woudl that make a difference? On Thu, Jul 9, 2009 at 1:55 PM, Dave Bauer dave.ba...@gmail.com wrote: On Thu, Jul 9, 2009 at 11:00 AM, Gary C Marting...@garycmartin.com wrote: Sorry, this was meant to go to the list no just Caroline. Begin forwarded message: From: Gary C Martin g...@garycmartin.com Date: 9 July 2009 15:54:34 BST To: Caroline Meeks carol...@solutiongrove.com Subject: Re: [Sugar-devel] SoAS Testing with XS On 9 Jul 2009, at 15:19, Caroline Meeks wrote: It was worth a try but I see exactly the same behavior on the media lab jabber server. One thing I think I am noticing. It seems like one machine at a time is connected to the Jabber Server. What happens when a machine connects? Is there anyway that one machine connecting could cause another to disconnect? Are these machines in some way replicating something about them when the server things it should be unique? Could there be some sort of firewall or a caching service that decides its a duplicate and cuts one of them off? Ohh geeezz... How did you make the sticks? Did you boot one and tweak it, then clone that one? There are all sorts of files generated when you boot a system that make it unique that would need to be very carefully erased to make the stick image was 'fresh'. No one has a full list of all these files and their various interactions, though I think some have tried. The jabber id is generated from ~/.sugar/owner.key. Removing ~/.sugar/owner.key and ~/.sugar/owner.key.pub generates a new key after reboot and the jabber id is reset. Dave Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GPA collaboration Issues - owner key theory
Are you sure? I think we were deleting ~/.sugar completely before. Trying to save the journal etc makes it more complex. On Thu, Jul 9, 2009 at 9:53 PM, Caroline Meekscarol...@meekshome.com wrote: We will delete ~/.sugar/owner.key and ~/.sugar/owner.key.pub when we reburn the sticks on Monday. In addition to ~/.gconf and ~/.gconfd Dave However, my problem with this theory is that l've been cloning pretty much the same Stick from FOSSVT on. Other places we have multiple people using the same stick without this problem. However, we have mostly be using wireless not wired. Woudl that make a difference? On Thu, Jul 9, 2009 at 1:55 PM, Dave Bauer dave.ba...@gmail.com wrote: On Thu, Jul 9, 2009 at 11:00 AM, Gary C Marting...@garycmartin.com wrote: Sorry, this was meant to go to the list no just Caroline. Begin forwarded message: From: Gary C Martin g...@garycmartin.com Date: 9 July 2009 15:54:34 BST To: Caroline Meeks carol...@solutiongrove.com Subject: Re: [Sugar-devel] SoAS Testing with XS On 9 Jul 2009, at 15:19, Caroline Meeks wrote: It was worth a try but I see exactly the same behavior on the media lab jabber server. One thing I think I am noticing. It seems like one machine at a time is connected to the Jabber Server. What happens when a machine connects? Is there anyway that one machine connecting could cause another to disconnect? Are these machines in some way replicating something about them when the server things it should be unique? Could there be some sort of firewall or a caching service that decides its a duplicate and cuts one of them off? Ohh geeezz... How did you make the sticks? Did you boot one and tweak it, then clone that one? There are all sorts of files generated when you boot a system that make it unique that would need to be very carefully erased to make the stick image was 'fresh'. No one has a full list of all these files and their various interactions, though I think some have tried. The jabber id is generated from ~/.sugar/owner.key. Removing ~/.sugar/owner.key and ~/.sugar/owner.key.pub generates a new key after reboot and the jabber id is reset. Dave Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GPA collaboration Issues - owner key theory
Have we experimented with unmodified keys? -walter On Thu, Jul 9, 2009 at 9:53 PM, Caroline Meeks carol...@meekshome.comwrote: We will delete ~/.sugar/owner.key and ~/.sugar/owner.key.pub when we reburn the sticks on Monday. However, my problem with this theory is that l've been cloning pretty much the same Stick from FOSSVT on. Other places we have multiple people using the same stick without this problem. However, we have mostly be using wireless not wired. Woudl that make a difference? On Thu, Jul 9, 2009 at 1:55 PM, Dave Bauer dave.ba...@gmail.com wrote: On Thu, Jul 9, 2009 at 11:00 AM, Gary C Marting...@garycmartin.com wrote: Sorry, this was meant to go to the list no just Caroline. Begin forwarded message: From: Gary C Martin g...@garycmartin.com Date: 9 July 2009 15:54:34 BST To: Caroline Meeks carol...@solutiongrove.com Subject: Re: [Sugar-devel] SoAS Testing with XS On 9 Jul 2009, at 15:19, Caroline Meeks wrote: It was worth a try but I see exactly the same behavior on the media lab jabber server. One thing I think I am noticing. It seems like one machine at a time is connected to the Jabber Server. What happens when a machine connects? Is there anyway that one machine connecting could cause another to disconnect? Are these machines in some way replicating something about them when the server things it should be unique? Could there be some sort of firewall or a caching service that decides its a duplicate and cuts one of them off? Ohh geeezz... How did you make the sticks? Did you boot one and tweak it, then clone that one? There are all sorts of files generated when you boot a system that make it unique that would need to be very carefully erased to make the stick image was 'fresh'. No one has a full list of all these files and their various interactions, though I think some have tried. The jabber id is generated from ~/.sugar/owner.key. Removing ~/.sugar/owner.key and ~/.sugar/owner.key.pub generates a new key after reboot and the jabber id is reset. Dave Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- 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] GPA collaboration Issues - keepalive theory
The other theory we are working on is that something is not set to long enough in keepalive This theory is based on the logs saying that jabber had been disconnected probably because gabble and died. We are thinking that actually the hardware/network might just be slow. Collabora suggested that keepalive might be the problem. Has anybody put eyeballs on this code? Is there a timeout somewhere that we could extend? I am camping this weekend. We will next be at GPA for tesing on Tuesday. Thanks! Caroline -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GPA collaboration Issues - owner key theory
I tested this on my eeePC with soas. First I deleted gconf/gconfd and I got to pick my name and colors, but my jabber id was the same. So I removed owner.key(.pub) without gconf and i got a new key and my jabber id changed. I think it can't hurt to try it quick on some of the sticks before they are reburned. Dave On Thu, Jul 9, 2009 at 9:56 PM, Walter Benderwalter.ben...@gmail.com wrote: Have we experimented with unmodified keys? -walter On Thu, Jul 9, 2009 at 9:53 PM, Caroline Meeks carol...@meekshome.com wrote: We will delete ~/.sugar/owner.key and ~/.sugar/owner.key.pub when we reburn the sticks on Monday. However, my problem with this theory is that l've been cloning pretty much the same Stick from FOSSVT on. Other places we have multiple people using the same stick without this problem. However, we have mostly be using wireless not wired. Woudl that make a difference? On Thu, Jul 9, 2009 at 1:55 PM, Dave Bauer dave.ba...@gmail.com wrote: On Thu, Jul 9, 2009 at 11:00 AM, Gary C Marting...@garycmartin.com wrote: Sorry, this was meant to go to the list no just Caroline. Begin forwarded message: From: Gary C Martin g...@garycmartin.com Date: 9 July 2009 15:54:34 BST To: Caroline Meeks carol...@solutiongrove.com Subject: Re: [Sugar-devel] SoAS Testing with XS On 9 Jul 2009, at 15:19, Caroline Meeks wrote: It was worth a try but I see exactly the same behavior on the media lab jabber server. One thing I think I am noticing. It seems like one machine at a time is connected to the Jabber Server. What happens when a machine connects? Is there anyway that one machine connecting could cause another to disconnect? Are these machines in some way replicating something about them when the server things it should be unique? Could there be some sort of firewall or a caching service that decides its a duplicate and cuts one of them off? Ohh geeezz... How did you make the sticks? Did you boot one and tweak it, then clone that one? There are all sorts of files generated when you boot a system that make it unique that would need to be very carefully erased to make the stick image was 'fresh'. No one has a full list of all these files and their various interactions, though I think some have tried. The jabber id is generated from ~/.sugar/owner.key. Removing ~/.sugar/owner.key and ~/.sugar/owner.key.pub generates a new key after reboot and the jabber id is reset. Dave Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GPA collaboration Issues - keepalive theory
On Fri, Jul 10, 2009 at 1:59 PM, Caroline Meekscarol...@solutiongrove.com wrote: The other theory we are working on is that something is not set to long enough in keepalive The logs we saw earlier were clearly of a domain vs IP address mismatch. Did you try the fix that I've suggested (changing the 'jabber server' setting on the clients to match the expected domain name)? After the change, did it work? If things still fail, the logs should look radically different after that change. Are there new logs? cheers, 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] Nobody understands Keep
On Thu, Jul 9, 2009 at 7:55 PM, Eduardo H. Silvahoboprim...@gmail.com wrote: 2009/7/9 Tomeu Vizoso to...@sugarlabs.org: On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote: On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. That's not far from the truth, right? At least in any work-losing or surprising way... It's far from the truth in that it's not normally what you want to do. My quoting-foo is bad, so I've caused confusion (in myself, too :)). To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as insurance or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. This is a great explanation -- it should be in the HIG or something. But the biggest problem is how do we explain this to users without them having to read the HIG (or manual)? Should be called Keep a copy? +1 For a while, in the pt_PT translation of Sugar I did, I named the Keep button as Keep a copy. I urge again that keep a copy is not what is intended, in the long run. Without proper versions, of course, this is effectively how it behaves. Therefore, it's no surprise many saw it this way. But with versions, the keep button is actually a keep new version button. As mentioned before, a new version retains the tree_id, whereas a true copy does not. Since versions are on the way, we should make sure to clarify the distinction! Eben Regards, Tomeu Daniel Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Add ability to record to Speak?
On Thu, Jul 9, 2009 at 10:50 PM, Muriel de Souza Godoi murielgo...@gmail.com wrote: Hi all, I've been away from Sugar for a long time... but keep reading the mailing lists :) I will be on vacation until July 20th, but after that I can face this as a new effort to help Sugar What about a different approach? Add the speak capability to memorize... Can memorize just use the speak library and pronounce the cards? What do you think? Thats an interesting idea too! Especially if you could have the speak face on the card doing the talking. He is so engaging. I think you want the capability to not show the print as the idea might well be to recognize the sounds and match them to the written word. Thanks! Muriel 2009/7/8 Aleksey Lim alsr...@member.fsf.org On Wed, Jul 08, 2009 at 04:55:36PM -0400, Caroline Meeks wrote: Hi, We worked with 3rd going into 4th graders at the GPA in Boston today making memorize games using social studies terms. The kids drew pictures and added them to the memorize game. The kids are very interested in making the computer talk. The lab computers (this is SoaS not XO) have headsets but do not have microphones. What I'd like to do is let the kids type into Speak, record it, then use that recording in their memorize games. I'm hoping that someone will find this easy and be able to give me a new version of Speak by next Weds? :) But current Speak version can record sounds and save recorded sounds to the journal. There could be one issue with setting up record volums(since 0.84 doesnt let users control it) but it could be fixed by alsamixer -V capture command from Terminal, later SoaS should store these settings between boot sessions. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Muriel de Souza Godoi Universidade Tecnológica Federal do Paraná -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
