Re: [Sugar-devel] Feature cleanup meeting: 11.01.10 --- Summary
On Mon, Jan 11, 2010 at 18:44, Simon Schampijer si...@schampijer.de wrote: Hi, today we went through the list of Features proposed for the 0.88 release and pending Feature requests. I will summarize here the outcome: *** Accepted: Enhanced Color Selector: http://wiki.sugarlabs.org/go/Features/Enhanced_color_selector --- in review process, first patch has been reviewed already TableView: http://wiki.sugarlabs.org/go/Features/TableView_Widget The current use of the gtk.treeview is quite hacky. The new widget will improve maintenance and will support multiple selections. --- in review process http://dev.sugarlabs.org/ticket/1586 --- adds new API, if not ready before the Freeze will be added internal to the shell only for now 3G-Support: http://wiki.sugarlabs.org/go/Features/3G_Support --- requested from the field, implemented from local developers, not too invasive --- in review process already http://dev.sugarlabs.org/ticket/230 http://dev.sugarlabs.org/ticket/1586 Enhanced-Gettext: http://wiki.sugarlabs.org/go/Features/Enhanced_Gettext --- has been requested from the field several times (e.g. Sri Lanka) --- adds new API Font configuration: http://wiki.sugarlabs.org/go/Features/Font_configuration --- first part, the GConf option, has been landed --- Sayamindu is working on a daemon thet monitors gconf and X about it as soon as something changes. The advantage of using X is that it is cross-desktop and works for all X apps (e.g. GTK, QT). In terms of performance reason the daemon could only run when resources are available and otherwise a restart would be needed for changes to take affect. --- API changes --- we are looking for a developer that would code a simple Control Panel interface to increase/decrease the font size I think this could be a major feature in 0.88. Regards, Tomeu Write to Journal anytime: http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime --- the outstanding issue is a design one, we need to find consensus about the design Thumbs View in Journal: http://wiki.sugarlabs.org/go/Features/Thumbs_View_in_Journal --- it already had been accepted for 0.86 but got delayed, the code is basically done only needs to be adopted to the new TableView widget _ *** Pending Dotted activity Versions: http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions --- needs an owner --- final poll to take a decision which scheme to use Sugar Bundles: http://wiki.sugarlabs.org/go/Features/Sugar_Bundles --- Original request cam up to simplify the ASLO updater (infrastructure request) --- we agreed in the goal itself, we would like to know how important it is for a deployment to know if we better do it now or later --- request feedback from deployers on the ml Tags in Journal: http://wiki.sugarlabs.org/go/Features/Tags_in_Journal --- design feedback needed, there are mockups already, a first attempt to get this in would be great Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [POLL] Dotted Activity Versions
On Mon, Jan 11, 2010 at 19:45, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Jan 11, 2010 at 06:44:36PM +0100, Simon Schampijer wrote: *** Pending Dotted activity Versions: http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions --- needs an owner --- final poll to take a decision which scheme to use schemes are http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description +1 for 2nd one e.g. +1 Tomeu for regular bugfix release of Browse-102 branch, -0.88 and 0.88+ user will see mostly the same activity version, -0.88 will get the same v102, 0.88+ will get v102.108 version. In most cases, activity developers won't use minor part and will continue the same release line e.g. v103, v104 etc. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Automated coverage testing?
On Thu, Jan 14, 2010 at 11:47, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Thu, Jan 14, 2010 at 04:06:46PM +0530, Sayamindu Dasgupta wrote: From what I understand, you need to have the accessibility bits in Sugar enabled first (atk, etc) for dogtail/ldtp to work. IIRC it worked fine for me without changes, but it's been a long time and I only tried something very simple. It's quite conceivable that major parts of Sugar aren't testable yet, but that shouldn't prevent anyone from setting something up to test the parts that can already be tested. Hippo is a problem here because it lacks atk support. Also, we need to add more metadata to our gtk widgets so that accessibility and testing tools can expose more of it. Lots of interesting information here: http://projects.gnome.org/accessibility/ http://library.gnome.org/devel/accessibility-devel-guide/nightly/ Regards, Tomeu CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJLTvYsAAoJELpz82VMF3Da4sMH/2X/N8UrSvR4YXOuq5kW+M4L miNoz8pprMT6C+mTuIDbn8vCzEmXPtHwrAIpIcp0NTUEep7xYotQhi9BMpstUGjN xGkehA+4LUXBUtN7UGXqtYEoV2tFEQIIXiwH5RyvxltgD/WHhJC7P9h/5T/XToKy 3nUNcIiO074drmLnCeeM8Ea25dgiWwtrDAWHtVKxON9AQbX0ReDZGUP0PDN+hWAs 122AHrBnli36o9rLj3ziMYaY6KJy7xb93gl8aJHKbGQDFCNnAwdixgOtw7aENWrt YnQS+9qz1yTOgcFS7Pj8cp9cUTcnQgd3Rxoi4g6gERyBIT7uXrXE40gwZyfzbP8= =xhma -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Automated coverage testing?
On Thu, Jan 14, 2010 at 17:19, Walter Bender walter.ben...@gmail.com wrote: On Thu, Jan 14, 2010 at 11:13 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Jan 14, 2010 at 11:47, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Thu, Jan 14, 2010 at 04:06:46PM +0530, Sayamindu Dasgupta wrote: From what I understand, you need to have the accessibility bits in Sugar enabled first (atk, etc) for dogtail/ldtp to work. IIRC it worked fine for me without changes, but it's been a long time and I only tried something very simple. It's quite conceivable that major parts of Sugar aren't testable yet, but that shouldn't prevent anyone from setting something up to test the parts that can already be tested. Hippo is a problem here because it lacks atk support. Also, we need to add more metadata to our gtk widgets so that accessibility and testing tools can expose more of it. Lots of interesting information here: http://projects.gnome.org/accessibility/ http://library.gnome.org/devel/accessibility-devel-guide/nightly/ Regards, Tomeu GNOME is planning on a Accessibility Hackfest on March 22-27 2010 at the CSUN conference in San Diego. It would be great to be able to get some Sugar hackers there. Sounds very interesting, wonder if we could get someone to sponsor this? Regards, Tomeu -walter CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJLTvYsAAoJELpz82VMF3Da4sMH/2X/N8UrSvR4YXOuq5kW+M4L miNoz8pprMT6C+mTuIDbn8vCzEmXPtHwrAIpIcp0NTUEep7xYotQhi9BMpstUGjN xGkehA+4LUXBUtN7UGXqtYEoV2tFEQIIXiwH5RyvxltgD/WHhJC7P9h/5T/XToKy 3nUNcIiO074drmLnCeeM8Ea25dgiWwtrDAWHtVKxON9AQbX0ReDZGUP0PDN+hWAs 122AHrBnli36o9rLj3ziMYaY6KJy7xb93gl8aJHKbGQDFCNnAwdixgOtw7aENWrt YnQS+9qz1yTOgcFS7Pj8cp9cUTcnQgd3Rxoi4g6gERyBIT7uXrXE40gwZyfzbP8= =xhma -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] GCompris was Re: Sugar Digest 2010-01-07
On Wed, Jan 13, 2010 at 02:44, Caroline Meeks carol...@solutiongrove.com wrote: On Tue, Jan 12, 2010 at 3:15 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Jan 12, 2010 at 19:24, Caroline Meeks solutiongr...@gmail.com wrote: === In the community === 2. Bruno Coudoin announced the release of GCompris Version 9.0. Aleksey is already working on making sure that it is properly packaged for Sugar and available on http://activities.sugarlabs.org. Congrats to the GComris team! I have found GCompris activities a valuable addition to Sugar and look forward to the upgrade. GCompris also has a groups model that allows some teacher administration: http://gcompris.net/wiki/index.php/Manual#Administering_GCompris Did the upgrade touch this part of the project? Does anyone know if anyone is thinking about how to make this functionality available to teachers using Sugar? Didn't got many answers when I asked about similar functionality on the Teachermate. My guess is that Sugar is supposed to be deployable in some situations where the data sharing solutions in the Teachermate and GCompris don't work. Having the teacher functionality potentially available where there is an XS doesn't have to mean the activities won't work when there isn't one. I was just checking to see the status. My recollection of what happened is that we got into two bike shedding exercises: find a way to collect results in more situations and find better assessment models. My memory about Teachermate was there were people interested in working on Teachermate teacher system but they wanted assurances that the Teachermate activities were going to be released under a GPL or CC license and an idea of how much content there was. There were no answers on that. I'm CC'ing Seth at Innovations for Learning in case he has the information you ask. Regards, Tomeu Thanks, Caroline Regards, Tomeu Thanks, Caroline IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
On Thu, Jan 14, 2010 at 18:52, Ed McNierney e...@laptop.org wrote: Tomeu - I think everyone should understand that things have changed quite a bit since January of 2009, and interpreting year-old emails may be a little misleading. I think Chris is both right and wrong here. You need to first remember that when that email was written, there was no XO-1.5 and no funding or plan to make it. That was a huge change that happened in April. If you decide that my statement was meant to apply to the XO-1.0, then I'd argue it's still correct. If you apply it to the XO-1.5, a project that didn't exist when it was written, then it's wrong. In either case, there's a lot more to that email than just one sentence, and I'd prefer it if people read the whole message. As pertains to the XO-1.0, it is still substantially correct. As it pertains to the XO-1.5, I think it's still true in the sense it was intended. Look at the 9.1 project plan mentioned - it was a substantial set of Sugar and system features being solicited from deployments by a Product Manager (a job that still no longer exists) looking for feature enhancement requests to combine with our own ideas to design new major releases. The major aspects of our 10.1 release are the (a) movement towards a more standard Sugar-on-Fedora platform as anticipated in the referenced email, and (b) the very substantial port to an almost completely new hardware platform. The latter really is a major job but it was not at all something I was talking about last February. So given that 10.1 is a discussion about a hardware device that didn't exist when the email was written, I think it's an out-of-context question. The statement was clearly never intended to refer to a machine and project that didn't exist at the time the statement was made. However, rather than continuing to parse ancient emails, it's probably a far more helpful endeavor to answer a current question, and I don't know what that question is in this context. What is the question that the reference to that email attempted to answer? Thanks. I wasn't asking any particular question, I just thought that the reference to that email in the wiki could be easily misinterpreted as-it-was and called your attention just in case you would appreciate it. Regards, Tomeu - Ed On Jan 14, 2010, at 11:44 AM, Chris Ball wrote: Hi, What I don't know is if the contents of that message are still valid, e.g. OLPC will not undertake, on its own, another major release of the software package we currently ship with each XO.. No, not still valid. We just finished doing exactly that for 10.1. :) - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Please tag tarball releases in git repository, e.g. Sugar 0.87.2
Ping! On Sun, Jan 3, 2010 at 13:14, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Dec 30, 2009 at 14:04, Jonas Smedegaard d...@jones.dk wrote: Hi, Please do remember to tag tarball releases in Git repositories. Those tags are helpful for (some) distributors - like me :-) Oops, was a problem with the release script, git push failed because I had some non-uptodate branches and the script didn't pushed the tags. I'm attaching a patch for Simon to review. Concretely Sugar 0.87.2 released december 21st lack a tag about that. Pushed, thanks! Regards, Tomeu Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJLO0/aAAoJECx8MUbBoAEheicP/37UK0+SUQVbOHL9p1Lc7nVl p+K6T3Q3jbhKVymTlGuKIirHpPp4y0FTy/X3kJbtPPAtFHYfcg0v+M5JMGJL9NqS gWQCITI1o+4Qd7d22j8FOSwX8hrsGwa6bwFtc1bHG17LRi47ZgNXjb5A/9LuQV00 1EIsYUT4uZzEIldtBoRw1iZ4B3/kOdgv2BOHVlc7VxKd0HHSPOSyBOS41cIxIJEQ njA+e3HZERc1kKXz5VPNzCGfo4cFfa2D1MDGy1BXp3eU0Yv8vJd7mdq3KVIdne/X CpxSONQMMUIgGXIC7UkH1CPy+fXmEaAVkG5gDB7E6Rd35D638rIgFOul7inftQFl 9ZNUP8BwBfJmsHewGPrMt9yqbdeq8TuIbRBD1Whpx+4h4cXhHNeqVwK9xgyVYQTG U+pxE9h6sZOhOvNmx/XOXp/rK6xDz3yPNOcqhnFqMZjbNJUUtsC9XIr7aUgGU06P h/7nycSQFvCPk5FBrI/dhAIgn8nF2ozbLXgpB82AfXGQCfblOxskhuSgQf0YfBy3 6k9CeBIxIt0n7wcv86EKH1WXBZ7cC8IQRIqUIkmYzNZyFjPrYr23wBs1hg34w7nx ZRSuLMLw92FtUc+x7dRT++C81BlJfRYQLqFik6z1V0GW1xSE7EqMM+YUMmu+Y7TA HeaW9o9JqV9qcQIyzGwI =hRAp -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.87.3
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.87.3.tar.bz2 == News == * shell breaks if system bus cannot be accessed #1403 * sugar-emulator: kill X server on exit #1440 * move ~/.i18n parsing from sugar-emulator to sugar #1441 * can't create ad-hoc network when name is 7+ characters #1604 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Please tag tarball releases in git repository, e.g. Sugar 0.87.2
On Tue, Jan 12, 2010 at 18:35, Jonas Smedegaard d...@jones.dk wrote: On Tue, Jan 12, 2010 at 05:51:32PM +0100, Tomeu Vizoso wrote: Ping! Was that targeted me? If so, why? Sorry, this as targeted to Simon about committing the patch for sugar-tools. Regards, Tomeu Sugar 0.87.2 was packaged for Debian on january 1st and entered testing earlier today. Status for that specific package is here: http://packages.qa.debian.org/s/sugar-0.88.html Status for all team-maintained Sugar-related packages are here: http://qa.debian.org/developer.php?login=debian-olpc-de...@lists.alioth.debian.org Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJLTLL4AAoJECx8MUbBoAEhD58QAKL1LeykxMiKqYyWZw0cqoAe 5zkqyqT/QVwDZV88XDwaMCew/5+zIu//rxDDdCXG9Q8H7KSx8JCbaMTpaCLllvDz bdTt4KX9nMTBTIardakiF8xlAYouB3poCBxflBMTzLFaozuYfRpYwuuY7gHf/no2 uKMUYnTOFJggdEMuvsp894g6RXnT2qKbIDw4LgUmOG6VrXFp7icJ2N8khMyAWF8c uI/B59oXjqKARiGZULg8l5iCRUo0+3ULWCPH/hlhsKbWBcx71//+nh2eIC0ZbM/f LMsdhQoBhGU8RrL49IevZ6T+Mc8Nv1JTdRJaAkUtcQjDFzq9HEpaiwLQmo6NWoNr KWCH8AkoHhx/b3pcWXuzTxHu2lnm4n7Mxzo6iqMUSchSaMdcmfrDWwIyUOOaYW4E cg61+4UUxZSwR1WkCSsPj10x0NoD6e+pCG9dfPqPbp+2IPpwNRNltfRjUmHuYLMD S5hzFWH6YgH7a5jGmP2LPhHRwwWIwOReCoBmQ78Xaty27z+e+WfGXN6Sb5qbu8sF 4Qc77HccaX+/65MB90OVZIRNluZC6EsXs/GzSFiM/z3giG9gKDWwDBt2ERV98c82 DOvGl4Gkfkbl7C650Wc3ZbcFsi9RHUSXyrIU62BcAHMtde8uDMwltRC1YFog3EcM y8zBjUTlarobmBYju3+N =dGjo -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] GCompris was Re: Sugar Digest 2010-01-07
On Tue, Jan 12, 2010 at 19:24, Caroline Meeks solutiongr...@gmail.com wrote: === In the community === 2. Bruno Coudoin announced the release of GCompris Version 9.0. Aleksey is already working on making sure that it is properly packaged for Sugar and available on http://activities.sugarlabs.org. Congrats to the GComris team! I have found GCompris activities a valuable addition to Sugar and look forward to the upgrade. GCompris also has a groups model that allows some teacher administration: http://gcompris.net/wiki/index.php/Manual#Administering_GCompris Did the upgrade touch this part of the project? Does anyone know if anyone is thinking about how to make this functionality available to teachers using Sugar? Didn't got many answers when I asked about similar functionality on the Teachermate. My guess is that Sugar is supposed to be deployable in some situations where the data sharing solutions in the Teachermate and GCompris don't work. Regards, Tomeu Thanks, Caroline IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SOAS 2 problems
Hi David, the most practical way of making sure that your download isn't corrupted is to verify the checksum: http://techcityinc.com/2009/02/06/calculate-md5-and-sha1-on-windows/ The SHA-1 checksum of the file should be the one in this file: http://download.sugarlabs.org/soas/releases/SHA1SUM I think that LiveUSB Creator checks it for you. I'm cc'ing this email to the soas mailing list in case they can be of more help. Regards, Tomeu On Mon, Jan 11, 2010 at 06:21, David Leeming da...@leeming-consulting.com wrote: Hello, I am trying out SOAS for the first time, for a workshop related to an OLPC deployment. Unfortunately I can’t get it to run on either of two laptops on which I tested. I followed the instructions using LiveUSB Creator, with a previously downloaded copy of the SOAS-2-Bueberry iso. The flash drive was 2GB capacity, previously reformatted and I used 505MB of persistent storage. I am using Windows Vista and tested it on that and also a machine running W7. Both required the boot helper but started up OK with the start up screen with the circle of dots forming clockwise around the X. But before the circle of dots completes, it hangs and on pressing the ESC key I see the following: /sbin/dmsquash-live-root:166: grep not found dracut warning: machine in enforcing mode and cannot execute load_policy dracut warning: to disable selinux, add selinux=0 to the kernel command line dracut warning: not continuing I reproduced this behaviour with another flash drive, so I doubt that is the problem. As stated, same behaviour with two very different laptop computers (both ASUS, one an F3SC laptop, one a 1005HA netbook). Could it be an incomplete download? Using Windows Explorer (right click/properties) on the downloaded iso file it shows as 589 MB (617,611,264 bytes). Can anyone verify that is OK? However, it succeeds with the LiveUSB Creator and does start up initially. That is not so easy for me to test as in the Solomons it can be an overnight job to download 600MB, and there are often outages. David Leeming Solomon Islands ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS with Sugar 0.87.2 coming to a system near you
On Mon, Jan 11, 2010 at 13:00, Simon Schampijer si...@schampijer.de wrote: On 12/28/2009 09:14 PM, Sebastian Dziallas wrote: Hi everybody, by popular request, there's now a Sugar on a Stick snapshot with the latest Sugar development release available. Please note that this snapshot is already part of our way to Sugar on a Stick v3. It's still based on F12 for stability reasons, though (this will change in the development cycle). But it incorporates already a number of significant changes which are part of the change to the SoaS v3 builds. The build is available here: http://download.sugarlabs.org/soas/snapshots/3/soas-3-20091228.iso Please follow the Blueberry instructions to put it on your flash drive. You can even run it on your XO-1 from a flash drive (NAND installation possibilities are being evaluated) by using liveusb-creator. Afterwards, plug it into your XO-1 and type: boot u:\boot\olpc.fth However, a known issue is (on the XO-1 only) that the X session tends to crash when trying to scroll. Help with debugging this would be very welcome. Thanks and happy testing! --Sebastian P.S.: Enjoy your holidays! First: Thanks very much Sebastian for taking care of providing us with such a nice testing environment. A few comments after a short test: * Soas: - evince-djvu is not installed, djvu-based books can not be shown - the user name is set to 'Liveuser' and the option to set is not shown on first boot. There was this change in latest Sugar: http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/5245f687227e29cde9bd679b9e3ca892180a5895 We need to set the gconf option to Disabled Maybe we forgot to set a default? Regards, Tomeu * Sugar: - switching activities by using tab is broken * Activities: - Write has problems drawing the canvas - Espeak does not start: voice.py syntax error - Clock: error in method draw_simple_background - Get IA Books: option djvu always selected, can not be changed Regards, Simon PS: Yay, the hotdog is back! :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SOAS 2 problems
On Mon, Jan 11, 2010 at 17:25, Art Hunkins abhun...@uncg.edu wrote: Your byte count is the same as mine, and I've no problems. I use the Live USB Creator as well on WinXP. I second Tomeu's suggestion about checksum.. If Live USB Creator is already checking the checksum, then there's no point in doing it manually as well. David, those errors are with the boot helper? What happens if you try to boot from the usb stick itself? Jim, note that SoaS' tracker is in https://launchpad.net/soas, not in http://bugs.sugarlabs.org/ . I'm cc'ing the soas mailing list again. Regards, Tomeu Art Hunkins - Original Message - From: David Leeming To: Sugar-devel@lists.sugarlabs.org Sent: Monday, January 11, 2010 12:21 AM Subject: [Sugar-devel] SOAS 2 problems Hello, I am trying out SOAS for the first time, for a workshop related to an OLPC deployment. Unfortunately I can’t get it to run on either of two laptops on which I tested. I followed the instructions using LiveUSB Creator, with a previously downloaded copy of the SOAS-2-Bueberry iso. The flash drive was 2GB capacity, previously reformatted and I used 505MB of persistent storage. I am using Windows Vista and tested it on that and also a machine running W7. Both required the boot helper but started up OK with the start up screen with the circle of dots forming clockwise around the X. But before the circle of dots completes, it hangs and on pressing the ESC key I see the following: /sbin/dmsquash-live-root:166: grep not found dracut warning: machine in enforcing mode and cannot execute load_policy dracut warning: to disable selinux, add selinux=0 to the kernel command line dracut warning: not continuing I reproduced this behaviour with another flash drive, so I doubt that is the problem. As stated, same behaviour with two very different laptop computers (both ASUS, one an F3SC laptop, one a 1005HA netbook). Could it be an incomplete download? Using Windows Explorer (right click/properties) on the downloaded iso file it shows as 589 MB (617,611,264 bytes). Can anyone verify that is OK? However, it succeeds with the LiveUSB Creator and does start up initially. That is not so easy for me to test as in the Solomons it can be an overnight job to download 600MB, and there are often outages. David Leeming Solomon Islands ___ 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 Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Toolkit in Vala
On Mon, Jan 11, 2010 at 17:30, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, While packagin GCompris-9 for sugar, it was decided to have sugar native toolbas for GCompris in sugar environment. So, instead of coding them in plain C, new project was initiated to port sugar-toolkit to Vala[1] http://git.sugarlabs.org/projects/toolkit At some point we can completely switch from python sugar-toolkit to Vala based project. For now, it has minimal code(style.vala:) only for GCompris needs but any help of porting sugar-toolkit to Vala is appreciated. While porting, pleas add comments like Have you considered using some automatic translator from python to vala? Regards, Tomeu /** * Port from original sugar-toolkit project. * File: src/sugar/graphics/style.py * Commit: 618df4e1770d0a75709c22dc1a83942ea3d7c8aa * Status: (complete|partial) */ [1] http://live.gnome.org/Vala -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Toolkit in Vala
On Mon, Jan 11, 2010 at 17:46, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Jan 11, 2010 at 05:33:28PM +0100, Tomeu Vizoso wrote: On Mon, Jan 11, 2010 at 17:30, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, While packagin GCompris-9 for sugar, it was decided to have sugar native toolbas for GCompris in sugar environment. So, instead of coding them in plain C, new project was initiated to port sugar-toolkit to Vala[1] http://git.sugarlabs.org/projects/toolkit At some point we can completely switch from python sugar-toolkit to Vala based project. For now, it has minimal code(style.vala:) only for GCompris needs but any help of porting sugar-toolkit to Vala is appreciated. While porting, pleas add comments like Have you considered using some automatic translator from python to vala? Greate idea to use such tool. The problem here is that I can't find something :) I guess it won't be very popular workflow, python is pretty fast for GUI applications and projects that are targeted to broad lang support, were already written in C. Too bad, there's also Genie, have you considered it? I don't know which level of maturity (stability) have those languages. Regards, Tomeu Regards, Tomeu /** * Port from original sugar-toolkit project. * File: src/sugar/graphics/style.py * Commit: 618df4e1770d0a75709c22dc1a83942ea3d7c8aa * Status: (complete|partial) */ [1] http://live.gnome.org/Vala -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning -- Aleksey -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Toolkit in Vala
On Mon, Jan 11, 2010 at 18:33, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Jan 11, 2010 at 12:22:25PM -0500, Wade Brainerd wrote: On Mon, Jan 11, 2010 at 12:20 PM, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Jan 11, 2010 at 5:16 PM, Wade Brainerd wad...@gmail.com wrote: On Mon, Jan 11, 2010 at 12:09 PM, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Jan 11, 2010 at 4:55 PM, Wade Brainerd wad...@gmail.com wrote: On Mon, Jan 11, 2010 at 11:30 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, While packagin GCompris-9 for sugar, it was decided to have sugar native toolbas for GCompris in sugar environment. So, instead of coding them in plain C, new project was initiated to port sugar-toolkit to Vala[1] http://git.sugarlabs.org/projects/toolkit At some point we can completely switch from python sugar-toolkit to Vala based project. Wow!! I think even for Python based activities, having the Sugar toolkit written in C will decrease activity startup time. And for non-Python activities, it will finally be possible to use native Sugar widgets such as the toolbar. I presume the plan is to use 0install to download the Vala toolkit? Not sure how that would work. Vala generates C code which then needs to be compiled. It doesn't provide any advantage to your average end user its just another way to develop C code. Ah, I was assuming that the generated C code would then be compiled into a shared library that could be exported to Python and other languages, thus providing first class support to languages like Mono and Ruby and also providing faster-loading Python bindings than what we have now. No, it just generates the C code which is then compiled by gcc. See http://live.gnome.org/Vala for further details. Oh; I get that. I was just wondering what Aleksey planned to do with the C code once generated. It sounds like he's just added it directly the GCompris makefiles. not exactly, http://git.sugarlabs.org/projects/toolkit is just regular autotools C based project, which has additional generation stage (.vala - .c/.h), the output library will be just regular .so accessible in GCompris via pkg-config. You can easily generate introspection information for a vala lib, which could then be used by all languages with gobject-introspection bindings (hint!). Regards, Tomeu Best, Wade -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] 'Resume' vs 'Start a new' Activity
On Thu, Jan 7, 2010 at 17:19, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Simon Schampijer wrote: When they resume a previous activity, and they wanted to start a new one, I have seen learners erasing the previous content and keep on working in that activity. This is the purpose of resume-by-default. The idea arose in response to feedback from Uruguay, where students routinely filled their disk. The situation became so severe that, infamously, children in Uruguay began to memorize the shell commands required to erase the Journal by force. When at Uruguay, I was told that even after deleting the journal the disk was full and they had to reflash. I guess this is because of temp file leaks that have been fixed in later releases. Also, resume-by-default would help with user-generated content, but the biggest files on the journal will be downloads (except videos taken in Record). Regards, Tomeu Regards, Tomeu If you are working on systems with larger than 1 GB disks, or students who do not use the machines full-time, then you will of course be far less likely to encounter this problem. This is not to say that I know what the right solution is; I'm not at all sure. --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Mockup for collab.sugarlabs.org
On Fri, Jan 8, 2010 at 05:28, Wade Brainerd wad...@gmail.com wrote: On Thu, Jan 7, 2010 at 9:47 AM, Aleksey Lim alsr...@member.fsf.org wrote: All mentioned above could be(already) done in existed env. But the major idea of collab.sl.o proposal is bringing life to existed scheme by stimulating users to share their needs(due to having convenient ASLO for needs site). Hi Aleksey, We definitely need to improve our lines of communication with users (deployments, teachers, students and casual). As a programmer I appreciate a good technical solution to this problem. I think it's more a personal problem than a tech problem though. E.g. we need better relationships between developers and users, more than we need a better form to fill in. This is certainly my opinion as well. The language problem is there, but though I'm a native spanish speaker I rarely get a reply when contacting someone from a deployment. Though if most people at SLs spoke spanish, then we could work stronger in this area. Any infrastructure we set up for feedback needs to take into account that most of our users are not comfortable using english, and that's a bit hard of a problem. Regards, Tomeu And that's really a job for the project leadership, mostly by introducing people and encouraging them to follow up. Tomeu's recent visit to Laboratorio Tecnológico del Uruguay is a great example; if only we could put every Sugar developer at a deployment for a week. I joined the sur list and use Google Translate to feel at least a little bit plugged in :) Still, I occasionally send emails to deployments asking things like Are you guys using Typing Turtle? and What kinds of activities could you use? but rarely hear back. I guess it's a problem when most of the developers speak one language, and most of the users speak one of many others. I'm personally for lightweight collab.sl.o(to meet only mentioned above issues) and reusing existed development related resources like wiki/launchpad/mls for development process. What do you think about making this idea into an activity, instead of a website? We could take my Report a Problem control panel and turn it into a Feedback activity. I already have the log collector server set up on SL infrastructure - we could turn the feedback into a RSS feed for developers who could detect trends. I'm not sure about the voting stuff - we hardly get any reviews on ASLO as it is, my Typing Turtle score is down to 3 stars because of one middle school kid :) (BTW, there seems to not be much user representation in the discussion about 0.88 features, which may provide some motivation for this topic) -Wade ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Mockup for collab.sugarlabs.org
On Fri, Jan 8, 2010 at 11:30, Gerald Ardito gma...@gmail.com wrote: Wade, You said: if only we could put every Sugar developer at a deployment for a week. I am a teacher and doctoral student managing a deployment of 150 XOs/SOAS and would love to have this happen! Is your deployment in New York? Regards, Tomeu Gerald On Thu, Jan 7, 2010 at 11:28 PM, Wade Brainerd wad...@gmail.com wrote: On Thu, Jan 7, 2010 at 9:47 AM, Aleksey Lim alsr...@member.fsf.org wrote: All mentioned above could be(already) done in existed env. But the major idea of collab.sl.o proposal is bringing life to existed scheme by stimulating users to share their needs(due to having convenient ASLO for needs site). Hi Aleksey, We definitely need to improve our lines of communication with users (deployments, teachers, students and casual). As a programmer I appreciate a good technical solution to this problem. I think it's more a personal problem than a tech problem though. E.g. we need better relationships between developers and users, more than we need a better form to fill in. And that's really a job for the project leadership, mostly by introducing people and encouraging them to follow up. Tomeu's recent visit to Laboratorio Tecnológico del Uruguay is a great example; if only we could put every Sugar developer at a deployment for a week. I joined the sur list and use Google Translate to feel at least a little bit plugged in :) Still, I occasionally send emails to deployments asking things like Are you guys using Typing Turtle? and What kinds of activities could you use? but rarely hear back. I guess it's a problem when most of the developers speak one language, and most of the users speak one of many others. I'm personally for lightweight collab.sl.o(to meet only mentioned above issues) and reusing existed development related resources like wiki/launchpad/mls for development process. What do you think about making this idea into an activity, instead of a website? We could take my Report a Problem control panel and turn it into a Feedback activity. I already have the log collector server set up on SL infrastructure - we could turn the feedback into a RSS feed for developers who could detect trends. I'm not sure about the voting stuff - we hardly get any reviews on ASLO as it is, my Typing Turtle score is down to 3 stars because of one middle school kid :) (BTW, there seems to not be much user representation in the discussion about 0.88 features, which may provide some motivation for this topic) -Wade ___ 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 Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Mockup for collab.sugarlabs.org
On Fri, Jan 8, 2010 at 11:37, Walther Neuper neu...@ist.tugraz.at wrote: Hi Wade, thanks for your initiative ! We would like to adjust (contribute?) to your efforts, since we just begin to try the same in a mini-environment: (student-)developers at our university + teacher students + teachers at Austrian schools. That sounds great! Please keep us posted. If I can help in any way, we could meet either in Graz or in Prague. Regards, Tomeu Walther PS: preliminary homepage www.ist.tugraz.at/projects/isac/rp Wade Brainerd wrote: On Thu, Jan 7, 2010 at 9:47 AM, Aleksey Lim alsr...@member.fsf.org wrote: All mentioned above could be(already) done in existed env. But the major idea of collab.sl.o proposal is bringing life to existed scheme by stimulating users to share their needs(due to having convenient ASLO for needs site). Hi Aleksey, We definitely need to improve our lines of communication with users (deployments, teachers, students and casual). As a programmer I appreciate a good technical solution to this problem. I think it's more a personal problem than a tech problem though. [...] -- Walther Neuper Mailto: neu...@ist.tugraz.at Institute for Software Technology Tel: +43-(0)316/873-5728 University of Technology Fax: +43-(0)316/873-5706 Graz, Austria Home: www.ist.tugraz.at/neuper ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] suggestions for additions to platform page
On Tue, Jan 5, 2010 at 11:54, Daniel Drake d...@laptop.org wrote: vte (and Python bindings) should be added (Terminal requires this) and it should be noted explicitly that python bindings for csound are required (Pippy and other activities use these) What's the process for making such changes? or am I allowed just to use common sense for once? :) The process is having some discussion such as what we are having now. I'm ok with these changes. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
Excellent suggestion! +1 Tomeu On Tue, Jan 5, 2010 at 17:50, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Background: Step in issue, sugar is not unique here, thats the problem for other FOSS projects as well. But sugar has it's own specific nature - sugar stimulates(at least should) doing not just using, our audience could have additional layers - teachers for examples. Projects like sugar also unique because it's not only about producing final product but about improving basic things - education here. So, many people could want to participate to projects like sugar even if they are tacking part in other FOSS projects. Thus the critical thing for sugar is supporting casual participating. Participating not only by experienced developers but designers, casual doers etc. Someone could argue that it's about gaining critical mass of contributors and we didn't achieve this point yet. But what about achieving critical mass of targeted audience and even users of sugar(thanks to OLPC). For example what can do teacher somewhere in Uruguay if local needs requires some improvement in sugar, he can post en email to one of sugar related lists, ask someone on IRC but is it so friendly?(it's the same level of answers like ask google). What can do individual who needs some activity and going to pay for this activity development(during 0.86 cycle I got such request and had to bounce it since didn't have enough time). So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. This collab.sugarlabs.org shouldn't be the only place to track all sugar users needs and of course any big deployment could have its own internal/external infrastructure. But having one place where every sugar users can look by default could useful. One of benefits of such site is a chance to coordinate sugar development contributions from outsiders/casual-contributors etc. BTW looks like even for core team we don't have strong coordination, there is no regular meetings etc. With collab.sl.o we at least can see what particular contributor is doing right now. Another benefit is that collab.sl.o could be right place to sustain developers by paying for implementing particular feature or having donation button like AMO does. -- This email was subjected by [POLL] to not loss this thread and since this question could be very arguable in details, lets split it to several stages, one for poll of necessity for this feature at all and next(if first stage will be accepted) for discussing details. Please attach +/- to your reply. -- +1 -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
On Tue, Jan 5, 2010 at 17:58, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Aleksey Lim wrote: So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. -1 1. Fragmentation is bad. We should instead attempt to unify our development sites under an interface that is both friendly to novices and efficient for experts. Fragmentation prevents questions from reaching people who know the answers. 2. Without a much more detailed description of the website, it is impossible to judge whether it is worth building. I thought the poll was about having a place where to track needs, not about how that site(s) would look. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
On Tue, Jan 5, 2010 at 18:05, Walter Bender walter.ben...@gmail.com wrote: On Tue, Jan 5, 2010 at 11:50 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Background: Step in issue, sugar is not unique here, thats the problem for other FOSS projects as well. But sugar has it's own specific nature - sugar stimulates(at least should) doing not just using, our audience could have additional layers - teachers for examples. Projects like sugar also unique because it's not only about producing final product but about improving basic things - education here. So, many people could want to participate to projects like sugar even if they are tacking part in other FOSS projects. Thus the critical thing for sugar is supporting casual participating. Participating not only by experienced developers but designers, casual doers etc. Someone could argue that it's about gaining critical mass of contributors and we didn't achieve this point yet. But what about achieving critical mass of targeted audience and even users of sugar(thanks to OLPC). For example what can do teacher somewhere in Uruguay if local needs requires some improvement in sugar, he can post en email to one of sugar related lists, ask someone on IRC but is it so friendly?(it's the same level of answers like ask google). What can do individual who needs some activity and going to pay for this activity development(during 0.86 cycle I got such request and had to bounce it since didn't have enough time). So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. This collab.sugarlabs.org shouldn't be the only place to track all sugar users needs and of course any big deployment could have its own internal/external infrastructure. But having one place where every sugar users can look by default could useful. One of benefits of such site is a chance to coordinate sugar development contributions from outsiders/casual-contributors etc. BTW looks like even for core team we don't have strong coordination, there is no regular meetings etc. With collab.sl.o we at least can see what particular contributor is doing right now. Another benefit is that collab.sl.o could be right place to sustain developers by paying for implementing particular feature or having donation button like AMO does. -- This email was subjected by [POLL] to not loss this thread and since this question could be very arguable in details, lets split it to several stages, one for poll of necessity for this feature at all and next(if first stage will be accepted) for discussing details. Please attach +/- to your reply. -- +1 -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep +1 as I am very sympathetic to you intentions. However, I worry that yet-another website might not be the solution. We have several places where we are already try to gather user needs and feedback (e.g., the Sur list, IAEP list, http://wiki.sugarlabs.org/go/Submit_Bugs/Problems, http://wiki.sugarlabs.org/go/Request_New_Features, http://wiki.sugarlabs.org/go/Sugar_Labs/Resources/Professional_services, etc.). How will this site be different/effective/unifying? I personally like what Greg Smith did back at OLPC: http://wiki.laptop.org/go/Feature_requests Regards, Tomeu -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse questions for Karma
On Fri, Jan 1, 2010 at 14:13, Bryan Berry br...@olenepal.org wrote: I am trying to run the Karma lessons using Browse instead of regular Firefox. Using Browse will enable me to create sugar bundle for karma that doesn't include binaries I have tested it on os10 of 0.86 http://dev.laptop.org/~smparrish/XO-1/builds/OS10/os10.img on the XO. This build uses xulrunner-1.9.1.5. My version of Conozco a Uruguay doesn't run at all http://karma.sugarlabs.org/examples/Conozco-Uruguay I can run Conozco on my regular laptop w/ Firefox 3.5 which uses xulrunner-1.9.1. My understanding was that Browse basically is Firefox. What other components make up Browse and which ones distinguish it from regular firefox? Both Browse and Firefox are based on xulrunner. Hulahop is a Gtk+ widget that allows embedding the xulrunner engine and provides some glue for using PyXPCOM. Browse uses PyXPCOM as Firefox uses XUL and XBL. My first question is, how can I debug web applications running in Browse? Debug is a bit wide of a term. As a first shot at anticipating what you want, you could activate the javascript console and use dump() calls? Those should appear in the activity log file. https://developer.mozilla.org/en/Debugging_a_XULRunner_Application If I can't debug on the XO or w/in Sugar, I need someway to replicate nearly the exact Firefox environment on my regular laptop. You mean the exact Browse? You can install F11 on your laptop, or sugar-jhbuild, Strawberry SoaS should also be very close. Also, is there another image besides os10.img that I should try? I think I heard from Steve about a new image soon. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] Journal Reload a new attempt
On Sun, Dec 6, 2009 at 03:20, Aleksey Lim alsr...@member.fsf.org wrote: (oops, wrong subject) Hi all, This post is not about particular feature but about proposed to 0.88 features that can be composited to one set. IMHO, instead of proposing (apparently out of the blue) new features that change everything including the development and deployment models, would be better to start from a stated need and then propose solutions for those. In the particular case of the Journal, we know from the 0.86 cycle that the current list widget is not the best we could use. Users are also demanding a way to select multiple items and perform operations on them. Sorting has also been requested. Do we really need to decide on the plugins thing before we solve these simpler issues? Regards, Tomeu Some of them could be implemented in 0.88 partially, some are invasive, some not. We lost possibility to push several such features in 0.86 and we have a chance to do it once more in 0.88 release cycle. But in my mind, start to fix followed issue could be useful even in 0.88. * Reinforcing the storage metaphor in sugar (w/o loosing dairy component). Since in sugar we have only datastore(existed Journal from users POV) as a data storage(excluding external sources), we have *very* poor instruments to treat sugar object from users POV - user has to face to the whole list of objects from begging(there is not way to keep query - should look like replacement of regular directories), user even can't manually sort Journal objects. Could be fixed by: * [5] having sugar directories - bookmarks * [6] several views that could provide most useful browsing features * Having extended storage metaphor, we should save dairy component, so we can start implementing of long discussing Actions feature Could be fixed by: * [2] its only a stub, so any ideas are welcome * Make existed work flows more consistent (activities vs. objects-that-could-be-treated-as-activities, activities vs. activity bundles) Could be fixed by: * having [5], there is simple behaviour, all sugar objects are accessible from one place but from different views e.g. Hove view is just a special view that contain only activities(but could contain other objects too to speed up access) or new Actions view is a dairy view * Encourage activity developers make custom objects views, (having only one object view we either have complicated view or feature less one) Could be fixed by: * [1] These features are: [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins the name could be confusing but [1] should provide all features that are mentioned here How its invasive: * except [7], non of UI should be changed in default sugar distribution * code will be refactored to support plugins API [2] http://wiki.sugarlabs.org/go/Features/Actions this page just a stub, so who are original initiators (or have ideas) for this feature, please tweak wiki page to cover all workflows How its invasive: * the full implementation of this feature could be too invasive for UI and codebase, but we can just initiate this feature in 0.88 and collect users feedback to improve it in 0.90 [3] http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object How its invasive: * adds another confusion when user deletes activity instead of activity objects but having [5], by default, all object sets could not contain activity object except special activity views that can make activity removing more explicit for users * shouldn't be invasive in case of codding [4] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles How its invasive: * codding shouldn't be invasive Summarising above text, I think we can start implementation of these features in 0.88 release cycle(but we shouldn't implement the final workflows and make only initial steps e.g. in case of Actions). So, what community thinks about how such features could be invasive to users workflows and codebase and how it could(invasive changes) be reduced. [5] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model [6] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#View_model [7] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_Design -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] File Share Activity
Hola, creo que os puede interesar esta actividad, que facilita mucho la distribucion de contenido y actividades en el aula. http://activities.sugarlabs.org/en-US/sugar/addon/4266 Saludos, Tomeu On Wed, Dec 30, 2009 at 22:24, Justin Lewis jtl1...@rit.edu wrote: I have been building a File Share activity and I have just uploaded a copy of it to the activities page. I am looking for testing, feedback, bugs, and any other comments you may have. It can be found here: http://activities.sugarlabs.org/en-US/sugar/addon/4266 Justin Lewis http://people.rit.edu/~jtl1728 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Please tag tarball releases in git repository, e.g. Sugar 0.87.2
On Wed, Dec 30, 2009 at 14:04, Jonas Smedegaard d...@jones.dk wrote: Hi, Please do remember to tag tarball releases in Git repositories. Those tags are helpful for (some) distributors - like me :-) Oops, was a problem with the release script, git push failed because I had some non-uptodate branches and the script didn't pushed the tags. I'm attaching a patch for Simon to review. Concretely Sugar 0.87.2 released december 21st lack a tag about that. Pushed, thanks! Regards, Tomeu Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJLO0/aAAoJECx8MUbBoAEheicP/37UK0+SUQVbOHL9p1Lc7nVl p+K6T3Q3jbhKVymTlGuKIirHpPp4y0FTy/X3kJbtPPAtFHYfcg0v+M5JMGJL9NqS gWQCITI1o+4Qd7d22j8FOSwX8hrsGwa6bwFtc1bHG17LRi47ZgNXjb5A/9LuQV00 1EIsYUT4uZzEIldtBoRw1iZ4B3/kOdgv2BOHVlc7VxKd0HHSPOSyBOS41cIxIJEQ njA+e3HZERc1kKXz5VPNzCGfo4cFfa2D1MDGy1BXp3eU0Yv8vJd7mdq3KVIdne/X CpxSONQMMUIgGXIC7UkH1CPy+fXmEaAVkG5gDB7E6Rd35D638rIgFOul7inftQFl 9ZNUP8BwBfJmsHewGPrMt9yqbdeq8TuIbRBD1Whpx+4h4cXhHNeqVwK9xgyVYQTG U+pxE9h6sZOhOvNmx/XOXp/rK6xDz3yPNOcqhnFqMZjbNJUUtsC9XIr7aUgGU06P h/7nycSQFvCPk5FBrI/dhAIgn8nF2ozbLXgpB82AfXGQCfblOxskhuSgQf0YfBy3 6k9CeBIxIt0n7wcv86EKH1WXBZ7cC8IQRIqUIkmYzNZyFjPrYr23wBs1hg34w7nx ZRSuLMLw92FtUc+x7dRT++C81BlJfRYQLqFik6z1V0GW1xSE7EqMM+YUMmu+Y7TA HeaW9o9JqV9qcQIyzGwI =hRAp -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning 0001-Push-only-to-master.patch Description: Binary data ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Sugar Services
On Sun, Jan 3, 2010 at 19:12, Aleksey Lim alsr...@member.fsf.org wrote: Happy New Year to all, http://wiki.sugarlabs.org/go/Activity_Team/Services I don't think I fully understand your plan with services yet, but when you feel this is ready to receive feedback from deployments, ask me, though I haven't had always success with that... Regards, Tomeu It is the first version Sugar Services infrastructure which is ready to test or use in simple cases(see Known Issues[1]). In short terms it's about adding decentralized method to support various activity dependencies. See what Services is[2] and is not[3]. There are also guides for: * activity developers http://wiki.sugarlabs.org/go/Documentation_Team/Services/Activity_Developers_Guide * service developers http://wiki.sugarlabs.org/go/Documentation_Team/Services/Service_Developers_Guide Examples: * CartoonBuilder-9 http://activities.sugarlabs.org/en-US/sugar/addon/4037 uses Toolkit[4] service which provides new toolbar design for 0.82+ * Speak-12 http://activities.sugarlabs.org/en-US/sugar/addon/4038 uses gst-plugins-espeak[5] service which lets activity use gst plugin instead of executing espeak command on XO-1 In all examples the only change(except bundling 0sugar-launch, since saccharin is not part of Sugar Platform) is adding new string to activity.info: requires = toolkit; gst-plugins-espeak [1] http://wiki.sugarlabs.org/go/Documentation_Team/Services/Activity_Developers_Guide#Known_issue [2] http://wiki.sugarlabs.org/go/Activity_Team/Services#Workflows [3] http://wiki.sugarlabs.org/go/Activity_Team/Services#What_is_Sugar_Services_not.3F [4] http://wiki.sugarlabs.org/go/Activity_Team/Services/Toolkit [5] http://git.sugarlabs.org/projects/gst-plugins-espeak -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] g.sl.o issues for Karma and perhaps other activities
On Sat, Jan 2, 2010 at 03:50, Bryan Berry br...@olenepal.org wrote: On Sat, Jan 2, 2010 at 6:16 AM, Wade Brainerd wad...@gmail.com wrote: This sounds like the ideal conditions for Git. Just set up a server at your office using any Git related software you want, like Gitorious or even GitWeb. Developers set their projects up on your local server, and when they reach some level of stability they create public repositories on git.sugarlabs.org. I would like to set up gitorious but not sure how difficult this would be Do all your development on your local server, and every once a while push the changes over to SL. git push gitori...@git.sugarlabs.org:myproject/mainline.git If SL people want to make changes, they clone the repository on git.sugarlabs.org and push to it. We will have about 60 individual repos by April and hopefully several hundred by the end of 2010. It will be impractical and error-prone is we have to create each repo twice, once on our local server and once on the SL server. Is there a way to automate this? Guess you can cook a cron job quite easily, but I don't see any way around having only one writeable instance and the others read only, unless someone wants to take care of resolving conflicts. Regards, Tomeu git push gitori...@git.sugarlabs.org:myproject/wadebs-clone.git The SL person lets the author know by email, and the author pulls the changes to their local repository, merges them, and pushes them to your internal server. git pull gitori...@git.sugarlabs.org:myproject/wadebs-clone.git .. do merge work git push usern...@local-git-server:myproject.git Does this help at all? -Wade On Thu, Dec 31, 2009 at 10:37 PM, Bryan Berry br...@olenepal.org wrote: I want to discuss some issues for managing Karma lessons on glso. Please let it be clear that I am not criticizing the infrastructure team __at_all__. I think they are doing a great job. The issues I am encountering have to do with underlying tools and some issues specific to developers working in countries w/ crappy bandwidth, such as Nepal. Some of the main goals of the Karma Project are to get more developers in general involved in creating content for Sugar and to make OLE Nepal's content development more accessible and open to developers inside and outside Nepal. We have a full-time team of 7 sw engineers, 3 graphic designers, and 3 teachers working on content. It would be a crying shame if we can't work with the larger community. One big problem for devs here in Nepal is that international bandwidth is both lousy and expensive. Conversely, w/in Kathmandu bandwidth is relatively high-speed and cheap. I have up to 2 Mbps w/in Nepal but get around 30 kbps for a site hosted outside Nepal. The Karma repos are big and there will soon be many. The main Karma repo will be 10-15 MB and each individual lesson will be in its own repo, usually 2-4 MB. I hope to have about 60 individual karma activities under source control. That will be easily 200 MB. Transferring files of that size over slow international links will really cramp our development cycle. At the same time we need for the Karma lessons to be easily accessible internationally. A working solution will have to start with a server inside Nepal hosting the Karma content. OLE Nepal can likely provide the server space. Would it be possible for us to set up our own instance of gitorious? My impression is that everyone is waiting to move to the gitorious instance but something is holding it up. Even if g.sl.o migrates to gitorious.org how difficult would it be to set up an instance in Nepal. Or will it be too hard to set up a gitorious instance and we should just use something simple for Karma like cgit? So say we do set up an instance of gitorious here in Nepal. How could we make it easy for others outside Nepal to access the code and contribute back? If you are outside Nepal, downloading from a server in Nepal also sucks due to the bandwidth issue. Would it be feasible to set up a read-only mirror of Nepal's repositories on the Sugar infrastructure? I would like there to be a writable set of repositories on an international server but I can't imagine how the this mirror would sync w/ the Nepal server without lots of nasty conflicts. Sugaristas, please let me know what you think ___ 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 Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list
Re: [Sugar-devel] Sugar Development
On Wed, Dec 30, 2009 at 06:33, James Cameron qu...@laptop.org wrote: On Tue, Dec 29, 2009 at 07:40:01AM -0500, Walter Bender wrote: Informally, we have such a list from Peru, which is our largest Sugar deployment. They use a core set of activities and have expressed the desire to see that set (a) reach a level of increased stability; and (b) run reliably on newer versions of Sugar [...] Helping track down open tickets with any activities on this list would be of great benefit. And a polite reminder that there are now at least three places you might find tickets ... sugarlabs.org, laptop.org, and launchpad. ;-) Not really, every distributor of Sugar has their own tracker. I would suggest anyone wanting to help with this to focus on only one tracker. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] undo stack in gtk+
Interesting thread, given that Undo is important for our learning goals: http://mail.gnome.org/archives/gtk-devel-list/2009-December/msg00082.html Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: [olpc-nz] Inventing games in python
-- Forwarded message -- From: Tabitha Roder tabitha.ro...@gmail.com Date: Wed, Dec 30, 2009 at 01:11 Subject: [olpc-nz] Inventing games in python To: olpc-nz olpc...@lists.laptop.org, OLPC Devel de...@lists.laptop.org, Support Gangsters support-g...@laptop.org Useful website: http://inventwithpython.com/ It was recommended by Nat Torkington so worthy of sharing the link. It has links for downloading Python installer for multiple operating systems as well as the book as .pdf or web page. Tabitha ___ olpc-nz mailing list olpc...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-nz -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: [Testing] Quick run-through of Activities that launch with build 802
For activity authors that wish to know if their new versions still run on 8.2.x, Mikus have given some testing to several activities: -- Forwarded message -- From: Mikus Grinbergs mi...@bga.com Date: Mon, Dec 28, 2009 at 18:20 Subject: [Testing] Quick run-through of Activities that launch with build 802 To: Testing test...@lists.laptop.org My attention had been on F11 for a number of months. Had occasion to check 8.2 again - and wanted to see which Activity versions would run. My testing was done on build 802, using a G1G1 XO with swap partition. Note: I did not actually TEST these Activities - just made sure that the Activity was initialized to the point where it drew is own screen. The following list is by sub-directory name (without '.activity'): Launched and showed Activity's screen: Abalone - 80601 Ajedrez - 1 malformed bundle Analyze - 8 APRSXO - 14 Arithmetic - 1 audacity - 1 dependency on back-level library Ayuda-1 - 1 screen not fit BlockHead - 7 BlockParty - 7 Bounce - 7 Breakout - 80601 Bridge - 2 Browse - 102 BundleActivity - 2 Calculate - 30 CardSort - 4 keep error CartoonBuilder - 6 cells - 2 Chat - 48 chess_computer - 10 Clock - 5 COBBLE - 3 ColorDeducto - 4 no color (press stop twice) Colors - 15 Connect - 22 ConozcoUruguay - 8 Deducto - 4 yes/no truncated (press stop twice) Develop - 39 keep error Distance - 18 Distribute - 1 Domino - 7 keep error Doom - 1 DOSConsole - 3 DrGeoII - 148 EatBoom - 2 Ecomundo - 2 Elements - 1 keep error EPaati - 13 ePals - 3 Etoys - 99 ExecCommand - 1 falabracman - 1 FiftyTwo - 2 Finance - 3 Firefox-6 - 6 FlipSticks - 3 FoodForce2 - 4 FreeCell - 1 Frotz - 3 Geoquiz - 4 GetBooks - 5 Gmail - 5 gpodder - 2 HablarConSara - 2 HelloMesh - 3 Help - 11 Helpfr - 5 Hop-A-Round - 2 idle - 2 ImageViewer - 8 Implode - 5 inarow - 1 InfoSlicer - 6 IRC - 5 iStoa.net - 150 JigsawPuzzle - 7 JokeMachine - 10 Jukebox - 8 Jump - 1 Kaleidoscope - 12 Kandid - 2 Karma - 2 Labyrinth - 8 LearningCenter - 4 LeerPendrive - 1 License - 4 Lines - 1 ListenAndSpell - 2 Log - 16 Mail - 1 Map - 7 MapStats - 1 keep error Maze - 6 Measure - 29 keep error Memorize - 34 micropolis - 8 Model - 8 Moon - 11 NewsReader - 24 OurMusic - 1 malformed bundle Pacman - 2 Paint - 27 Panorama - 1 Physics - 3 Pippy - 35 PlayGo - 6 Pointillism - 2 Poll - 22 Pong - 1 Read - 56 ReadETexts - 17 Record - 64 RoadMap - 3 Ruler - 6 keep error SarynPaint - 1 has java dependency Scratch - 12 Screencast - 1 Scribble - 2 ShowNTell - 2 simcity - 5 difficulty closing Skype - 1 SliderPuzzle - 8 Sliderule - 7 keep error Smile - 2 Snow - 1 SocialCalcActivity - 1 sonata - 11 SpaceTag - 1 ?? - did not want to stop Speak - 11 SpillDill - 1 StackAttack - 80601 StarChart - 5 StopWatch - 4 StoryBuilder - 15 sudoku - 10 Surf - 106 keep error; dependency on WebKit and more swordread - 2 TabletAreaTest - 1 TamTamEdit - 51 TamTamJam - 52 TamTamMini - 51 TamTamSynthLab - 52 tangram - 10 Terminal - 30 Theorie - 8 TurtleArt - 81 (needed keyboard input to show first screen) TuxPaint - 2 TypingTurtle - 26 ucblogo - 4 VideoChat - 9 ViewSlides - 10 VisualMatch - 13 keep error WatchMe - 2 Wesnoth - 1452 WikipediaEN - 4 Wine - 19 WirelessGraph - 7 Words - 4 Write - 60 X - 1 x2o - 9 XaoS - 2 xoEditor - 2 XOlympics - 1 Did not launch properly: -- asteroids - 1 -- childsplay - 1 -- classic - 6 -- iabv - 1 -- Kuku - 1 -- MaMaMediaMenu - 3 -- Memosono - 10 -- MikMik - 1 -- Mimic - 1 ended instead of starting -- MindMap - 1 -- MotionCapture - 3 -- OurStories - 1 -- pydance - 2 -- Quiz - 3 -- watch-listen - 14 -- Xmms - 1 ___ Testing mailing list test...@lists.laptop.org http://lists.laptop.org/listinfo/testing -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Development
On Sat, Dec 26, 2009 at 22:50, Mark Symmonds msymmo...@codegladiator.com wrote: Hello! I am a freelance developer and LAMP architect with over twelve years experience. I would like to get involved in the OLPC development project where my skills may be of best use. Please let me know if there is anything I can help with. Wade, do we have a list of orphan activities that people could adopt? If so, I could ask deployments which are the most important from their points of view. Thanks, Tomeu Here are a few of my skill sets which may be beneficial in the Sugar and Sugar Activity development effort: Languages: Python, Ruby, C++ / C, Java, PHP, Perl Platforms: Linux (any dist. but primarily Fedora and Ubuntu), Free BSD, Windows Best regards, Mark Symmonds ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Accessibility - control panel
On Mon, Dec 28, 2009 at 20:09, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Dec 28, 2009 at 7:02 PM, Esteban Arias ear...@plan.ceibal.edu.uy wrote: In Uruguay, we have section of control panel: Accessibility. This item configurate keyboard accessibility options: mouse keys, bounce keys and sticky keys. We develop this on sugar 0.82 and now we begin to update this source code to 0.88. Given that it is likely that you will deploy 0.84 (before 0.88), it might make sense to target both 0.88 and 0.84 :-) From what I have seen, most of this functionality should translate very easily from 0.82 to 0.88 and in-between. IMHO, this is an awesome feature, Ceibal has several other accessibility features that I think Sugar must get. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Weekly Fedora Sugar Meetings
On Mon, Dec 28, 2009 at 22:06, Sebastian Dziallas sebast...@when.com wrote: Hi all, you've probably heard the rumor, that SoaS v3 will only ship Fedora packages. Now let me tell you this: It's true. What this means is that we can use a lot of help with packaging all kinds of crazy-awesome activities and other stuff for Fedora - which will get a Sugar environment with even more and better apps on its turn. So. Let's get this party started. I'm suggesting weekly meetings starting this Thursday, at 1500 UTC, 1000 EST [1]. Who else is in for this? Drop a note here! Great idea, will try to attend regularly. Regards, Tomeu For those who're interested in getting started with contributing to Sugar, for example by packaging activities, there will be a Fedora Classroom session on January 6 (1500 UTC) in IRC Gobby [2]. --Sebastian [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=12day=31year=2009hour=15min=0sec=0p1=0 [2] https://fedoraproject.org/wiki/Classroom ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] packaging accessibility tools
Hi, Uruguay is working on adding some accessibility features to Sugar and they are using some stuff that, though old, is not properly packaged in any distro I know of: http://slappy.cs.uiuc.edu/fall98/Linux/download.html Do we have any volunteers to tackle packaging in their distro of choice? This seems like a task with specially high karma points. Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Debian-olpc-devel] packaging accessibility tools
On Tue, Dec 29, 2009 at 19:37, Sascha Silbe sascha-ml-ui-sugar-debian-olpc-de...@silbe.org wrote: On Tue, Dec 29, 2009 at 06:49:31PM +0100, Tomeu Vizoso wrote: http://slappy.cs.uiuc.edu/fall98/Linux/download.html xkbset is an alternative CLI (for the AccessX interface) and already packaged at least for Debian. Have they considered using that one instead? I've given the package you mentioned above a quick look and it's Makefile looks horrible from a distro maintainers POV. Besides it doesn't even compile anymore, i.e. needs to get patched first. Hi Esteban, have you considered using xkbset instead? Thanks, Tomeu CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJLOkxjAAoJELpz82VMF3DaRlIH/jiqA9qKkOeMwhGLIdu6nIiW EDr7r0XwPqxs8Vt5UERh8ylPareFMQWwh+d+6doWl9lH4KgUiOHko0yQgzFJKAgK 1BT9/99PGksvg7aJm2nBjBARoOCg96ZFTVgXx1kPjU3+HUHUULa0amrVRVoHR8kK Eq7JsQOWSiGu6O8crtCFETbsSkgL/8fF7J97gjhN4a5TndPI4aiOA1QM0ZSTwUse tL27Ib7w72LxraskmW1pTjeAp9lvWffMRwHTwFNmZOWngmeSZPzzkrGyruwOLVow KkZuYm46Q/V8GkoL2NV2UMJu77BSSFeFE0UcxxQ6Ne29iOSdv8Br/SXS0thvN4s= =aBSD -END PGP SIGNATURE- -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ticket 8104
On Wed, Dec 23, 2009 at 17:33, Cecilia Abalde caba...@plan.ceibal.edu.uy wrote: Hi, I have a question about the patch in ticket 8104. to which version of networkmanager was done? Hi Cecilia, I'm forwarding our email to the devel mailing list at OLPC because NetworkManager is a component that belongs to the distro, not to Sugar. In case of doubt, you are of course welcome to ask here again. Regards, Tomeu thank you regards Cecilia ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] Ad Design for StackOverflow
On Mon, Dec 21, 2009 at 15:56, Sean DALY sdaly...@gmail.com wrote: thanks all for these suggestions I think we can include both a call for motivation (kids education) and competence (python) I like the idea of Activities as an on-ramp - we certainly want to grow the ASLO ecosystem my instinct would be to start with education, but may be better to define target as Python devs? Maybe something like this: SL logo Python Developers! Develop Activities for the Sugar Learning Platform Help children learn with your skills - over 1,000,000 served join.sugarlabs.org In my experience, most people only consider helping when they realize we are all volunteers and we are filling an important hole that nobody wants to fill. How could we communicate that succinctly? Regards, Tomeu feedback? Sean On Mon, Dec 21, 2009 at 1:14 AM, John Tierney jtis4...@hotmail.com wrote: From: jtis4...@hotmail.com To: jtis4...@hotmail.com Subject: RE: [Marketing] Ad Design for StackOverflow Date: Sun, 20 Dec 2009 19:11:08 -0500 Hello All, Something like Got Python? Change the world!? Not sure how much room we have. Also, developers are a quite heterogeneous bunch when it comes to motivation, can we target a defined profile? Maybe something like: Get Rockin With Python Join Sugar Labs Developing Communities!! Help Kids Learn How to Learn!! Change The World One Child at a Time!! Best- John Tierney Date: Sun, 20 Dec 2009 19:31:46 + From: to...@sugarlabs.org To: CC: market...@lists.sugarlabs.org; sugar-devel@lists.sugarlabs.org Subject: Re: [Marketing] Ad Design for StackOverflow On Sun, Dec 20, 2009 at 17:54, Sean DALY sdaly...@gmail.com wrote: Many thanks Luke, a good catch as developers are difficult to reach in fact I've been thinking of placing such an ad with the Ad Bard network after our December free run for Blueberry is done - they cycle ads on dev-oriented sites Before we ask the designers to work on this, we need to decide what to write Should we seek Activity, or platform devs? Maybe first activities? Makes an easier start. Python or gtk+ experience should be enough. Tomeu, what do you think a developer would react to? Something like Got Python? Change the world!? Not sure how much room we have. Also, developers are a quite heterogeneous bunch when it comes to motivation, can we target a defined profile? e.g.: sugar labs logo Nonprofit volunteer org seeks talented developers interested in improving the lives of Sugar's second million children. Join us! URL join.sugarlabs.org Sounds pretty good, a reference to concrete technologies as python and gtk are may help, because developers tend to group around the technologies they use and like. Regards, Tomeu thanks Sean On Sat, Dec 19, 2009 at 8:44 PM, Luke Faraone l...@faraone.cc wrote: Hi, StackOverflow, a popular programmer Q/A site, is soliciting adverts from FOSS projects looking for developers. Does anybody have some spare time to whip up a 220px by 220px image? -- Luke Faraone http://luke.faraone.cc ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.87.2
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.87.2.tar.bz2 == News == * Name input screen should be deactivable #1497 * Create temporary files for DS in ~/.sugar #1452 * can't connect to WEP shared key networks #1602 * intro screen doesn't unfreeze dcon #1601 * font configuration through gconf #1584 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] multiple selection in the journal
Hi, often have heard from the field about the need to select multiple entries and delete them. Should we add a checkbox to every entry in the list, or allow the user to select with shift-click and ctrl-click? Or anything else? Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] multiple selection in the journal
On Sun, Dec 20, 2009 at 10:39, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, often have heard from the field about the need to select multiple entries and delete them. Should we add a checkbox to every entry in the list, or allow the user to select with shift-click and ctrl-click? Or anything else? This has been already discussed here, more comments welcome: http://lists.sugarlabs.org/archive/sugar-devel/2009-November/020630.html Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Re: #1493 UNSP: Keep preferable activities
What do people think about this? Thanks, Tomeu On Tue, Oct 13, 2009 at 09:46, Sugar Labs Bugs bugtracker-nore...@sugarlabs.org wrote: #1493: Keep preferable activities --+- Reporter: alsroot | Owner: tomeu Type: enhancement | Status: new Priority: Unspecified by Maintainer | Milestone: 0.88 Component: sugar | Version: 0.86.x Severity: Unspecified | Keywords: r? Distribution: Unspecified | Status_field: Unconfirmed --+- How it could be: for activity_id less Journal objects, sugar could store chosen Resume with activity and use it for later fast click activation -- Ticket URL: http://bugs.sugarlabs.org/ticket/1493 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] what looks like an activity developer?
Looks like this or can we find something more appropriate? http://activities.sugarlabs.org/img/amo2009/developers/hub-addon-fox.png Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] Ad Design for StackOverflow
On Sun, Dec 20, 2009 at 17:54, Sean DALY sdaly...@gmail.com wrote: Many thanks Luke, a good catch as developers are difficult to reach in fact I've been thinking of placing such an ad with the Ad Bard network after our December free run for Blueberry is done - they cycle ads on dev-oriented sites Before we ask the designers to work on this, we need to decide what to write Should we seek Activity, or platform devs? Maybe first activities? Makes an easier start. Python or gtk+ experience should be enough. Tomeu, what do you think a developer would react to? Something like Got Python? Change the world!? Not sure how much room we have. Also, developers are a quite heterogeneous bunch when it comes to motivation, can we target a defined profile? e.g.: sugar labs logo Nonprofit volunteer org seeks talented developers interested in improving the lives of Sugar's second million children. Join us! URL join.sugarlabs.org Sounds pretty good, a reference to concrete technologies as python and gtk are may help, because developers tend to group around the technologies they use and like. Regards, Tomeu thanks Sean On Sat, Dec 19, 2009 at 8:44 PM, Luke Faraone l...@faraone.cc wrote: Hi, StackOverflow, a popular programmer Q/A site, is soliciting adverts from FOSS projects looking for developers. Does anybody have some spare time to whip up a 220px by 220px image? -- Luke Faraone http://luke.faraone.cc ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] Ad Design for StackOverflow
On Sun, Dec 20, 2009 at 20:37, Gary C Martin g...@garycmartin.com wrote: Hi Tomeu, On 20 Dec 2009, at 19:31, Tomeu Vizoso wrote: On Sun, Dec 20, 2009 at 17:54, Sean DALY sdaly...@gmail.com wrote: Many thanks Luke, a good catch as developers are difficult to reach in fact I've been thinking of placing such an ad with the Ad Bard network after our December free run for Blueberry is done - they cycle ads on dev-oriented sites Before we ask the designers to work on this, we need to decide what to write Should we seek Activity, or platform devs? Maybe first activities? Makes an easier start. Python or gtk+ experience should be enough. Tomeu, what do you think a developer would react to? Something like Got Python? Change the world!? Not sure how much room we have. Also, developers are a quite heterogeneous bunch when it comes to motivation, can we target a defined profile? e.g.: sugar labs logo Nonprofit volunteer org seeks talented developers interested in improving the lives of Sugar's second million children. Join us! URL join.sugarlabs.org Sounds pretty good, a reference to concrete technologies as python and gtk are may help, because developers tend to group around the technologies they use and like. Just a FWIW: gtk was a pain word and kept me away from tinkering for some time, Hey Python, fab; oh hell GTK+, not another random GUI toolkit to learn. But then again, I don't really consider myself an OSS developer so am likely an outlier. Good to know, I'm not sure if OSS people hang around in StackOverflow. Regards, Tomeu Regards, --Gary Regards, Tomeu thanks Sean On Sat, Dec 19, 2009 at 8:44 PM, Luke Faraone l...@faraone.cc wrote: Hi, StackOverflow, a popular programmer Q/A site, is soliciting adverts from FOSS projects looking for developers. Does anybody have some spare time to whip up a 220px by 220px image? -- Luke Faraone http://luke.faraone.cc ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: Turtleart and Arduino
Hola, creo que oi a alguien en esta lista comentar algo sobre arduino y olpc? Saludos, Tomeu -- Forwarded message -- From: Sayamindu Dasgupta sayami...@gmail.com Date: Sat, Dec 19, 2009 at 13:00 Subject: [Sugar-devel] Turtleart and Arduino To: Sugar devel sugar-devel@lists.sugarlabs.org Hello everyone, Over the past few weekends, I have been working on adding Arduino[1] support to TurtleArt, and you can get the latest code from http://git.sugarlabs.org/projects/turtleart/repos/arduino-support If you have an Arduino board lying around, it would be great if you could test out the code, and let me know if something refuses to work. Here's a screenshot: http://people.sugarlabs.org/sayamindu/ta_arduino.png Instructions on how to set up your board, etc are at http://git.sugarlabs.org/projects/turtleart/repos/arduino-support/blobs/master/README.arduino Thanks, Sayamindu [1] http://www.arduino.cc/ -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN][FEATURE] 3G modem support
On Fri, Dec 11, 2009 at 19:36, mabe...@paraguayeduca.org wrote: It has been discussed before and i have been working on it with Daniel Castelo from Uruguay. This is the link of the formal proposal, I will be updating it soon. http://wiki.sugarlabs.org/go/Features/3G_Support I support this feature, has a clear value for our users and the proposal is solid. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Journal Backup Restore
On Fri, Dec 18, 2009 at 14:38, crodas cro...@paraguayeduca.org wrote: Hello Everybody, Last year, Daniel Drake, while he was in Paraguay, he wrote a set of scripts to perform backups from SugarJournal to Schoolserver and a restore script. Everybody can see it: + http://trac.paraguayeduca.org/browser/scripts/os-modifications (diario-*) + http://trac.paraguayeduca.org/browser/scripts/os-modifications/olpc-session-restore-journal.patch We have tested creating a backup on XO-1, OS8.2 and restoring the backup in the same machine after an OS upgrade (to OS10), and worked perfectly fine. That's very good for an automatic OS upgrade. So, we have questions to the folk: 1. Is there any similar to this and standar on Sugar? 2. If no, Wouldn't be great if we add those scripts to Sugar? 3. In any case, I think will be great if we add a new section on the Control Panel, to manually force the backup and restore. Any thoughts? Right now backup support lives outside sugar: http://dev.laptop.org/git/users/martin/ds-backup.git/ But I agree with integrating it into sugar or datastore. Regards, Tomeu Thanks, -- crodas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Technique to extract all records from xapian DB?
On Wed, Dec 16, 2009 at 17:48, Martin Langhoff martin.langh...@gmail.com wrote: On Fri, Dec 11, 2009 at 2:35 PM, Tomeu Vizoso to...@sugarlabs.org wrote: I think it's worth trying, but not sure if worth merging and deploying. 0.82 didn't used directly the python xapian bindings, but some wrapper on top of it that tried to make easier the mapping between keys in the B-tree and metadata values. Yeah. It's a very complex beast that, after following the callstack hither and yon, only makes a v simple mapping. I've written a 20 line mini-reader class using xapian directly. Instead of following the DS code, I used the CLI tools that xapian includes, and it is a trivial thing. Needs a bit more time but it'll work. Sounds good, if you need later to move to python, we can do something easily if we know the prefixes for each field. The mapping mentioned before is persisted in index/config inside the DS dir. Ah, it's not static? The number-field mapping It seems stable to me testing it. So the right way is to read that 'config', how do you parse it? I think it should be stable for the fields we care about, which is a fixed set: http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/blobs/sucrose-0.82/src/olpc/datastore/model.py#line379 Regards, Tomeu Good that I asked. 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 Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Technique to extract all records from xapian DB?
On Wed, Dec 16, 2009 at 20:21, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Dec 16, 2009 at 9:46 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Dec 16, 2009 at 17:48, Martin Langhoff martin.langh...@gmail.com wrote: On Fri, Dec 11, 2009 at 2:35 PM, Tomeu Vizoso to...@sugarlabs.org wrote: Yeah. It's a very complex beast that, after following the callstack hither and yon, only makes a v simple mapping. I've written a 20 line mini-reader class using xapian directly. Instead of following the DS code, I used the CLI tools that xapian includes, and it is a trivial thing. Needs a bit more time but it'll work. Sounds good, if you need later to move to python, we can do something easily if we know the prefixes for each field. The code is all python using the xapian bindings. I used the CLI tools to figure out the data layout... because I hadn't spotted the mapping array you've just given me :-) I think it should be stable for the fields we care about, which is a fixed set: http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/blobs/sucrose-0.82/src/olpc/datastore/model.py#line379 Will use that and stop guessing. They still have odd prefixes which I have to strip out, some do, some don't... the whole thing is rather strange. I don't know if I want to know the hysterical raisins behind it... In case you change your mind... ;) http://xapian.org/docs/quartzdesign.html Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Future of Zero Sugar
On Tue, Dec 15, 2009 at 04:07, Aleksey Lim alsr...@member.fsf.org wrote: On Tue, Dec 15, 2009 at 10:16:02AM +0545, Bryan Berry wrote: I strongly agree w/ tomeu on this. Making Sugar easier to contribute to isn't anywhere near the top of the list of requested features by our kids and teachers in Nepal. The far and away most requested feature by teachers in Nepal is a mechanism for kids to turn in homework. I am not talking about invasive testing here. The typical Nepali teacher just wants to know which students out of 50-70 kids are failing to understand basic concepts. I absolutely agree with such points, but: * as a 3rd party developer, I don't see such teachers requests listed somewhere on wiki, that let me see what can I do and peek most interesting/suitable-for-my-skils/etc task I'm painfully aware of this situation and have been spending my energies on this problem for already a good while. Our colleagues at Uruguay and Paraguay are already working on upstreaming their developments, but are also going to work with us in identifying the most pressing needs in deployments. Have already some ideas about what to work on, how do you think we should track them? * I'm feeling huge discomfort as a developer when I need to package binary blobs to my .xo, w/o instrument which let me unify installing/upgrading process of such non-SP/specific-to-my-activity dependencies I agree this is a problem, but also think that many activities shipping binaries don't actually need them. Bindings for libraries can be written in ctypes, without need to use a .so. * I'm feeling less(but still big) discomfort as a developer when I don't have standard method to share my core related changes, for-testing-purposes/to-show-what-I-have-in-mind, well please, attach my cloned repos, install them still works but not so attractive for users What about generating a SoaS (or Trisquel, etc) image with such changes? This is something that can be done today without so much trouble. * implementing Zero Sugar initiative, in my mind, is providing fishing-rod for developers/doers instead of feeding users thus has prime priority I don't see things so black and white. I have been working on this same problem for a while now (view source key, extensions, etc) and our users are taking advantage of at least the extensions facility. We are going to see patches very soon for keybindings, device icons and control panel sections. And that code can be already deployed without waiting for upstreaming because of the extensions mechanism. So _today_ we have empowered users that are deploying shell extensions without disrupting the rest of the shell, and simultaneously are working with the community and sharing the fruit of their work. The technical part has been in place since a year ago, but the trigger for this to happen has been actually social interaction. There's no point in making our platform super-hackable if we don't work as well in the non-technical part of the problem. Regards, Tomeu On Tue, Dec 15, 2009 at 12:04 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Aleksey Lim wrote: So, I have strong intension to switching development focus from core team, which develops sucrose - glucose(core) and fructose(some core activities) to wide range of developers/doers thus some kind of decentralization of development process. I agree. I think this has been a central part of the Sugar design philosophy from the beginning. I think your message is very much on the right track. While I think this is in the spirit of my vision for Sugar, my experience with how Sugar is being used and deployed _today_ makes it quite uninteresting and too invasive to consider for the near future. The current barriers for people to contribute to Sugar development and share their work are mostly cultural. We can make the technology a thousand times easier to modify, but if people still think that they can be only users, we won't gain anything. If we really want more people to realize their power and modify sugar and share their work, we need to, in order: - show how the community can address some of their needs, as perceived by them, - show how they can better address the rest of their needs by working within the community. The rest is just icing on the top, IMHO. Regards, Tomeu [snip] * I hope to see many shell forks with implemented features like new sugar themes(wallpapers support, new icons etc.), Actions view implementations from non-core development/doers. The benefit they will have after 0install integration is more useful method to share these forks - just a regular entity on Activity Library that brings new shell to user environment I don't think this part will work as a regular entity on Activity Library
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
On Mon, Dec 14, 2009 at 17:40, Wade Brainerd wad...@gmail.com wrote: +1 overall. The one thing that jumps out to me here is the idea that I could download frame components from ASLO, like a Clock or a Calendar. That sounds fantastic. Yes, but what about security? Right now the shell process only executes code in /usr, executing activities in a separate process. A possible approach would be to run extensions out-of-process and have D-Bus APIs, but the memory usage would be pretty high... I also like that activities such as Chat could install frame components, and have a proper notification system. XOIrc emits a notification when a direct message is received, maybe Chat needs the same? It has been already mentioned that the notification alert doesn't call the attention enough. http://www.galago-project.org/specs/notification/0.9/index.html A great addition to this feature would be to actually implement the freedesktop.org panel protocol, which would help Sugar run native software like pidgin or claws-mail or skype (or nm-panel!). Looks like GNOME 3 is going to drop those? There's the impression from desktop developers that the application developers abused that mechanism. Regards, Tomeu Regarding extensibility, we would have to clearly define the roles of the different sides of the screen. IE the top is for task and view switching, the bottom is for information and devices, the left is for MIME objects, the right is for collaboration. Rather than adding a panel to top/left/right/bottom, a panel should be added by role. I agree that all four sides should be independently stickable. Also would be nice if they could come out separately when the screen edge is hovered. -Wade On Mon, Dec 14, 2009 at 1:53 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Dec 14, 2009 at 01:34:38PM -0500, Eben Eliason wrote: On Sun, Dec 13, 2009 at 12:42 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, At the end Journal Plugins mutated to Frame Panles feature. All UI visible changes I wanted to implement in plugins could be done via Frame Panle components(the rest of code are shell agnostic). Frame Panles feature has the same major idea, social context - giving non core developers more freedom in case of releasing/supporting theirs code, e.g. adding GSM modem support could be implemented not in core(thus stuck to sugar version, when previous sugar version users can't grab last changes of GSM modem component) but as a standalone activity(and deployed as a regular activity). Is this an extension of the device concept already present? The idea there was to allow anyone to create devices (in the bottom edge of the frame) that added extended features (such as text-to-speech, additional hardware support, dictionaries, etc.). Having a way to separate these from the core of Sugar, and even add or remove them at will, would be nice. it was more common proposal, ala GNOME panels == Summary == Treat frame as a containers(upper, left, right and bottom) for predefined or custom components i.e. having GNOME panels analog in sugar. I'm a bit confused by this. The panels, clockwise from top, are for activities, people, devices, and objects (clipboard). Only the bottom edge is currently thought of as a place for extension. Are you proposing that all of these would be extensible? yup, e.g. could move any predefined components to panel he wants.. i.e. like GNOME panle components == Detailed Description == The major reason is to let activities like FileShare or Chat special UI representation in shell's interface. It could be also useful if user wants fast access to some activities like Journal replacements. I would raise some caution here. The Frame was specifically designed as a place for active elements to live, and is specifically not a launcher. As such, any running activities, current friends, available devices, etc. appear there. Your description of fast access makes it sound more like a launcher and less like a place of status. my intention was to have panel components ala GNOME panel launchers(or even menus) Any of four panels could be stuck i.e. let user see its components all time. This is an interesting idea. yup, I'm also strongly for such feature, despite of accepting panels feature We played with similar concepts early on, but decided at the time that the Frame as more comprehensible as a single unit that could be shown and hidden at will. If we break that paradigm, how do we handle the overlap that a persistent frame edge would cause? Does the activity window move/shrink in these instances? yup, activity windows should be shrunk e.g. like application in GNOME have less free space for maximization after adding new panel. === Predefined components === * rings switch * activities list These are views within the Home zoom level. What's your proposal for making these Frame components?
Re: [Sugar-devel] [IAEP] Future of Zero Sugar
On Tue, Dec 15, 2009 at 12:19, Bert Freudenberg b...@freudenbergs.de wrote: On 15.12.2009, at 15:09, Daniel Drake wrote: I believe there are still various well-known 0.86 regressions (over 0.84). For example, Record not working. These regressions are going to be a huge headache to anyone who tries to upgrade, perhaps you could squash a few of those. Speaking of upgrade headaches, the most significant UI change in 0.84 is resume-by-default, which combined with the still not implemented versioning is possibly unhealthy in deployments. I can see many Journal entries overwritten for good. Has there been any experience with kids used to the 0.82 way who switched to a later Sugar version? And if needed, would it be easy for deployments to revert to not resuming by default? Good point, reverting would be easy and also adding a setting to switch it on or off. I can work on it if someone takes the task of verifying the need. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Tue, Dec 8, 2009 at 07:05, Simon Schampijer si...@schampijer.de wrote: On 12/07/2009 01:09 PM, Aleksey Lim wrote: On Mon, Dec 07, 2009 at 10:57:01AM +0100, Simon Schampijer wrote: On 12/07/2009 05:58 AM, Aleksey Lim wrote: On Sun, Dec 06, 2009 at 11:56:09PM +, Gary C Martin wrote: On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/11/27 Aleksey Limalsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters. The core idea of plugins is exactly to avoid situation when we have to release fat UI change set, plugins let us decentralize existed scheme when entirely sugar design(not only UI) depends on what core team thinks. We just provide usable toolset developers cold use to implement what they think. [1] proposes UI changes in [2] but plugins API could be implemented w/o any UI changes at all - user will see the same Journal(but it will be Journal plugin). The idea is let developers make plugin out of sucrose release cycle, yeah developers could do it in pure activities(but see [3]) and even out of sugar at all, but imho it will be useful(in all cases, not only technical) to initiate/support/organize such process from core. [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description Generally the idea of plugins is interesting - it always adds extensibility and make parts exchangeable. In the Journal case it is the support for different pluggable views. Looking just at the idea: great! Let's take a concrete example of a scenario with different views that is floating around: the action/object view. While there have been some pros for the change to have these two views, the implementation could be done using plugins or not. From a technical point of view: while having to change code it might be a good moment to add a plugin structure. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. I prefer to have a plugins over activities - here I agree. Do you have a layout of the plugins structure already? How much code/how invasive is it? I agree with Tomeu in the question: has this Feature of pluggable views been asked by the community?. well, this feature is not final users targeted, it's just about making development process more flexible. Ok, then we should make this more clear in the proposal
Re: [Sugar-devel] [FEATURE] TableView Widget request for inclusion to 0.88
On Sun, Dec 6, 2009 at 14:53, Aleksey Lim alsr...@member.fsf.org wrote: On Sun, Dec 06, 2009 at 02:37:07PM +0100, Simon Schampijer wrote: On 11/28/2009 05:00 AM, Aleksey Lim wrote: Hi all, Hi Aleksey, thanks for proposing this feature! http://wiki.sugarlabs.org/go/Features/TableView_Widget GTK widget to replace gtk.TreeView in Journal. Benefit to Sugar Standard gtk components are not designed to be lazy. Third party widgets, I managed to find, uses scheme with renders(like gtk components), introduced component uses widgets instead(could have performance penalties, I guess, in common case but we don't have many rows in Journal view, so should be ok for us). Can you elaborate on this? Instead of using the cell renderers to draw the data in the tree model we would pack widgets? we should just implement Cell class(regular wigdet) and it will be used for all(visible) cells, see example http://wiki.sugarlabs.org/go/Features/TableView_Widget#Simple_example_for_SmootTable_widget The API looks very good to me, just one thing: what means 3, 3 here? table = SmoothTable(Cell, 3, 3) Benefits we have for such scheme: Can you describe the benefit for a user? Faster scrolling? I meant here only developers, for users it could have only disadvantages :) if we have many visible cells at the same time, but in our case it should be ok, I tested thumbs view on XO-1 and didn't see lags I don't think the overhead of using widgets instead of renderers will be noticeable given that we render svg icons there. * coding cells is more useful by using widgets then renders, we can reuse our existed custom widgets instead of coding sugarized cell renders * in some cases its hard to sugarize cells theme(we still have ugly progress bar for Journal entries), with new widget, we use just gtk.ProgressBar Don't we use the gtk.ProgressBar already? not for TreeView, it uses progress render Or do you mean it would just look better? Our cells will look like other widgets(since cells are the same widgets) and we won't have to sugarize renders' theme(e.g. in exsited code, we have not fully sugarized pregress renders) There is an ongoing discussion in gnome community about replacing GtkTreeView, not sure if new widget is ready to use for 0.88 and since Journal's view widget is pretty simple we can use our own simple implementation(360 lines of code). Do you have pointers to the GNOME discussion? I found that snippet from someone having the same problem: http://www.mail-archive.com/gtk-app-devel-l...@gnome.org/msg12127.html Better to ask tomeu, I heard about GNOME discussion from him I guess better for us will be switching to GNOME implementation when it's ready(for now we can use as simple as possible lazy view implementation and imho proposed widgets meet that) For example this: http://pvanhoof.be/blog/index.php/2009/08/24/as-it-should-be The GNOME Activity Journal people are also looking for something lik this but I don't know of any public discussion. Regards, Tomeu Do you have written some code already? The model less widget is fully implemented, in case of model, current code has TableView class which uses gtk.TreeModel. Exact model scheme will depend on what we will use in Journal -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Sharing work between XOs/SOAS devices
On Tue, Dec 15, 2009 at 15:36, Walter Bender walter.ben...@gmail.com wrote: Sugar 0.86 has sharing built into the Journal. But that doesn't help you (yet) on your XO machines :( Paraguay is coming to the rescue :) http://lists.laptop.org/pipermail/devel/2009-December/026947.html Regards, Tomeu -walter On Tue, Dec 15, 2009 at 12:30 PM, Gerald Ardito gerald.ard...@gmail.com wrote: Hello all. As our 5th graders are doing more and more work with their XOs, their being able to turn in and share their work products (as opposed to collaborating with others) is becoming more and more important. My temporary solution is having them upload their work (along with reflections, if desired) to Moodle, which I can do because we have an XS implementation. However, this means that if a student has created a Memorize vocabulary game that s/he want to share s/he has to: 1. Create the game. 2. Save it to the Journal 3. Go to Browse 4. Navigate to Moodle 5. Find the right course/right assignment within the course 6. Upload game. S/he pretty much has to do the same thing to download and then play other games. This is certainly workable, but dramatically slows down the momentum of creating games and wanting others to play them. So, I am asking to create/offering to help create an Activity that allows users to share work products easily. I know that Bert was working on something called Distribute, which may be a starting place. It seems to share Journal objects, which seems right. I am happy to work with developers on this. I could create requirements, if need be. Just say the word. I look forward to what comes next. Thanks and best, Gerald -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] TableView Widget request for inclusion to 0.88
On Tue, Dec 15, 2009 at 16:33, Aleksey Lim alsr...@member.fsf.org wrote: On Tue, Dec 15, 2009 at 03:28:23PM -0200, Tomeu Vizoso wrote: On Sun, Dec 6, 2009 at 14:53, Aleksey Lim alsr...@member.fsf.org wrote: On Sun, Dec 06, 2009 at 02:37:07PM +0100, Simon Schampijer wrote: On 11/28/2009 05:00 AM, Aleksey Lim wrote: Hi all, Hi Aleksey, thanks for proposing this feature! http://wiki.sugarlabs.org/go/Features/TableView_Widget GTK widget to replace gtk.TreeView in Journal. Benefit to Sugar Standard gtk components are not designed to be lazy. Third party widgets, I managed to find, uses scheme with renders(like gtk components), introduced component uses widgets instead(could have performance penalties, I guess, in common case but we don't have many rows in Journal view, so should be ok for us). Can you elaborate on this? Instead of using the cell renderers to draw the data in the tree model we would pack widgets? we should just implement Cell class(regular wigdet) and it will be used for all(visible) cells, see example http://wiki.sugarlabs.org/go/Features/TableView_Widget#Simple_example_for_SmootTable_widget The API looks very good to me, just one thing: what means 3, 3 here? table = SmoothTable(Cell, 3, 3) visible_row_count and visible_column_count Oh, thought the SmoothTable would be able to know which is the visual area? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Glucose and Frame
On Tue, Dec 15, 2009 at 16:39, Cilyan Olowen gak...@gmail.com wrote: Hello ! I'm all new in the Sugar community, but I'm very interested in Sugar's very simple and intuitive interface for my grand parents who are completely new to computers. As I need a light and very strong system, I decided to base this on a distrib I know very well : ArchLinux. I met here another Archer who has almost the same needs and same interests, and together we decided to package Sugar for ArchLinux. That's for the background. Now the project has a little bit progressed, and I'm ending with Glucose almost packaged : hippo-canvas, hulahop, python-xklavier, squeak, sugar, sugar-artwork, sugar-base, sugar-datastore, sugar-presence-service, sugar-toolkit (I'm missing etoys and pyabiword). All this is now installed on my system and I wanted to make a little check of where I was. And surprise, after launching sugar in a console, no Frame ! Metacity is launched, together with a nice big cursor, but no Frame or Activity Circle. Same with sugar-emulator which opens a nice Xephyr window with a black screen and the famous cursor inside, but nothing more. And indeed it seems that the sugar script ends with no error or maybe forks to the background but I have no trace of it in ps. This leads to the simple question : Do I have a misconfiguration here, a bug, or am I simply missing a packet ? Woo, such a long message for a simple question, yes I know, sorry. But I needed to introduce myself too to your community ;) Hi Cilyan, welcome. Can you attach ~/.sugar/default/logs/shell.log? There should be some error. Thanks, Tomeu Regards, Cilyan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Glucose and Frame
On Tue, Dec 15, 2009 at 16:58, Cilyan Olowen gak...@gmail.com wrote: Thanks for the reply, here is the log and indeed, it seems there is a problem with the presence service. http://pastebin.com/mdac6658 Ok, and what says sugar-presence-service? Regards, Tomeu 2009/12/15 Tomeu Vizoso to...@sugarlabs.org: On Tue, Dec 15, 2009 at 16:39, Cilyan Olowen gak...@gmail.com wrote: Hello ! I'm all new in the Sugar community, but I'm very interested in Sugar's very simple and intuitive interface for my grand parents who are completely new to computers. As I need a light and very strong system, I decided to base this on a distrib I know very well : ArchLinux. I met here another Archer who has almost the same needs and same interests, and together we decided to package Sugar for ArchLinux. That's for the background. Now the project has a little bit progressed, and I'm ending with Glucose almost packaged : hippo-canvas, hulahop, python-xklavier, squeak, sugar, sugar-artwork, sugar-base, sugar-datastore, sugar-presence-service, sugar-toolkit (I'm missing etoys and pyabiword). All this is now installed on my system and I wanted to make a little check of where I was. And surprise, after launching sugar in a console, no Frame ! Metacity is launched, together with a nice big cursor, but no Frame or Activity Circle. Same with sugar-emulator which opens a nice Xephyr window with a black screen and the famous cursor inside, but nothing more. And indeed it seems that the sugar script ends with no error or maybe forks to the background but I have no trace of it in ps. This leads to the simple question : Do I have a misconfiguration here, a bug, or am I simply missing a packet ? Woo, such a long message for a simple question, yes I know, sorry. But I needed to introduce myself too to your community ;) Hi Cilyan, welcome. Can you attach ~/.sugar/default/logs/shell.log? There should be some error. Thanks, Tomeu Regards, Cilyan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [NEW FEATURE] write to the journal whenever you want
On Fri, Nov 20, 2009 at 15:49, Walter Bender walter.ben...@gmail.com wrote: On Fri, Nov 20, 2009 at 9:47 AM, Gary C Martin g...@garycmartin.com wrote: Hi Walter, On 19 Nov 2009, at 19:32, Walter Bender wrote: Many of us love the Naming Alert, but even more seem to despise it. With this feature, it is invoked from a toolbar button instead of automatically invoked on quit. It lets the learning take notes repeatedly and at any time during an activity session. See http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime This is a quick hack. We may want to revisit the toolbar integration and certainly need a better icon :) :-) The first thing that comes to mind is something Journal icon like (but still distinguishable from the Journal activity icon), the original Journal with pencil seems a good place to work from (as Eduardo already mentioned). Comments? Yes, I do like the intent, though I'm not sure we have activity toolbar space for another new icon. How about the whole dialogues content be placed in the activity icon secondary toolbar design (I think Simon raised this once before)? This would also make it non-modal, so you can add notes and interact with your activity canvas without the 'click the tick' edit cycle. The secondary toolbar does scale to fit the content height, but you'd need to be sensitive with the amount of space used as some activities will layout badly if too much of their canvas space is eaten away. I could try a few mockups if this approach seems reasonable. My mock up was just to get the ball rolling on this. It is a reasonable fall-back if we cannot get a better solution implemented in time for 0.88, but I would love to see more ideas emerge. I'm a bit wary about quick temporary fixes with big impact in the UI, because deployments generate materials that get outdated, etc. I'm pinging Christian and Eben in case they have more ideas about how to resolve the issue. About the bug of the values in the activity not being updated by changes in the journal, I think Simon is already working on it. Regards, Tomeu One thing that does seem a shame is that this indicates the Journal UI for adding details is not easy enough to use. Ideally we would have one single UI as part of the Journal for entering all entry details (for both code maintenance and design simplicity reasons). Activities could then providing a quick way to switch there. When the current original naming dialogue was first added I was hoping a way would be found to replace the new dialogue by just switching directly to the existing Journal detail view instead. Perhaps this should be the design goal (improving Journal integration/use rather than new separate activity based dialogues). We could use a bit more structure (esp. in the tags section) and a rich-text interface (including images and audio) in the description field.) Regards, --Gary -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 -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Backwards compatible Browse
On Mon, Nov 30, 2009 at 01:00, Wade Brainerd wad...@gmail.com wrote: I cloned Browse v114 and spent a few hours hacking on backwards compatibility. I added compatibility fallbacks for the toolbars and a few other modules. The repository is here: http://git.sugarlabs.org/projects/browse/repos/backwards-compatibility On OLPC build 8.2.0, the patched Browse v114 starts and basically works. A few features like typeahead find are broken and beyond my ability to trivially fix, but someone with more experience hacking XPCOM could probably figure it out quickly. Is there any interest in re-forging the compatibility chain, so that the latest Browse will work on old versions of Sugar? I think there's interest. Have given a look at your modifications and have these comments: +# If GConf is not available, automatic server authentication is disabled. +try: +import gconf +except ImportError: +pass was automatic server authentication working in any way in 0.82? If so, I guess we need to fix it (maybe we were using something else than GConf back then?) +try: +client = gconf.client_get_default() +except NameError: +return I would define HAS_GCONF, like you have done with the toolbars. +if not NEW_TOOLBARS: +_TOOLBAR_EDIT = 1 +_TOOLBAR_BROWSE = 2 I think we should try to not mix the main code with the compatibility one. Otherwise the code in activities will get quite more messy and when we decide to drop some of it we'll have more risk to introduce regressions. Nice work, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Sun, Dec 6, 2009 at 01:42, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Dec 02, 2009 at 04:38:56PM +0100, Bert Freudenberg wrote: On 30.11.2009, at 21:24, Bert Freudenberg wrote: On 30.11.2009, at 20:02, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? That would link the old and new version field - I thought of them as being independent. Basically, the old activity_version field would be a like a build number, increasing for every build, as we did before. It would be optional in Sugar 0.88. The real user-visible version number would be the dotted one in a different field. An activity author who wants to support both could keep incrementing activity_version, and assign dotted version numbers independently. - Bert - Thinking about this, for Etoys it doesn't really make a difference. We can as well switch to the dotted-only scheme. So unless other activity authors feel backwards compatibility is needed, just use whatever is simplest. Is this already written up as a feature? Couldn't find it. I've created http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions and wrote several options of your proposal(how I understood it) in http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description Also I pushed it to Feature Ready for Release Manager group though this feature doesn't meet all requirements(there is no owner, I guess it will be trivial to code it) but it let us do not forget about this feature. Thanks a lot for entering the feature page. Do we have any consensus on which alternative is best? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
On Sun, Dec 13, 2009 at 03:42, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, At the end Journal Plugins mutated to Frame Panles feature. All UI visible changes I wanted to implement in plugins could be done via Frame Panle components(the rest of code are shell agnostic). I'm having trouble guessing which needs addresses this change. Does this idea come from any need expressed by our users? Thanks, Tomeu Frame Panles feature has the same major idea, social context - giving non core developers more freedom in case of releasing/supporting theirs code, e.g. adding GSM modem support could be implemented not in core(thus stuck to sugar version, when previous sugar version users can't grab last changes of GSM modem component) but as a standalone activity(and deployed as a regular activity). == Summary == Treat frame as a containers(upper, left, right and bottom) for predefined or custom components i.e. having GNOME panels analog in sugar. == Detailed Description == The major reason is to let activities like FileShare or Chat special UI representation in shell's interface. It could be also useful if user wants fast access to some activities like Journal replacements. Any of four panels could be stuck i.e. let user see its components all time. === Predefined components === * rings switch * activities list * clipboard * users list * sources list * network component * notification area == Benefit to Sugar == * let users more freedom to organize sugar shell how they want * provide to activity developers a way to integrate theirs activities * to shell UI(useful for activities that work in background and * requires some kind all-time-present indicator in UI) * having stable API for panel components, activity developers have more * freedom and aren't stuck to core releases e.g. Network * activity/component(analog of NM widget in GNOME) could support * several sugar releases and previous release sugar users will benefit * from last Network component. * previous sugar release users will benefit from last updates of * predefined components as well == UI Design == * all of four frame panels could be stuck * manage components, way to add-new/remove/move components * components could have shell level key shortcuts == User Experience == * sugar frame as a regular GNOME panels -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Future of Zero Sugar
On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Aleksey Lim wrote: So, I have strong intension to switching development focus from core team, which develops sucrose - glucose(core) and fructose(some core activities) to wide range of developers/doers thus some kind of decentralization of development process. I agree. I think this has been a central part of the Sugar design philosophy from the beginning. I think your message is very much on the right track. While I think this is in the spirit of my vision for Sugar, my experience with how Sugar is being used and deployed _today_ makes it quite uninteresting and too invasive to consider for the near future. The current barriers for people to contribute to Sugar development and share their work are mostly cultural. We can make the technology a thousand times easier to modify, but if people still think that they can be only users, we won't gain anything. If we really want more people to realize their power and modify sugar and share their work, we need to, in order: - show how the community can address some of their needs, as perceived by them, - show how they can better address the rest of their needs by working within the community. The rest is just icing on the top, IMHO. Regards, Tomeu [snip] * I hope to see many shell forks with implemented features like new sugar themes(wallpapers support, new icons etc.), Actions view implementations from non-core development/doers. The benefit they will have after 0install integration is more useful method to share these forks - just a regular entity on Activity Library that brings new shell to user environment I don't think this part will work as a regular entity on Activity Library, for security reasons. Any Activity that hooks so deeply into the shell is no longer safe to run. It is running with the full authority of the user and can violate the user's privacy or interfere with the user's actions. In orders to encourage users to become doers, Sugar is designed to make sure that Activities are always safe to run (thanks to Bitfrost/Rainbow protections). I would of course support an effort to wall off parts of the shell in a secure fashion, but so far almost no work has been done in that direction. --Ben ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Future of Zero Sugar
On Mon, Dec 14, 2009 at 17:01, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Dec 14, 2009 at 04:19:51PM -0200, Tomeu Vizoso wrote: On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Aleksey Lim wrote: So, I have strong intension to switching development focus from core team, which develops sucrose - glucose(core) and fructose(some core activities) to wide range of developers/doers thus some kind of decentralization of development process. I agree. I think this has been a central part of the Sugar design philosophy from the beginning. I think your message is very much on the right track. While I think this is in the spirit of my vision for Sugar, my experience with how Sugar is being used and deployed _today_ makes it quite uninteresting and too invasive to consider for the near future. The current barriers for people to contribute to Sugar development and share their work are mostly cultural. We can make the technology a thousand times easier to modify, but if people still think that they can be only users, we won't gain anything. If we really want more people to realize their power and modify sugar and share their work, we need to, in order: - show how the community can address some of their needs, as perceived by them, - show how they can better address the rest of their needs by working within the community. The rest is just icing on the top, IMHO. well, thats all true but it doesn't exclude easy to change and easy to share possibility of doer's changes e.g. if I want to hack Journal by adding wallpaper support(and of course want to expose my changes) the worst way that could be is proposing my changes to core team(e.g. think about proposing your patches to kernel.org team - maybe exaggerating but the same level issue). Having ready to use sugarized 0install environment gives developers easy sharing method. As I said, I agree with your points of view and also agree something should be done in the path you show. But I also think that presently, what would bring more users and deployers on board, is by caring of their more immediate needs. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] moving some more configuration to gconf (was Re: some efforts that would be really useful for deployments)
On Tue, Dec 8, 2009 at 06:56, Simon Schampijer si...@schampijer.de wrote: On 12/07/2009 11:39 AM, Mathieu Bridon (bochecha) wrote: On Mon, Dec 7, 2009 at 10:11, Simon Schampijersi...@schampijer.de wrote: Yes, I think it makes sense to control settings via gconf - this should be our standard way. Isn't Gnome thinking about dropping GConf ? (in favor of DCconf as far as I understood) I'd be worried about using a technology that upstream is not certain to go on maintaining :-/ In general I agree. Though, the discussion with moving away from gconf has been for a while. It has been now scheduled for 3.0 it looks like. http://mail.gnome.org/archives/devel-announce-list/2009-November/msg2.html + dconf (desktop) - agreement it's the way forward - concerns about migration of settings - concerns about the lack of planning for admin tools (pessulus and sabayon) - concerns about the fact that we need stuff in glib but that's not there yet (although we know there's a plan for this) - a massive migration from gconf to dconf would be preferrable (instead of having some modules using gconf and some other modules using dconf). We know it might not be realistic, though. = rejected for this cycle, but pre-approved for the next cycle (assuming glib gets the required API for the next cycle). The additional time should be used for careful planning of the above items. = we encourage developers to look at it and to create gsettings branches for their modules (like devhelp and gedit). Maybe someone wants to evaluate the current status of dconf, work out the pros and cons and present a summary here? I'm following those discussions and I don't think it's time yet for any project do ditch gconf for dconf. And when the time comes, it will be such a minor modification that is not worth our discussion time. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] File Share Activity
Would you like for people in Uruguay to test it? 0.84 and later Sugar releases have file transfer in the journal, but most OLPC machines are stuck with 0.82 for the time being. Btw, are you the author of Bundle or is it another Lewis? http://dev.laptop.org/git/activities/bundleactivity/ Regards, Tomeu On Sat, Dec 12, 2009 at 02:30, Justin Lewis jtl1...@rit.edu wrote: Hey members of sugar-devel, Just wanted to let you know that I have been working on a file share activity and is now in a testable state. It is still under development, but I figured I would share it with everyone and see what you all think. The activity can be found on on the sugarlabs wiki. http://wiki.sugarlabs.org/go/FileShare Please feel free to check it out. Let me know if you have any suggestions, bugs or other feedback. Justin Lewis http://wiki.sugarlabs.org/go/User:Jlew ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Technique to extract all records from xapian DB?
On Sun, Dec 6, 2009 at 12:49, Martin Langhoff martin.langh...@gmail.com wrote: I am trying to add minimal support on 0.84 for the old 0.82 format in which JE metadata was saved on external disks. By minimal I mean read-only, fail-safe, and generally with small impact on the codebase. I sure don't want to reimplement the old DS code Is there a simple (and cheap) way to read the xapian DB and extract all the records, complete? I think it's worth trying, but not sure if worth merging and deploying. 0.82 didn't used directly the python xapian bindings, but some wrapper on top of it that tried to make easier the mapping between keys in the B-tree and metadata values. I'm not sure if it would be easier for you to try to read the index with the basic bindings or by using secore (now called xappy). The mapping mentioned before is persisted in index/config inside the DS dir. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] branches for sugar-base and hulahop
Hi, hulahop lacks any branch and sugar-base has only 0.82 and 0.86. Can the missing branches be created in the points where new development started? Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] resource for understanding git
Unfortunately, for learning git you need to have some knowledge of its architecture. This link has helped me understand quite a bit of things: http://www.newartisans.com/2008/04/git-from-the-bottom-up.html Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] activity.info enhancements
On Fri, Dec 11, 2009 at 17:18, Sayamindu Dasgupta sayami...@gmail.com wrote: On Fri, Dec 11, 2009 at 11:13 PM, Walter Bender walter.ben...@gmail.com wrote: Summary: It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file. Details: In walking the process of creating an RPM of one of my activities with Sebastian Dziallas, who is doing lots of packaging for Fedora and SoaS, we observed that many fields in packages' .spec files could readily be pulled from the activity.info file. A few additional fields would be necessary, such as the following: * a short summary * an URL to the source package * an URL to the activity home page * the required dependencies to run None of these additional fields are particularly onerous for an activity developer to provide and it would enable the creation of a script (as part of setup.py/bundlebuilder.py) to do most of the work in creating the .spec file. (I assume .deb has similar requirements to .rpm). Things are more complex for activities that include binaries and the like, but for the most part, we should be able to greatly facilitate upstream maintenance of our code while asking little more of Sugar developers. None of these additional fields need be required, but their inclusion would make things easier. (This is not a new idea, but one that seems timely given all the upstream interest in Sugar these days.) It may be interesting to factor in localization (eg: translation of the description, etc) into this discussion. We already translate parts of activity.info so it may be trivial to extend the mechanism. However, it does increase the workload on translators a bit, and we need to agree on which fields to translate (for example, if we have a non-UI-visible field called category or tags, it may not make sense to translate it). I was thinking of displaying these tags in the activity list (or it's already happening, not sure). Also, if we allow searching for those, we would need to do so with the ones in the local language. Regards, Tomeu It may also be worthwhile to keep some kind of compatibility with the desktop-entry spec http://standards.freedesktop.org/desktop-entry-spec/latest/, in case we add support for standalone activities in the future. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] links and commands for supporting development
More links about what we have covered today: http://wiki.sugarlabs.org/go/User:Tomeu/CeibalDay2 == Overview of Sugar's architecture == http://wiki.sugarlabs.org/go/Development_Team/Release/Modules http://wiki.sugarlabs.org/go/0.86/Platform_Components http://wiki.sugarlabs.org/go/Development_Team/Release http://wiki.sugarlabs.org/go/Development_Team/Architecture http://people.collabora.co.uk/~danni/telepathy-book/ == Code submission == http://wiki.sugarlabs.org/go/Development_Team/Code_Review http://wiki.sugarlabs.org/go/Development_Team/Code_guidelines http://www.python.org/dev/peps/pep-0008/ http://wiki.sugarlabs.org/go/Development_Team/Almanac http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface/Colors http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface/Layout_Guidelines == Sugarization of C activities == http://wiki.sugarlabs.org/go/Running_Linux_Applications_Under_Sugar http://git.gnome.org/cgit/gcompris/tree/src/gcompris/gcompris.c?h=gcomprixogoo#n642 http://git.sugarlabs.org/projects/etoys/repos/mainline/blobs/master/etoys-activity#line77 == Forking of rpms == http://fedoraproject.org/wiki/Projects/Mock http://bradthemad.org/tech/notes/patching_rpms.php http://www.rpm.org/max-rpm/s1-rpm-miscellania-rpm2cpio.html http://cvs.fedoraproject.org/viewvc/F-11/sugar/sugar.spec?view=markup http://koji.fedoraproject.org/koji/buildinfo?buildID=144037 Regards, Tomeu On Wed, Dec 9, 2009 at 17:20, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, have been talking today with developers at the Plan Ceibal and have written down a series of links and commands that were discussed. I'm sending this to the list in case is useful and in case someone has any questions. Regards, Tomeu git checkout -b sucrose-0.84 origin/sucrose-0.84 sshfs to...@10.0.0.33:/home/tomeu/sugar-jhbuild/install/lib/python2.6/site-packages/sugar sugar http://embraceubuntu.com/2005/10/28/how-to-mount-a-remote-ssh-filesystem-using-sshfs/ PermitRootLogin yes PasswordAuthentication yes PermitEmptyPasswords yes http://wiki.sugarlabs.org/go/Development_Team/Release http://wiki.sugarlabs.org/go/Features http://wiki.sugarlabs.org/go/Features/Policy http://wiki.sugarlabs.org/go/Development_Team/Code_Review http://wiki.sugarlabs.org/go/Development_Team/Code_guidelines http://wiki.sugarlabs.org/go/Development_Team/Architecture http://wiki.sugarlabs.org/go/0.86/Platform_Components http://docs.python.org/library/pdb.html http://winpdb.org/ http://code.djangoproject.com/wiki/DebuggingDjangoWithWinpdb import rpdb2 rpdb2.start_embedded_debugger(any_password) http://producingoss.com/ -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fructose - What is it? What should it be?
2009/11/27 Gary C Martin g...@garycmartin.com: Hi Tomeu, On 26 Nov 2009, at 12:41, Tomeu Vizoso wrote: On Tue, Nov 24, 2009 at 17:44, Simon Schampijer si...@schampijer.de wrote: On 11/24/2009 03:18 PM, Aleksey Lim wrote: On Tue, Nov 24, 2009 at 02:57:16PM +0100, Simon Schampijer wrote: Hi, this came up several times now. People where wondering what Fructose is. From the definition it is: The Sugar developers will need some example set of activities with which to demonstrate Sugar. This set is Fructose. The packages in Fructose should be selected to make the resulting environment as impressive as possible for a potential client or user. Packages should therefore be stable, polished, and exercise the widest possible range of features. Fructose may also serve as an example for people constructing their own Activity sets. [1] The current list of activities can be found at [2]. The fructose activities follow the Sucrose development cycle (0.84, 0.86...). This means they follow the freezes, provide source tarballs, need a present maintainer etc. The duties are described at [3]. The activity gets noted in release notes, possibly more attention by the localization teams as revenue. In the end their are downsides and upsides to be part of Fructose. There were some arguing, that only system dependent activities should be part of it (e.g. Browse with the dependency on hulahop). There were some discussions that we would loose the show case activities when an activity would not be part of Fructose anymore. This comes down to packaging, as for rpm packaging one needs to provide the source tarballs and need to follow certain rules. Some distributors may ship the .xo bunles at one point, otherwise probably won't, so it is a good habit to do the source releases. Anyhow, this is a bit of the background. Let's think how we can move forward on this topic. We should do it quickly, to be able to keep the work on 0.88 going. In my mind, the best thing we can do is making clear definition: 1) we have core with strong release cycle * glucose(and its dependencies) * sugar platform(additional dependencies) (core) 2) various sugar activities (the rest of development community) 3) sugar users (the rest of community) Relations between 1) and 2) totally depends on sugar release cycles. Activity developers decide what release cycles they can/should/will support. For activities like Browse it will several activities versions per SP release. Most activities will support several SP release. Relations between 2) and 3) is task for various deployment methods. Since fructose makes sense mostly for users, its content should totally depends on deployers not core. So I can't see the 4rd place for fructose, only as a part of 2). So far, I conclude, that Fructose as we have it today is outdated. The tarball issue could be solved with adding for example a field to ASLO, to be able to upload a tarball too, when doing a release. As I think where to upload a tarball was one big issue back in the days. The packaging (rpm, xo, deb) and how you install/upgrade, where you install (system vs user space) is then up to the deployer. As the tarball is available, that should work out nicely. Activities that rest coupled to the Sucrose release would be Browse and Etoys as they have strong platform dependencies. I think hulahop is more mature now and won't change as much in the future. Also Python allows us to do lots of tricks to keep backwards compatibility, but it all takes time developing and testing. Browse may be now in the same situation as Read. I don't think the problem is that Browse depends too much in hulahop, but that the only help the maintainer has with regard to this issue is when people complaint that the last released Browse is not working in the release they are running. With some more manpower I think we could surmount these issues. Sorry, just to be sure I read correctly, were you recommending/suggesting that we should try to update the Browse activity so that it works on past and present versions of Sugar (let's say 0.82 and up) rather than forking versions at every new Sugar release? I was suggesting the possibility, but if it's a good idea or not should be decided by its maintainer with the participation of deployers, etc. Does anything else need hulahop, or could it just be bundled inside Browse? I know there was a lot of talk about creating a simple html widget for any activity to easily use, but just wondered if anything else is actually using hulahop now. Karma perhaps, the Help-french activity, Lucuan's Webified? Yeah, I think some activities ended up using it. There's also some downsides to bundle binaries inside .xos, specially if they depend on much other stuff in the system. Regards, Tomeu Regards, --Gary -- «Sugar Labs is anyone who participates in improving and using Sugar. What
[Sugar-devel] [DESIGN] activity upgrading (was Re: some efforts that would be really useful for deployments)
2009/11/25 Daniel Drake d...@laptop.org: [snip] Automatic activity upgrading Activity updating is too difficult for young children to understand and is very hard to coordinate across a classroom. This one I have never had time to hack a fix into place. Also the You should upgrade your activities notice needs to die. Any ideas about the best user experience for users updating their activities? Lots of people have been complaining about this. I know we discussed it in the past but cannot remember the conclusion, if any. Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] translation updates (was Re: some efforts that would be really useful for deployments)
2009/11/25 Daniel Drake d...@laptop.org: Another constant headache is with translations. How do you roll out new translations for old software? The best we have right now is language packs but they install files which conflict with both system packages and activity bundles. And they are difficult for deployments because you need Linux skills to execute them. I guess that we don't have this problem for software packaged in rpms? For activities, once we get major/minor version numbers, may be easier to spin new stable releases with updated translations? If we still need to decouple the translations from the release process, then I guess Sayamindu's proposal is the way to go. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] some efforts that would be really useful for deployments
2009/11/25 Daniel Drake d...@laptop.org: Hi, After revisiting some of the changes I have made to the software while working on deployments I just wanted to post the list again as a refresher. Thanks for doing this, I think it really helps to ping people until the important stuff gets finally done. Regards, Tomeu I have not had enough time to do the appropriate master-level QA on these, or to get them running on the latest Sugar versions. I hope that some people will consider taking on these tasks. Some of the items here are far from trivial and will require design and thought to fix properly. Some of the items below are not purely sugar tasks. But at the same time they are really big items for sugar deployments. (Just to throw in some opinion here too, I feel that all deployments would benefit from more time being spent working on deployment technologies and realities at the system level -- Sugar 0.82 reached a point where the biggest problems you find in the field are far outside of the UI/activities level, now we have to attack the others) Customizing browse homepage The procedure to do this is too complicated for most deployments, and is undocumented. Customizing which activities are in the favourites view by default You can do this just by editing a file, but that file is a part of the sugar distribution so it will be lost on upgrades. There is also no documentation for how to do this, as far as I can see. Automatic activity upgrading Activity updating is too difficult for young children to understand and is very hard to coordinate across a classroom. This one I have never had time to hack a fix into place. Also the You should upgrade your activities notice needs to die. Unregistering from an XSes / registering with multiple XSes A hack available here: http://dev.sugarlabs.org/ticket/362 Still no user-friendly or documented way of doing this. Full journal restore, and backup control http://dev.laptop.org/ticket/9250 We still don't have a good way of browsing backups or restoring multiple files (e.g. the whole journal) in 1 go. Another constant headache is with translations. How do you roll out new translations for old software? The best we have right now is language packs but they install files which conflict with both system packages and activity bundles. And they are difficult for deployments because you need Linux skills to execute them. Registration is a real headache in classrooms right now. It's just a bit of an alien concept for new computer users. And it's so difficult. If you try to register before connecting then a bug somewhere means that you can't even complete a successful registration after connecting -- you have to restart sugar. And then after you do register you have to restart sugar for it to take effect. http://dev.sugarlabs.org/ticket/1151 But why do we force users through the pains of registering at all? We control all the technical bits, lets automate it to hunt down the specific school server and register. http://dev.sugarlabs.org/ticket/1152 And once we're that far, why do users have to select which network to connect to? This is also a significant classroom challenge. But typically in deployments, networks are installed at the same time that the sugar systems are made available. It's all controlled by the same party. So we could have a way that deployers could make sugar automatically connect to specific networks, or something like that. During activity update, only download the parts that have changed http://dev.sugarlabs.org/ticket/1499 And speaking now from a Sugar implementor standpoint, here are 2 fully specced features which have yet too see much attention: http://wiki.sugarlabs.org/go/Features/Font_configuration http://wiki.sugarlabs.org/go/Features/Content_support Any takers? :) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.84 maintenance
2009/12/1 Daniel Drake d...@laptop.org: Hi, Earlier this year, OLPC began developing a new laptop (XO-1.5) and OLPC OS (based on Fedora 11). Sugar-0.84 was hot off the presses at that time so even though it may feel a little dated today, it's what we've been working with and will soon be shipping in large quantity. One issue that we've been facing is various regressions since Sugar 0.82, some of which have been fixed in Sugar versions later than 0.84 and some which are still pending. As nobody seems to look after 0.84 any more we've been backporting these fixes into a local branch for our OS builds. Now we're going to move to making these changes in the usual sugarlabs git repositories (sucrose-0.84 branches) and publishing them as regular Sugar releases of the main components. This is an improvement/cleanup to our current development processes and will open it up for other people to become involved. (we already have our 'offline fork' including about 15 patches, but we're not being very organised with our development working this way) So, OLPC will take over maintenance. To start with we'll just be working with sugar and sugar-toolkit. Me and Sayamindu will be taking care of this. There may be exceptions, but in general we'll only be taking patches that are already in master. We'll focus on fixes, but if there are really important features then we'll take them too (ad-hoc networking support is the 1 example we have right now). Of course, we'd love support from those of you who are actively involved in Sugar development. In a way it's a bit sad for us to see that 0.84 maintenance already seems to have been halted, but at the same time it's certainly our responsibility to make contributions as well. Thanks a lot for stepping up and taking these tasks, in my view this is a big step forward for Sugar. About the general issue of maintenance of stable releases, I don't think it has to be so black and white. There's lots of ways to contribute resources that end up benefiting maintenance of stable releases: - take maintenance of whole modules, - become comaintainers of whole modules, - take roles in the community that right now are overloaded on existing maintainers: coordinator of teams such as development, QA, community, etc. - help with bug triaging, - answering questions in the mailing lists and irc channels, - help with macro-features such as accessibility support, performance, static bindings, etc (deployments might not care right now, but these are areas that Sugar must tackle at some point in order to keep growing), - keep pinging and summarizing the most important points for deployments, - and finally, taking maintenance of a stable branch in a module. I'm not saying the option you have chosen is not the best one in this circumstances, I just wanted to point out that if more resources are needed in stable branches, there are still all those ways to keep improving on this. So we'll try and keep the community updated on the issues that we are facing, and hopefully you will be interested in helping us out. We'll be shipping this to a lot of children. Thanks for the continued developments on sugar, but don't forget that developing is only a small part of the challenge...! Yes, thanks for keeping reminding us, for SLs to be a cohesive and inclusive community, we need a bigger exchange of needs and points of view. Also on this topic - we will certainly run into issues where activities themselves progress beyond the Sugar-0.84 platform; if activity authors could work to minimize these cases (i.e. keep backwards compatibility, remain responsive to bugs) it would help us avoid a huge headache, and will help your activities spread to various corners of the globe. I think this is a current policy of the activity team? Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] moving some more configuration to gconf (was Re: some efforts that would be really useful for deployments)
2009/11/25 Daniel Drake d...@laptop.org: [snip] Customizing browse homepage The procedure to do this is too complicated for most deployments, and is undocumented. Customizing which activities are in the favourites view by default You can do this just by editing a file, but that file is a part of the sugar distribution so it will be lost on upgrades. There is also no documentation for how to do this, as far as I can see. [snip] And once we're that far, why do users have to select which network to connect to? This is also a significant classroom challenge. But typically in deployments, networks are installed at the same time that the sugar systems are made available. It's all controlled by the same party. So we could have a way that deployers could make sugar automatically connect to specific networks, or something like that. [snip] http://wiki.sugarlabs.org/go/Features/Font_configuration It has been suggested that GConf is the way to go here because is precisely intended to simplify customization of defaults by deployments. Everybody agrees with this? Should be a goal? Maybe someone from the technical teams at .uy or .py would like to lend a hand? Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
2009/11/27 Aleksey Lim alsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] registering/unregistering to XS (was Re: some efforts that would be really useful for deployments)
2009/11/25 Daniel Drake d...@laptop.org: Unregistering from an XSes / registering with multiple XSes A hack available here: http://dev.sugarlabs.org/ticket/362 Still no user-friendly or documented way of doing this. From the other day's conversation in #sugar, seemed like the command line tool was enough for some deployments? Do we still need to add anything to the UI? Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
2009/12/3 Aleksey Lim alsr...@member.fsf.org: On Thu, Dec 03, 2009 at 12:23:37AM -0500, Eben Eliason wrote: On Tue, Dec 1, 2009 at 5:54 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Nov 30, 2009 at 9:40 PM, Wade Brainerd wad...@gmail.com wrote: When deleting an object from the Journal that is an activity bundle, we ought to display an alert with a scary icon. The alert should clearly state that Journal entries will no longer be able to be opened until the activity is reinstalled. Majority of 6 year old will not understand that. The best way to handle this, I think, is to let kids delete activities but also keep a reference to the source in the form of an update URL or similar, so that fetching the activity automatically when an instance of it is resumed can be done. There's additional UI work there, and we can't guarantee connectivity, etc., but it would help reduce the overhead involved. (I'm not suggesting we shouldn't find ways to make it clearer when a deletion is happening, either, but as noted, the dialog may not work in practice with the target audience.) Some of the other operations Aleksey mentioned, like upgrading activities, ought to display similar alerts. Gentlemen, alerts do not work with young users. We have to just DTRT, or provide actions that are very clearly different (and even then...). On a more general note, this discussion has many hints of the action/object views that have been tossed around for some time now. This specifically addressed the conflict between the desire to manage all objects and the desire to have the Journal reflect only the actions of the child. In this split, the action view shows actions, which reference one or more objects (activities, people, devices, etc.) This would contain only references to things the children have done themselves. The object view shows objects, which is a more traditional view of everything that's around to be manipulated. Any preinstalled activities would appear in the object view by default, and thus be accessible by kids to copy, share, modify, etc. (and as they do, new actions will be created to record that). Ultimately, the object view would look much like the current Journal view does, and the actions view would be a bit friendlier. One benefit of this is that young kids need only look at the actions view, while those that wanted more control could dig into the objects directly. Good catch, what about more explicit following user works all time with the same objects but from different views and add Action view as a Journal plugin(and maybe make it default) to [1](technically we need addition data to form actions view but for users it could be the same (as in objects view) objects but organized to actions. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins I agree that the split of the journal in an actions and objects view would help with this and other problems we currently have in the journal. The GNOME Activity Journal is also going with this. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Feature Policy updated
2009/11/29 Simon Schampijer si...@schampijer.de: On 11/27/2009 09:00 PM, Sascha Silbe wrote: On Fri, Nov 27, 2009 at 07:40:26PM +0100, Simon Schampijer wrote: * Backup up by the community * The proposer of the feature has to get feedback from the community. This includes technical feedback, feedback from the deployments etc. See as well in the last paragraph about which points the community might care. Of course there will be some different opinions in the community - in general there should be more YES than NO in the community for a feature to be able to get into a Sugar release. This puts the burden of interacting with deployments on each individual feature proposer (but away from the core developers, which is a good thing). How is that supposed to happen (getting feedback from deployments)? Writing to iaep? What if nobody replies to those messages (e.g. because it doesn't matter to them either way), will the feature be rejected even if it's a good idea? (*) Yes, sending an email to sugar-devel - see here the section community consensus [1]. So deployments for example interested in the evolution of the Sugar platform should read sugar-devel and watch out for the [FEATURE] tag. Of course not only deployers are invited to comment. The idea is to have the submitter of a Feature taking care of getting the feedback. He is the one that knows best about the feature. It is good practice to interact with the community, too. The release manager is just there to make sure the process is done correctly. I think the deployment team can play a strong role here, but it's currently in need of re-energizing. In the meantime, I think you can ask people like Daniel Drake, Martin Langhoff, Caroline, Walter, me, etc. to proxy that request to others or share whatever we may have heard about the need in the field. Local labs might also be able to help here. There's also a page in the wiki that lists some contacts in deployments that are active in the community, should be something like Deployment_Team/Places. Regards, Tomeu (*) Obviously good idea is quite subjective, but I assume you understand what I mean. I guess we have to use common sense for that. There are guidelines [2] what you should thinks about before proposing a feature. I hope we don't see dead ends often. If we do, we can create a board that solves such conflicts - like the oversight board (not sure if it is the same board or if it has to be a different one). Regards, Simon [1] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle [2] http://wiki.sugarlabs.org/go/Features/Policy#Things_you_should_consider_when_proposing_a_feature ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Removing Log and Terminal from favorites view
On Fri, Dec 4, 2009 at 11:21, Simon Schampijer si...@schampijer.de wrote: On 12/04/2009 12:15 PM, Daniel Drake wrote: Hi, For the OLPC builds we're removing Log and Terminal from the default favorites view. Is there any interest in making this change in upstream sugar too? The reasons being that these activities are confusing/useless for young children, but are left discoverable in the list view for older users as well as other people who end up working on more technical tasks with the laptops. Daniel +1 Sounds good to me. I'm ok with that, but I think that the favorites file in the sugar tarball should be considered an example, and nothing that packagers and deployers should accept as-is. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] adding 3G devices support to sugar
On Thu, Dec 3, 2009 at 18:44, Martin Abente mabe...@paraguayeduca.org wrote: Today i finished the systray device icon. (but i still need the icon graphic... any artist around?) What would be a good symbol? A GSM base station? http://www.mobilecomms-technology.com/projects/india_gsm/images/img1.jpg So, now we have 1. Store settings with gconf 2. Configuring settings at control panel (thanks to Daniel Castelo) 3. Systray device icon fully working 4. Gsm connections management I still need to clean stuff on 1,3,4 Congratulations! Tomeu Saludos, On Wed, 2 Dec 2009 10:43:51 -0200, Daniel Castelo dcastelo.sugarl...@gmail.com wrote: In Uruguay we need USB_SERIAL_OPTION for 3G Modems. Martin, I could test your work using 3G Modems. I could help programming the control panel and the device icon too. On Wed, Dec 2, 2009 at 10:31 AM, Martin Langhoff martin.langh...@gmail.comwrote: On Wed, Dec 2, 2009 at 3:04 AM, Martin Abente mabe...@paraguayeduca.org wrote: I have successfully extended jarabe/model/network.py, so we can load-in a gsm connection, tested it with my app (gsmbridge) and it works, tomorow ill clean up the code, add the control panel and the device icon part. Cool. Can you give us a list of kernel modules that will work with this, so we can look at building them for the XO1/1.5 kernels? They'll probably be split off in a separate rpm, but easily installable. 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 Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.87.1
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.87.1.tar.bz2 == News == * Several Access Points with the same essid #330 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-presence-service-0.87.1
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-presence-service/sugar-presence-service-0.87.1.tar.bz2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] adding 3G devices support to sugar
Hi all, have heard about progress from the different people involved in this effort, but it's being a bit hard to track who is doing what and where the problems are. Could you write a small note in this thread saying what the status are, plans going forward and any problems you are finding? As with most FOSS work, there isn't a single person who has all the knowledge required, so 1-to-1 conversations aren't particularly effective. If the existing forums are not appropriate enough, please tell and we can discuss alternatives. Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] maintenance of 0.84 branches
On Thu, Nov 26, 2009 at 13:43, Daniel Drake d...@laptop.org wrote: On Thu, 2009-11-26 at 09:53 +, Daniel Drake wrote: On Thu, 2009-11-26 at 09:45 +, Tomeu Vizoso wrote: We'll need that they make explicit which modules want to take maintenance of and then each current maintainer should agree or disagree. All of glucose, I guess. Right now we only have patches for sugar-toolkit and sugar. Actually, we'd rather only take over maintenance where it has stopped. So for sugar and sugar-toolkit at least that seems necessary. I'm the maintainer of sugar and I'm fine with it. Simon maintains sugar-toolkit. As I think you have already commit access, please add yourselves to sugar/MAINTAINERS and update http://wiki.sugarlabs.org/go/Development_Team/Release/Modules#sugar . If existing maintainers of other components are able to continue taking new patches (from master) and translations and publishing releases then we'd rather leave the job to them. Mind that it's not just a matter of a module or branch being maintained or not. It's more about the person officially responsible for that having time to attend all the requests or not. There are many ways to increase the resources available for the maintenance tasks of a module: being a co-maintainer, taking maintenance of another module maintained by the maintainer, helping with bug triaging, replying to questions posted in the mailing list, fixing bugs in that module, helping with attracting more contributors, and a long etc. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] CMDA/GSM/3G Modem Support in Sugar
On Fri, Nov 27, 2009 at 12:48, Daniel Castelo dcastelo.sugarl...@gmail.com wrote: We are thinking in add CMDA/GSM/3G Modems Support in Sugar. We want to discuss the best interface to allow user configure and use this type of connections. Awesome! The basical idea that we managed is to have an option in control panel to allow users to setup the connection, and a device icon in the bottom frame where users could connect and disconnect it. If is possible when the SO detect the new device, sugar could show the device icon and a shortcut to setup it. Yes, that's easily doable. The fields that user should configure are: Tel Number, User Name and Password (which more?) We should discuss if we will allow configure many conections or just one. I would vote for just one as a start. Or will the users in your deployment need to configure more than one? Regards, Tomeu Opinions, Contributions? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] maintenance of 0.84 branches
Hi, Daniel Drake and Sayamindu Dasgupta have offered to take maintenance of the 0.84 branches of some modules in glucose and fructose. I'm happy about this because apart from their technical capabilities, they are working for OLPC's deployments so can know better what their needs are. Any concerns about it? We'll need that they make explicit which modules want to take maintenance of and then each current maintainer should agree or disagree. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ooo4Kids in several languages - how to let it appear on aslo?
Hi Bastien, On Thu, Nov 26, 2009 at 09:27, Bastien bastiengue...@googlemail.com wrote: Dear all, I just uploaded Ooo4Kids 0.5.1 on aslo: http://activities.sugarlabs.org/fr/sugar/addon/4241 There is an spanish version here: http://download.ooo4kids.org/es/descargar-ooo4kids-xo-intel How to host this spanish version on aslo? Should I make another activity, or is it possible to upload several branches? Thanks for any hint! Has the OOo4Kids team considered using gettext or similar so can ship a single bundle containing several localizations? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ooo4Kids in several languages - how to let it appear on aslo?
On Thu, Nov 26, 2009 at 09:48, Tomeu Vizoso to...@sugarlabs.org wrote: Hi Bastien, On Thu, Nov 26, 2009 at 09:27, Bastien bastiengue...@googlemail.com wrote: Dear all, I just uploaded Ooo4Kids 0.5.1 on aslo: http://activities.sugarlabs.org/fr/sugar/addon/4241 There is an spanish version here: http://download.ooo4kids.org/es/descargar-ooo4kids-xo-intel How to host this spanish version on aslo? Should I make another activity, or is it possible to upload several branches? Thanks for any hint! Has the OOo4Kids team considered using gettext or similar so can ship a single bundle containing several localizations? Eric has told me in #sugar that the reason for this is because each locale takes about 100MB when compressed. If it's not feasible to make the locales smaller, then I would recommend creating different activities, with different activity ids. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSM/CDMA Modems support (part II)
On Wed, Nov 25, 2009 at 14:47, Daniel Drake d...@laptop.org wrote: On Wed, 2009-11-25 at 09:36 -0500, Martin Abente wrote: Would a patch that extends the allowed connection types be accepted in the 0.84 branch (that will be shipped with F11) ? Depends on the patch, but in general one requirement I've been putting on patches for OLPCs 0.84 fork is that the patches must already be in sugar master. So this should be your first port of call... I'll be happy to work with Martin (and whoever else) on this. From looking at http://trac.paraguayeduca.org/browser/nmbridge , Paraguay Educa has already the required skills to do a great work there. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fructose - What is it? What should it be?
On Tue, Nov 24, 2009 at 17:44, Simon Schampijer si...@schampijer.de wrote: On 11/24/2009 03:18 PM, Aleksey Lim wrote: On Tue, Nov 24, 2009 at 02:57:16PM +0100, Simon Schampijer wrote: Hi, this came up several times now. People where wondering what Fructose is. From the definition it is: The Sugar developers will need some example set of activities with which to demonstrate Sugar. This set is Fructose. The packages in Fructose should be selected to make the resulting environment as impressive as possible for a potential client or user. Packages should therefore be stable, polished, and exercise the widest possible range of features. Fructose may also serve as an example for people constructing their own Activity sets. [1] The current list of activities can be found at [2]. The fructose activities follow the Sucrose development cycle (0.84, 0.86...). This means they follow the freezes, provide source tarballs, need a present maintainer etc. The duties are described at [3]. The activity gets noted in release notes, possibly more attention by the localization teams as revenue. In the end their are downsides and upsides to be part of Fructose. There were some arguing, that only system dependent activities should be part of it (e.g. Browse with the dependency on hulahop). There were some discussions that we would loose the show case activities when an activity would not be part of Fructose anymore. This comes down to packaging, as for rpm packaging one needs to provide the source tarballs and need to follow certain rules. Some distributors may ship the .xo bunles at one point, otherwise probably won't, so it is a good habit to do the source releases. Anyhow, this is a bit of the background. Let's think how we can move forward on this topic. We should do it quickly, to be able to keep the work on 0.88 going. In my mind, the best thing we can do is making clear definition: 1) we have core with strong release cycle * glucose(and its dependencies) * sugar platform(additional dependencies) (core) 2) various sugar activities (the rest of development community) 3) sugar users (the rest of community) Relations between 1) and 2) totally depends on sugar release cycles. Activity developers decide what release cycles they can/should/will support. For activities like Browse it will several activities versions per SP release. Most activities will support several SP release. Relations between 2) and 3) is task for various deployment methods. Since fructose makes sense mostly for users, its content should totally depends on deployers not core. So I can't see the 4rd place for fructose, only as a part of 2). So far, I conclude, that Fructose as we have it today is outdated. The tarball issue could be solved with adding for example a field to ASLO, to be able to upload a tarball too, when doing a release. As I think where to upload a tarball was one big issue back in the days. The packaging (rpm, xo, deb) and how you install/upgrade, where you install (system vs user space) is then up to the deployer. As the tarball is available, that should work out nicely. Activities that rest coupled to the Sucrose release would be Browse and Etoys as they have strong platform dependencies. I think hulahop is more mature now and won't change as much in the future. Also Python allows us to do lots of tricks to keep backwards compatibility, but it all takes time developing and testing. Browse may be now in the same situation as Read. I don't think the problem is that Browse depends too much in hulahop, but that the only help the maintainer has with regard to this issue is when people complaint that the last released Browse is not working in the release they are running. With some more manpower I think we could surmount these issues. Regards, Tomeu Of course, activity authors are encouraged to follow the Sucrose release cycle, the point is: they don't have to. As Walter stated there is some benefit. Keeps you focused etc. More thoughts? Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] .swf files visualization and bundling
On Tue, Nov 24, 2009 at 11:02, Wade Brainerd wad...@gmail.com wrote: Good question - the SWF author would have to manually add support for sharing to the activity. I believe Gnash has DBus bindings, so that might be a possibility. If there is interested by at least one SWF author, I could add support in the SWF framework for collaboration. The DBus plugin is just a stub for now and I think it would take lots of work to get it working. What I would suggest instead is a plugin that provided a simple API for collaboration. I have done some experiments in this area and will be happy to share my experience. Regards, Tomeu Unless, Sugar had some sort of automatic collaboration, using VNC or the like, which didn't require custom programming in each activity, -Wade On Mon, Nov 23, 2009 at 11:08 PM, roshan karki ros...@olenepal.org wrote: nice, work. I can see that the activity can be shared as well. But unlike other shared activities I can't see any relation between two shared Cabeza activity. Though shared both activity are playing independently. Is it intentional ? What kind of work needs to be done so that a swf based activity can also be shared like 'write' activity ? On Tue, Nov 24, 2009 at 4:10 AM, Rafael Enrique Ortiz Guerrero raf...@sugarlabs.org wrote: Hi Wadeb and Tim Thanks for the suggestions. I followed eatboom skeleton and i got a working initial activity. http://people.sugarlabs.org/rafael/Cabeza.activity.xo obvioulsy i borrowed eatbom.svg (this mail is only for reporting the advance :)) Great work Wade!. Rafael Ortiz On Sun, Nov 22, 2009 at 7:44 AM, Wade Brainerd wad...@gmail.com wrote: Hey Rafael, Check out http://git.sugarlabs.org/projects/eatboom/repos/wadebs-clone. That project provides a template for making .SWF files into proper Sugar activities. The bundle is also available on ASLO here: http://activities.sugarlabs.org/en-US/sugar/addon/4225 EatBoom is pretty simplistic, but I'm working on porting a more advanced example. Let me know if you need any assistance with this. -Wade On Sun, Nov 22, 2009 at 2:11 AM, Rafael Enrique Ortiz Guerrero raf...@sugarlabs.org wrote: Hi. I have some educational content .swf files that i wish to visualize inside Sugar and also making a content bundle for them. What is the present way of doing so (both making the bundle and visualizing .swf files) ?, we have not talked in a while about content bundles at least that i remember ;), so please direct me to past conversations or links about it. Cheers and thanks in advance for your help. Rafael Ortiz ___ 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 Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Record rewrite -- was Re: [SoaS] SoaS v2 approaching RC state
On Thu, Nov 26, 2009 at 14:41, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Nov 25, 2009 at 12:25:12AM +, Aleksey Lim wrote: On Tue, Nov 24, 2009 at 11:51:55PM +, Peter Robinson wrote: On Tue, Nov 24, 2009 at 9:13 PM, Sebastian Dziallas sebast...@when.com wrote: Hi all, with the next SoaS release coming up really soon (final image is supposed to be composed this weekend, release date is Dec 8), there's a new snapshot ready for you. It includes a lot of fixes and smaller adjustments. It's currently only available as a general .iso build, others will presumably follow later. You can get it from here: http://download.sugarlabs.org/soas/snapshots/2/soas06.iso Let us know how it goes and help us debugging and fixing the remaining bugs here: https://bugs.launchpad.net/soas/+bugs A last note, if anybody knows what's wrong with Record, Cairo and F12, Who is the maintainer of Record? It would be a pity to ship BB without that working as its one off the Activities that kids seem to love. What's the issue with Cairo? last time /me patched Record.. and looks like it doesn't work in 0.86 for a long time, so its the right moment to fix 0.86 issues then Sorry, I'm a bit stuck with it, my plans were to rewrite Record-65 and make lightweight Record: * w/o collaboration feature as it was designed in existed Record * it just share records, I'm planing to do the same on Journal level * it just doesn't work well(especially for big files) * w/o gtk.Windows that represent Record's controls, only widgets * using more robust gst scheme I decide to use camerabin[1] gst plugin which is a good option for Record but it doesn't work(stop w/ gst errors on recording) any help from people who are aware of such gst and video recording stuff is appreciated. [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/gst-plugins-bad-plugins-camerabin.html Maybe Daniel Siegel of Cheese fame can give some insight on that? Added him to CC Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] development team meeting thursday at 14.00 UTC
And here are the logs: http://meeting.sugarlabs.org/sugar-meeting.minutes.20091126_0919.html http://meeting.sugarlabs.org/sugar-meeting.log.20091126_0919.html Regards, Tomeu On Thu, Nov 26, 2009 at 09:15, Simon Schampijer si...@schampijer.de wrote: On 11/24/2009 06:27 PM, Tomeu Vizoso wrote: Hi, the development team is going to meet next thursday to discuss this particular moment in the 0.88 release cycle, please add topics here: http://wiki.sugarlabs.org/go/Development_Team/Meetings#Upcoming_Meetings See you then, Tomeu Developers, interested in 0.88 please join in. What we will have a look at is our roadmap and the feature process. If you have questions about it - best is to ask now! http://wiki.sugarlabs.org/go/0.88/Roadmap#Schedule http://wiki.sugarlabs.org/go/Features/Policy Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
