[Sugar-devel] Tablet support
Hi all, Chris Marshall, Ping Cheng (of Wacom) and myself have started work on a project to add graphics tablet (such as Wacom Bamboo) to Sugar. Our goal is to submit patches over the next six months adding a wacom driver, a control panel extension, and activity support to Sugar. We're targeting both XO and XO 1.5, currently planning to support 10.1.3 and future builds. Progress reports will be posted to the project wiki page at http://wiki.laptop.org/go/Projects/Tablet_Support. Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Colors! Activity status
Looks like I tagged v16 in Git last January, but somehow it never made it to ASLO. I'll take care of that now!! On Sat, Dec 25, 2010 at 9:54 AM, chm devel.chm...@gmail.com wrote: I just tried Colors-13.xo (from the OLPC site) but it failed to load because it could not find python2.5 libraries. I'm not surprised at that, just hoping Merry Christmas, Chris On 12/25/2010 9:21 AM, chm wrote: On 12/23/2010 6:41 PM, Wade Brainerd wrote: Yikes, can you tell me what isn't there? ... Just to check, does your version have a Help button in the toolbar? That would indicate that it's the most recent one that I made. I just checked and the Colors-15 I have has neither the Help button or the Eraser (in addition to the missing videopaint---which was never working before either). I'll try to fetch the activity again in case there was some mixup. Is there a way to check out the latest release from git? Thanks, Chris ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Colors! Activity status
Hey Chris, On Wed, Dec 22, 2010 at 10:13 PM, chm devel.chm...@gmail.com wrote: I've built a wacom tablet kernel driver for 10.1.3beta and have been able to run Colors! with a Wacom Bamboo Fun tablet. This was the first time since leaving os802 on the XO-1. Yippee! Wonderful! I wonder if OLPC would be up for including your module in future distributions by default. Wacom Bamboo tablets are easily within reach of most school budgets and add to the experience of many activities, not just Colors!. I notice some problems with a solid, full-pressure/full-size dot at the beginning of a stroke. That was fixed previously by some of the tablet driver settings but I don't recall the details. I believe I tried to work around this in the Colors! code at some point too. We were getting some extraneous mouse signals with no pressure data, which Colors! interprets as full pressure. Also, I used the Copy widget to save a drawing to the clipboard and thence to the Journal. Unfortunately, I could not figure out how to save the playable version of the drawing to the Journal. Just stop the activity, the Journal entry for the activity contains the strokes. Or did you want the .drw file to say, upload to the Colors! gallery? Finally, I downloaded the git sources from the gitorious and I think I'll be able to figure out how to get more of the wacom tablet features available. Specifically, the Bamboo has a Ring that could be used to dial for the color selector. There are a number of other buttons as well that could be used to reduce/eliminate the need to go to the XO keyboard while drawing. It would be cool if one could draw while in e-book mode for the XO-1. That would be awesome - I'd love to see the hue / saturation / value assigned to those. My tablet only has linear sliders. I wonder how the mapping should work? If you'd like to collaborate on this, I have a couple weeks off after the Holidays and am hoping to get some activity work done. Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wacom Bamboo with Colors! on XO-1 (again)?
Good question, I'll have to do some research on the status of wacom support in F11. The supporting utilities are definitely installable via yum, so maybe the kernel module and xorg configuration have been done too. Thanks for the reports! -Wade On Sun, Dec 19, 2010 at 11:42 AM, chm devel.chm...@gmail.com wrote: I tried the updated script with the following log of the session. The two issues appear to be that the wacom.ko won't work with a different linux kernel version (not too surprising) and that the Xorg configuration stuff has changed from the fedora-9 to fedora-11 change. I was wondering if since fedora-11 is more recent if there might be a package to install the needed module/driver directly with yum rather than having to build a custom kernel. I took a look at the Xorg stuff and it was enough different that I was not sure where to begin. --Chris --2010-12-19 16:21:20-- http://dev.laptop.org/~wadeb/wacom.kohttp://dev.laptop.org/%7Ewadeb/wacom.ko Resolving dev.laptop.org... 18.85.2.147 Connecting to dev.laptop.org|18.85.2.147|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 214387 (209K) [text/plain] Saving to: “/lib/modules/2.6.31_xo1-20101119.1249.1.olpc.3781c4e5eac361a/kernel/drivers/usb/input/wacom.ko†100%[===] 214,387 188K/s in 1.1s 2010-12-19 16:21:21 (188 KB/s) - “/lib/modules/2.6.31_xo1-20101119.1249.1.olpc.3781c4e5eac361a/kernel/drivers/usb/input/wacom.ko†saved [214387/214387] Copying Xorg configuration file... --2010-12-19 16:21:21-- http://dev.laptop.org/~wadeb/xorg-dcon.confhttp://dev.laptop.org/%7Ewadeb/xorg-dcon.conf Resolving dev.laptop.org... 18.85.2.147 Connecting to dev.laptop.org|18.85.2.147|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3544 (3.5K) [text/plain] Saving to: “/etc/X11/xorg-dcon.conf†100%[===] 3,544 --.-K/s in 0.002s 2010-12-19 16:21:21 (1.35 MB/s) - “/etc/X11/xorg-dcon.conf†saved [3544/3544] Building kernel module dependenies... WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. FATAL: Error inserting wacom (/lib/modules/2.6.31_xo1-20101119.1249.1.olpc.3781c4e5eac361a/kernel/drivers/usb/input/wacom.ko): Invalid module format Wacom installation complete! Please restart your XO. On 12/17/2010 10:26 AM, Wade Brainerd wrote: Hey Chris, Two things are going wrong: 1) You need internet connectivity to run that script. It downloads the kernel module from dev.laptop.org http://dev.laptop.org. 2) The script referenced a copy of the wacom.ko from Paul Firth's home directory, but it's not there any more. I updated the script to reference a copy in my home directory. So, please grab the updated script and try again: http://dev.laptop.org/~wadeb/setupwacom.shhttp://dev.laptop.org/%7Ewadeb/setupwacom.sh I'm hoping that the kernel module will be compatible. If not, we may need to build it from source for os852. Best, Wade On Thu, Dec 16, 2010 at 10:25 PM, Chris Marshall c...@alum.mit.edumailto: c...@alum.mit.edu wrote: Here it is...it seems like the current script fetches the old wacom.ko. I'm not sure a kernel module would work across different versions of the kernel. --Chris Copying and installing Wacom kernel module... --2010-12-16 23:33:47-- http://dev.laptop.org/~pgf/wacom.kohttp://dev.laptop.org/%7Epgf/wacom.ko Resolving dev.laptop.org... failed: Temporary failure in name resolution. wget: unable to resolve host address “dev.laptop.org http://dev.laptop.org” Copying Xorg configuration file... --2010-12-16 23:33:47-- http://dev.laptop.org/~wadeb/xorg-dcon.confhttp://dev.laptop.org/%7Ewadeb/xorg-dcon.conf Resolving dev.laptop.org... failed: Temporary failure in name resolution. wget: unable to resolve host address “dev.laptop.org http://dev.laptop.org” Building kernel module dependenies... WARNING: Module /lib/modules/2.6.31_xo1-20101119.1249.1.olpc.3781c4e5eac361a/kernel/drivers/usb/input/wacom.ko is not an elf object WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. FATAL: Module wacom not found. Wacom installation complete! Please restart your XO. On 12/6/2010 5:16 PM, Wade Brainerd wrote: Hey Chris, I just saw this email. Can you tell me what the error message you got was? I haven't installed os852 on my XO-1 but I might be able to diagnose it by the error message. Thanks, Wade On Sun, Dec 5, 2010 at 5:10 PM, chm devel.chm...@gmail.commailto: devel.chm...@gmail.com mailto:devel.chm...@gmail.com mailto: devel.chm...@gmail.com wrote: I've been delighted to see the user-driven development for the XO-1 starting to pay
Re: [Sugar-devel] Wacom Bamboo with Colors! on XO-1 (again)?
Hey Chris, Two things are going wrong: 1) You need internet connectivity to run that script. It downloads the kernel module from dev.laptop.org. 2) The script referenced a copy of the wacom.ko from Paul Firth's home directory, but it's not there any more. I updated the script to reference a copy in my home directory. So, please grab the updated script and try again: http://dev.laptop.org/~wadeb/setupwacom.sh I'm hoping that the kernel module will be compatible. If not, we may need to build it from source for os852. Best, Wade On Thu, Dec 16, 2010 at 10:25 PM, Chris Marshall c...@alum.mit.edu wrote: Here it is...it seems like the current script fetches the old wacom.ko. I'm not sure a kernel module would work across different versions of the kernel. --Chris Copying and installing Wacom kernel module... --2010-12-16 23:33:47-- http://dev.laptop.org/~pgf/wacom.ko Resolving dev.laptop.org... failed: Temporary failure in name resolution. wget: unable to resolve host address “dev.laptop.org” Copying Xorg configuration file... --2010-12-16 23:33:47-- http://dev.laptop.org/~wadeb/xorg-dcon.conf Resolving dev.laptop.org... failed: Temporary failure in name resolution. wget: unable to resolve host address “dev.laptop.org” Building kernel module dependenies... WARNING: Module /lib/modules/2.6.31_xo1-20101119.1249.1.olpc.3781c4e5eac361a/kernel/drivers/usb/input/wacom.ko is not an elf object WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. FATAL: Module wacom not found. Wacom installation complete! Please restart your XO. On 12/6/2010 5:16 PM, Wade Brainerd wrote: Hey Chris, I just saw this email. Can you tell me what the error message you got was? I haven't installed os852 on my XO-1 but I might be able to diagnose it by the error message. Thanks, Wade On Sun, Dec 5, 2010 at 5:10 PM, chm devel.chm...@gmail.com mailto: devel.chm...@gmail.com wrote: I've been delighted to see the user-driven development for the XO-1 starting to pay off (e.g., now there is a unified XO-1 and XO-1.5 release). However, I have not been able to get the Wacom Bamboo tablet working with 10.1.2/xo-1 (a.k.a. os852). The previous install script doesn't work and I can't figure out what needs to change to get things to work. Any help would be appreciated since my nieces really liked the Colors! activity using the Wacom and have not been able to use it since the OS upgrade which is so much better that I thought the tradeoff was worth it. Thanks much, Chris ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wacom Bamboo with Colors! on XO-1 (again)?
Hey Chris, I just saw this email. Can you tell me what the error message you got was? I haven't installed os852 on my XO-1 but I might be able to diagnose it by the error message. Thanks, Wade On Sun, Dec 5, 2010 at 5:10 PM, chm devel.chm...@gmail.com wrote: I've been delighted to see the user-driven development for the XO-1 starting to pay off (e.g., now there is a unified XO-1 and XO-1.5 release). However, I have not been able to get the Wacom Bamboo tablet working with 10.1.2/xo-1 (a.k.a. os852). The previous install script doesn't work and I can't figure out what needs to change to get things to work. Any help would be appreciated since my nieces really liked the Colors! activity using the Wacom and have not been able to use it since the OS upgrade which is so much better that I thought the tradeoff was worth it. Thanks much, Chris ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Analysis help needed re: sugargame (pygame) on the 1.0XO (build 802)
Hi George, Turns out the get_window() method is indeed missing in that older PyGTK. Instead, there is a property called window. So just replace: self._socket.get_window() with: self._socket.window And it should work fine. I'll release a new version with this change. Thanks, Wade On Sat, Jun 26, 2010 at 4:27 PM, Wade Brainerd wad...@gmail.com wrote: Hi George, Thanks! I'll take a look at it this weekend to see if I can find a workaround for the missing API. Wade On Jun 26, 2010, at 12:02 PM, George Hunt georgejh...@gmail.com wrote: Hi Wade, Thanks for your offer. I've attached XoPhoto-2.xo. There is also a git repo at http://git.sugarlabs.org/projects/xophoto/repos/mainline http://git.sugarlabs.org/projects/xophoto/repos/mainline if that is more convenient. On my test machine, I reflashed to build 802. For some reason, I had trouble getting the journal to recognize my USB stick. So I copied /media/KINGSTON/XoPhoto-2.xo to /home/olpc/Activities, and then unzipped it. I found that if I commented out line 50 of XoPhoto.activity/sugargame/canvas.py, my application would come up successfully. Tomeo's hypothesis is that gtk. 2.14.2 (or pygtk) doesn't include _socket.get_window(). Without the ability to set the pygame cursor to None, as you will see, I'm not able to use the gtk cursor resources. I've tried a few things unsuccessfully to try to get a reference to the pygame window. I'd appreciate any ideas you might have George On Fri, Jun 25, 2010 at 10:39 PM, Wade Brainerd wad...@gmail.com wad...@gmail.com wrote: Hi George, Can you send me a copy of your activity? I'll try it out on my XO (also running 802) and see what's wrong. Thanks, Wade On Tue, Jun 15, 2010 at 9:40 PM, George Hunt georgejh...@gmail.com georgejh...@gmail.com wrote: To: sugar-devel@lists.sugarlabs.orgsugar-devel@lists.sugarlabs.org Date: Sun, 6 Jun 2010 16:20:05 -0400 Subject: Analysis help needed re: sugargame (pygame) on the 1.0XO (build 802) Hi everyone, I've been developing a thumbnail slide sorting activity using pygame on my 1.5XO. I've been happy with the ease of laying out the screen using pygame. Now I'm checking it out on the 1.0, and having perplexing difficulty. My guess is that it's something that I'm doing, because the test activity distributed with sugargame, and the Demoiselle demo program developed by Jim Simmons also fail in the same manner. (but I've redownloaded build 802, and reflashed my test machine, and also brought down the most recent git of sugargame) As I understand it, Sugargame puts a gtk.socket into an eventbox, and the event box is loaded into the XO's VBox by the sugar.graphics.window.set_canvas function -- which is a super of sugar.activity.activity. In sugargame/canvas.py line 41 self._socket.get_window().set_cursor(None) AttributeError: 'gtk.Socket' object has no attribute 'get_window' This is after an environment variable SDL_WINDOWID has been passed to the pygame.init() routine, (I guess pygame uses this ID to create the gtk.Plug(). What works on the 1.5 (test.activity, and demoiselle.activity, and my application) gtk.ver = 2.16.1 pygame.ver = 1.8.1 What doesn't work on 1.0XO build 802: (all three of these fail with the above AttributeError) gtk.ver = 2.14.2 pygame.ver = 1.8.0 I looked into putting the pygame 1.9.1 on Build 802, but there were dependencies more than just SDL-devel, and I've still got the nagging feeling that I'm missing something simple (the test.activity was probably tested on build 802) Any insight, advice would be appreciated, George ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.orgSugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel http://lists.sugarlabs.org/listinfo/sugar-devel XoPhoto-2.xo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Sugargame v1.1
== Sugargame == Sugargame is a Python package which allows [http://www.pygame.org/ Pygame] programs to run well under Sugar. It is fork of the olcpgames framework, which is no longer maintained. http://wiki.sugarlabs.org/go/Development_Team/Sugargame http://git.sugarlabs.org/projects/sugargame Sugargame v1.1 is a bug fix release: * Fix bugs in event handling. (Pablo Moleri) * Remove reference to gtk.Socket.get_window() method, which is missing in older versions of PyGTK. See the Wiki page for usage information and examples. Best, -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Analysis help needed re: sugargame (pygame) on the 1.0XO (build 802)
Hi George, Can you send me a copy of your activity? I'll try it out on my XO (also running 802) and see what's wrong. Thanks, Wade On Tue, Jun 15, 2010 at 9:40 PM, George Hunt georgejh...@gmail.com wrote: To: sugar-devel@lists.sugarlabs.org Date: Sun, 6 Jun 2010 16:20:05 -0400 Subject: Analysis help needed re: sugargame (pygame) on the 1.0XO (build 802) Hi everyone, I've been developing a thumbnail slide sorting activity using pygame on my 1.5XO. I've been happy with the ease of laying out the screen using pygame. Now I'm checking it out on the 1.0, and having perplexing difficulty. My guess is that it's something that I'm doing, because the test activity distributed with sugargame, and the Demoiselle demo program developed by Jim Simmons also fail in the same manner. (but I've redownloaded build 802, and reflashed my test machine, and also brought down the most recent git of sugargame) As I understand it, Sugargame puts a gtk.socket into an eventbox, and the event box is loaded into the XO's VBox by the sugar.graphics.window.set_canvas function -- which is a super of sugar.activity.activity. In sugargame/canvas.py line 41 self._socket.get_window().set_cursor(None) AttributeError: 'gtk.Socket' object has no attribute 'get_window' This is after an environment variable SDL_WINDOWID has been passed to the pygame.init() routine, (I guess pygame uses this ID to create the gtk.Plug(). What works on the 1.5 (test.activity, and demoiselle.activity, and my application) gtk.ver = 2.16.1 pygame.ver = 1.8.1 What doesn't work on 1.0XO build 802: (all three of these fail with the above AttributeError) gtk.ver = 2.14.2 pygame.ver = 1.8.0 I looked into putting the pygame 1.9.1 on Build 802, but there were dependencies more than just SDL-devel, and I've still got the nagging feeling that I'm missing something simple (the test.activity was probably tested on build 802) Any insight, advice would be appreciated, George ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to start the Browse activity from my own activity?
On Tue, Feb 2, 2010 at 5:55 PM, James Cameron qu...@laptop.org wrote: On Tue, Feb 02, 2010 at 09:59:12AM +0100, Tomeu Vizoso wrote: On Mon, Feb 1, 2010 at 23:30, James Cameron qu...@laptop.org wrote: I've just tested; one can open Wikipedia activity, type google.com into the location text field, and then start a Browse activity from the activity ring ... result, two active web browsers. ?A feature! ?;-) For the record, Wikibrowse *extends* Browse. It starts up a local webserver which serves pages from a compressed wikitext database, and then instantiates a customized Browse activity. I'm glad Chris jumped in and took credit for the /home/olpc thing, I didn't think I had left it like that ;) Also, it would be great if the Browse source code were available to other activities without hacks like this. I look forward to Sugar Services providing this functionality in a clean manner! Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Development
On Fri, Jan 22, 2010 at 6:45 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Fri, Jan 22, 2010 at 03:42:14PM -0500, Francis Xavier Fitzpatrick wrote: I was just curious as to what set up you all use to develop applications on Sugar? I use Gentoo sugar overlay which has useful feature, USE flag source so, the whole sugar in /usr are symlinked to ~/src and I can at any time change sugar sources, switch betwean sugar releases w/o building/reinstalling sugar. Also I use wmii+screen+mc+vim to do coding stuff. I would like to see a screencast of Aleksey working sometime. Maybe next time you decide to start on a new bug or small feature, you would record the process?? It still boggles me how you can get stuff done so quickly! :) -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Deployments on the wiki
I've started pinging deployments about this; any help will be greatly appreciated. On Tue, Jan 19, 2010 at 4:47 PM, Simon Schampijer si...@schampijer.de wrote: On 01/18/2010 12:11 AM, Wade Brainerd wrote: On Sun, Jan 17, 2010 at 5:09 PM, Simon Schampijersi...@schampijer.de wrote: On 01/17/2010 11:05 PM, Wade Brainerd wrote: I think we ought to have a Template and structure for deployments, along the lines of the Feature wiki pages [1]. Then we could ask each deployment to create new pages under [[Deployments/]]. Would anyone mind if I created [[Deployments/Deployment_Template]] and a [[Deployments/...]] category? Wade [1] - http://wiki.sugarlabs.org/go/Features/Feature_Template If we do not have something like that yet - I think it would be a very good thing to setup. And yes, a template like the Feature one would help to structure that information. Thanks, Simon Okay, I took a stab at this. I'm not much for writing long descriptions, so any help with fleshing out [1] and [2] is greatly appreciated. Also, any suggestions for new / tweaked template fields are also welcome. Gerald Simon, would you mind adding your deployments as the first ones under http://wiki.sugarlabs.org/go/Deployments? Best, Wade [1] http://wiki.sugarlabs.org/go/Deployments [2] http://wiki.sugarlabs.org/go/Deployments/Policy Awesome, thanks Wade! I gave it a shot and added the Planetarium deplyoyment [1]. I cleaned a few appearances of the word 'Feature' in the deployment template ;p Regards, Simon [1] http://wiki.sugarlabs.org/go/Deployments/Planetarium ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Development
Hi Francis, I currently develop activities using sugar-jhbuild running under Fedora 11, inside a VirtualBox VM on an iMac. I use Eclipse + PyDev for the actual coding. When developing on XO, I use Komodo Edit with the Remote Drive Tree extension to edit files directly on the XO over ssh. I also use VIM for quick edits. Recommendation: Find a high quality development environment that you are comfortable and efficient in, and stick with it. There's nothing like a poor development environment to kill coding productivity. -Wade On Fri, Jan 22, 2010 at 5:01 PM, Gary C Martin g...@garycmartin.com wrote: On 22 Jan 2010, at 20:42, Francis Xavier Fitzpatrick wrote: I was just curious as to what set up you all use to develop applications on Sugar? For me it's a combination of: 1) Mac OS X running a VM of Fedora + sugar-jhbuild or (currently) a Blueberry image 2) Sugar on physical XO-1s ...and for coding: 1) Xcode (when pythoning on a Mac) 2) vim (when pythoning on an XO or VM) Using git for version control. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Low-level Activity API
Hi Bert, Thanks for doing this! Once place you can link it from is http://wiki.sugarlabs.org/go/Activity_Team/Resources. Best, Wade On Wed, Jan 20, 2010 at 6:28 AM, Bert Freudenberg b...@freudenbergs.de wrote: Hi folks, I just moved the documentation for how to write Sugar Activities in languages other than Python from the OLPC wiki to the Sugar Labs wiki: http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API I need help though - there are quite a few broken links. For most of them I guess there is an equivalent page on the new wiki. It would be great if someone could find these and adjust the references. Here is the version on the OLPC wiki this is based on: http://wiki.laptop.org/index.php?title=Low-level_Activity_APIoldid=219699 Also, I guess this should be linked from the Almanac but I wasn't sure where to put it. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] 'Resume' vs 'Start a new' Activity
On Sun, Jan 17, 2010 at 5:30 AM, Simon Schampijer si...@schampijer.de wrote: In yesterday's design meeting [1] we discussed this issue. The outcome was the following (full logs can be found at [2]): Hi Simon, Good job proving me wrong and achieving a reasonable consensus :) I support the design team's conclusion. It restores the distinction between activity and activity instance, and is not too disruptive. Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Mockups of Home view showing Start new ring and separate row of icons for resume
On Sun, Jan 17, 2010 at 5:09 PM, Simon Schampijer si...@schampijer.de wrote: On 01/17/2010 11:05 PM, Wade Brainerd wrote: I think we ought to have a Template and structure for deployments, along the lines of the Feature wiki pages [1]. Then we could ask each deployment to create new pages under [[Deployments/]]. Would anyone mind if I created [[Deployments/Deployment_Template]] and a [[Deployments/...]] category? Wade [1] - http://wiki.sugarlabs.org/go/Features/Feature_Template If we do not have something like that yet - I think it would be a very good thing to setup. And yes, a template like the Feature one would help to structure that information. Thanks, Simon Okay, I took a stab at this. I'm not much for writing long descriptions, so any help with fleshing out [1] and [2] is greatly appreciated. Also, any suggestions for new / tweaked template fields are also welcome. Gerald Simon, would you mind adding your deployments as the first ones under http://wiki.sugarlabs.org/go/Deployments? Best, Wade [1] http://wiki.sugarlabs.org/go/Deployments [2] http://wiki.sugarlabs.org/go/Deployments/Policy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FileShare Activity 7
Hi Justin,
I've been meaning to check out this activity for awhile. It looks
great! And I am starting to believe in enabling more functionality
like this through activities rather than adding them into the shell.
Things seem to happen a lot faster that way at least!
I downloaded v7 from ASLO on SoaS Blueberry tonight to test it out. I
got this exception when trying to add the fileshare-7.xo bundle from
the Journal.
** (sugar-activity:1811): DEBUG: Got client ID
103037e31b109a267c1263691692431510008980010
** (sugar-activity:1811): DEBUG: Setting initial properties
1263691692.144747 WARNING root: No gtk.AccelGroup in the top level window.
1263691692.151700 WARNING root: No gtk.AccelGroup in the top level window.
/usr/lib/python2.6/site-packages/sugar/graphics/window.py:290:
DeprecationWarning: use toolbar_box instead of toolbox
warnings.warn('use toolbar_box instead of toolbox', DeprecationWarning)
** (sugar-activity:1811): DEBUG: Received SaveYourself(SmSaveLocal,
!Shutdown, SmInteractStyleNone, !Fast) in state idle
** (sugar-activity:1811): DEBUG: Sending SaveYourselfDone(True) for
initial SaveYourself
** (sugar-activity:1811): DEBUG: Received SaveComplete message in
state save-yourself-done
/usr/lib/python2.6/site-packages/dbus/connection.py:242:
DeprecationWarning: object.__init__() takes no parameters
super(Connection, self).__init__(*args, **kwargs)
Traceback (most recent call last):
File /home/liveuser/Activities/FileShare.activity/GuiView.py, line
47, in requestAddFile
file_obj = self.activity.build_file( jobject )
File /home/liveuser/Activities/FileShare.activity/FileShareActivity.py,
line 267, in build_file
journalentrybundle.from_jobject(jobject, bundle_path )
File /home/liveuser/Activities/FileShare.activity/journalentrybundle.py,
line 49, in from_jobject
b.set_metadata(jobject.get_metadata())
File /home/liveuser/Activities/FileShare.activity/journalentrybundle.py,
line 167, in set_metadata
self.set_entry_id(entry_id)
File /home/liveuser/Activities/FileShare.activity/journalentrybundle.py,
line 85, in set_entry_id
zip_file = zipfile.ZipFile(self._path,'a')
File /usr/lib/python2.6/zipfile.py, line 698, in __init__
self._RealGetContents()
File /usr/lib/python2.6/zipfile.py, line 723, in _RealGetContents
endrec = _EndRecData(fp)
File /usr/lib/python2.6/zipfile.py, line 201, in _EndRecData
return _EndRecData64(fpin, -sizeEndCentDir, endrec)
File /usr/lib/python2.6/zipfile.py, line 147, in _EndRecData64
fpin.seek(offset - sizeEndCentDir64Locator, 2)
IOError: [Errno 22] Invalid argument
1263693756.355801 WARNING root: No gtk.AccelGroup in the top level window.
1263693757.626212 WARNING root: No gtk.AccelGroup in the top level window.
1263693757.636758 WARNING root: No gtk.AccelGroup in the top level window.
1263693757.638275 WARNING root: No gtk.AccelGroup in the top level window.
1263693757.705847 WARNING root: DSObject was deleted without cleaning
up first. Call DSObject.destroy() before disposing it.
Activity died: pid 1811 condition 0 data (None, open file 'fdopen',
mode 'w' at 0xa169200)
Also, the spinny status indicator looks a little odd on SoaS - might
be a resolution issue or something.
Best,
Wade
On Tue, Jan 12, 2010 at 6:23 PM, Justin Lewis jtl1...@rit.edu wrote:
FileShare is an activity that allows the user to share files from
their journal to other xo's or to a central server.
Activity Homepage:
http://activities.sugarlabs.org/en-US/sugar/addon/4266
Sugar Platform:
0.82 - 0.86
Release notes:
Improved gui response.
* Gui is now dispatching threads for long blocking calls.
* Throbber is shown while gui is running a blocking call.
Improved server interaction when in Server Mode
* Basic permission system
* Admin view to change user permissions
* Fixed hang (added 10 second timeout) when server is set but offline
Fixed Keep Error bug with empty file list
Other Notes:
This project has not undergone any extensive testing, so please feel
free to send feedback and bug reports.
Justin Lewis
http://people.rit.edu/~jtl1728
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Toolkit in Vala
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? -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SOAS 2 problems
Hi David, Did you try adding 'selinux=0' to the kernel boot parameters? SoaS Blueberry expects selinux to be disabled, so it sounds like the image you're using was created incorrectly. 1. When first booting, press a key when it prompts you to. 2. You should see a 'GNU GRUB' screen. Press the e key. 3. Press the down arrow once to highlight the kernel line. 4. Press the e key. 5. Press the End key, then type selinux=0 without the quotes. That is, spaceselinuxequals0. 6. Press enter. 7. Press the b key. 8. The system should now boot. -Wade On Mon, Jan 11, 2010 at 12:21 AM, 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-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
My feeling regarding all this is that the problem is deeper than finding a way to Resume Latest or Start New from the home screen. IMO, the whole idea of Resume Latest is broken and needs to be ditched. The Journal is the place to resume activities. We need to make the Journal more discoverable and usable instead of trying to mash its features into the home screen. But, I don't think there is any way to achieve consensus on this issue. In fact, the need for consensus feels like a constant problem in the advancement of the Sugar shell. I eagerly await someone in charge making a good decision. :) Best, Wade ___ 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 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. -Wade ___ 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 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. Best, Wade ___ 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
n Fri, Jan 8, 2010 at 5:30 AM, 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! Hi Gerald, Can I find more information about your deployment somewhere? Best, -Wade ___ 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
Walther, It's great to hear that people are doing the combined developer - teacher - student approach. It was just a rhetorical idea so it's awesome to see it occurring in practice :) ReckonPrimer looks quite cool btw. I especially like how the development has been tied to pedagogical efforts. Do you think it will be stable enough to post on activities.sugarlabs.org soon? Best regards, Wade 2010/1/8 Walther Neuper neu...@ist.tugraz.at: 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. 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
Re: [Sugar-devel] [IAEP] Mockup for collab.sugarlabs.org
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
Re: [Sugar-devel] Several chapters of Make Your Own Sugar Activities! ready for review, feedback
Hi Jim, Just wanted to say, this looks awesome! I love the overall writing style, the scattered pearls of wisdom and bits of humor, and the extensive use of screenshots. I'll try to provide some more detailed comments soon. Great work! -Wade On Tue, Jan 5, 2010 at 2:57 PM, Jim Simmons nices...@gmail.com wrote: I've been working on a Floss Manual that should be a beginner's guide to creating Sugar Activities. I've got 64 page's worth (in the PDF version) written and I feel confident that I will finish this book eventually. What I have now may be good enough to criticize. It contains some pretty good code samples, some reasonable recommendations, and a fair number of screen shots. So far it covers writing a basic Activity in Python, running it with sugar-emulator, and getting the code in Git. Future chapters will include doing i18n with Pootle, distributing the Activity, doing text to speech with and without highlighting, and collaboration features. I may stick something on Activity debugging techniques in somewhere too. Other stuff that *should* be included, but which I am not currently qualified to write, would include: * Developing Activities on a Mac * Creating an Activity using PyGame instead of PyGTK. * Creating the new-styled toolbars * etc., etc. If you want to check out what I have the URL is: http://en.flossmanuals.net/ActivitiesGuideSugar/Introduction Any help anyone can provide on this will be greatly appreciated. If you want to register as a writer and contribute stuff of your own or edit my stuff you have my blessing. Thanks, James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Sugar Services
Happy New Year!
Can we bundle some 0install sources (blobs) in the .xo file? Like,
for Colors! could I bundle the {py25,py26}_{x86,x64} 0install sources
in the .xo file and specify a local path when starting up?
Thus, remote 0install is only invoked in a less common scenario, where
the user is more likely to have a net connection anyway.
Though, the Browse extension sounds neat.
-Wade
On Mon, Jan 4, 2010 at 4:36 AM, Aleksey Lim alsr...@member.fsf.org wrote:
As was predicted, there could be issue w/ downloading new activities from
ASLO and first launch them w/o net(see http://bugs.sugarlabs.org/ticket/1641)
looks like it could be fixed w/o implementing offline mode in shell(thus only
in last sugar) but just in Browse.
I'm going to implement such fix for 0.82+ Browses. This fix will let
users follow regular workflow i.e. get full activity .xo after
downloading from ASLO but after implementing [6] in shell and switching
to online mode users will download pure .xo and reuse already
downloaded 0install dependencies.
[6] http://wiki.sugarlabs.org/go/Features/Zero_Install_integration
On Sun, Jan 03, 2010 at 06:12:01PM +, Aleksey Lim wrote:
Happy New Year to all,
http://wiki.sugarlabs.org/go/Activity_Team/Services
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
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] g.sl.o issues for Karma and perhaps other activities
How badly do you need a user friendly repository creator like Gitorious? If it's not important, you can just use GitWeb which is trivial to set up. I guess the important thing to consider is that Git can handle distributing and merging *code* changes across as many servers as you want. But if you want the metadata like project descriptions updated, you'll have to setup cron or a manual process like that. Honestly, 60 projects doesn't sound like too much work to set up by hand on both servers, compared with the amount of work to actually develop the lessons... Setting up a project on g.sl.o only takes a minute or so. -Wade On Sat, Jan 2, 2010 at 10:00 AM, Tomeu Vizoso to...@sugarlabs.org wrote: 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
Re: [Sugar-devel] malformed OurMusic bundle
What editor do you use to edit source code? I do lots of development on Windows too, but haven't had this problem. -Wade On Sat, Jan 2, 2010 at 2:54 PM, Art Hunkins abhun...@uncg.edu wrote: Mikus suggested the following to me (re: my OurMusic activities and Windows line-endings): - Original Message - From: Mikus Grinbergs mi...@bga.com To: Art Hunkins abhun...@uncg.edu Cc: Testing test...@lists.laptop.org Sent: Tuesday, December 29, 2009 11:13 PM The other is a personal dislike. Various files in this bundle have Windows line-endings. I'm running Linux on my XO (that's a Fedora-based build), and have the 'python-psyco' accelerator installed. In the past, I've seen my system's python execution fail when the python files in an Activity did not have Linux line-endings. mikus I use Windows to do most of my text editing, and my question is: how much of an issue is this for you Linux people? If it is, could you suggest a simple conversion utility, that changes Windows to Linux line endings? Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] g.sl.o issues for Karma and perhaps other activities
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. 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. 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
Re: [Sugar-devel] Fedora Sugar Meeting Minutes 31/12/2009
Hi Sebastian, I'm concerned that you guys are planning to require activity authors to package their activities in Fedora, in order to see them shipped in SoaS. Is this the case? Currently SoaS pulls a predefined list of activities from ASLO. I think requiring Fedora packaging would be too much extra work activity authors. If you look at the packaged versions on download.sugarlabs.org, many are out of date from their ASLO equivalents. Also, will you still allow packages from rpmfusion? These are currently required to make VirtualBox Guest Additions work. Best, Wade On Thu, Dec 31, 2009 at 11:30 AM, Sebastian Dziallas sebast...@when.com wrote: This is it. First meeting after some time, quite some folks joined. Thanks to all those who dropped by! Here are the minutes and logs: http://meeting.olpcorps.net/fedora-olpc/fedora-olpc.minutes.20091231_1013.html http://meeting.olpcorps.net/fedora-olpc/fedora-olpc.log.20091231_1013.html Next date is the Sugar Packaging Session on Jan 6, 1500 UTC [1] - if you're interested in learning how to package, join us! --Sebastian [1] https://fedoraproject.org/wiki/Classroom#Upcoming_Classes ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Religious/Spiritual Text
Hi Art, Personally, I would find it appropriate and sufficient if you added a note about the religious content to the OurMusic and OurMusicMC activity descriptions at activities.sugarlabs.org. I was one of the ones who (privately) flagged your activities as a possible issue for SugarLabs, and I then advocated that we develop some kind of editorial standards for activity hosting on activities.sugarlabs.org. Like Edward says, we have activities which include religious or spiritual content and there is nothing wrong with that. The imperative is that it be labeled appropriately and not forcibly or subversively distributed. Best, -Wade On Thu, Dec 17, 2009 at 12:45 PM, Art Hunkins abhun...@uncg.edu wrote: It has recently been suggested to me that the religious/spiritual text in my OurMusic and OurMusicMC activities may not be well received by some, and that the text may hinder chances for deployment and even potentially cause individuals (or Sugar Labs) trouble. Needless to say, I'd like to avoid these eventualities if at all possible. (For perspective on the relevence of this text to me, please see my list of Recent Compositions at www.arthunkins.com. These activities are the final manifestations of a long-term project.) The current text is: A Creation Story: On the sixth day I was created. God said I was very good. On the sixth day We were created - my friends and I. God said We were very good. On the sixth day my Family was created - my loved ones and I, together with all the other creatures. God said my Family was very good. God saw that everything He made was very good. He was so pleased He decided to take a holiday, and joined us in play. A possible alternative text (equivalent, and equally acceptable to me - but expressed in more universal language): One day long ago I was created. Spirit was delighted with me. One day long ago We were created - my friends and I. Spirit was delighted with us. One day long ago my Family was created - my loved ones and I, together with all the other creatures. Spirit was delighted with my family. Spirit, delighted with everything Spirit had made, decided to take a holiday and join us in play. I'd greatly appreciate *any and all* comments, especially from those with backgrounds and concerns different from mine. I'm eager to hear from as many of you as are willing to share your views and on-the-ground insights. TIA, Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
+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. I also like that activities such as Chat could install frame components, and have a proper notification system. 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!). 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? * clipboard * users list Yup, these are the left and right edges, currently. * sources list * network component Are these equivalent to the devices (bottom) edge of the frame? Are you proposing we split them somehow? idea was just to make all existed frame components freely added/removed * notification area I'd much rather see a general notification system built up (we have the beginnings of one already). There are a number of design mockups showing how notifications are bound to the 4 corners of the screen, associated with the 4 edges for activities, people, devices, and objects. notifications would include activity invitations, group invitations, people joining/leaving activities, low battery, lost network, etc. I think
Re: [Sugar-devel] [Feature] Problem Reports
On Sun, Dec 13, 2009 at 7:23 PM, James Cameron qu...@laptop.org wrote: Looks good ... though I haven't actually reviewed the patches. I hope you've thought about what will happen if people report problems that are part of the underlying software stack ... or even hardware. It does bundle a few system logs, so there may be clues there. 317 # Include some log files from /var/log. 318 for fn in ['dmesg', 'messages', 'cron', 'maillog','rpmpkgs', 319'Xorg.0.log', 'spooler']: 320 self.write_log(z, '/var/log/'+fn, 'var-log/'+fn, logbytes) The collection code is based on the old logcollect.py from the original Log activity's Send Logs feature, that was broken for all these years (with the logs going nowhere). Perhaps a way for mass deployments to customise the destination for the problem report. Yep, the logserver URL is a gconf setting. The backend PHP code just stores the data in a folder, puts an entry in a sqlite db, and sends a formatted email to a configured address. So it should be pretty easy for mass deployments to customize. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] Problem Reports
On Sun, Dec 13, 2009 at 8:26 PM, James Cameron qu...@laptop.org wrote: On Sun, Dec 13, 2009 at 08:07:45PM -0500, Wade Brainerd wrote: On Sun, Dec 13, 2009 at 7:23 PM, James Cameron qu...@laptop.org wrote: Looks good ... though I haven't actually reviewed the patches. I hope you've thought about what will happen if people report problems that are part of the underlying software stack ... or even hardware. It does bundle a few system logs, so there may be clues there. Not just that, but how will your processes handle things that aren't outside your direct control? Will you elevate OLPC problems back to OLPC, for example? Will you have adequate translators? Oh, no not at all. That's why it doesn't file bugs. The plan is to have knowledgeable people (myself, to begin with) triage the sugar-reports list and forward data to the appropriate place. For example, if the logs contain a Sugar Python traceback we haven't seen before, whoever is monitoring the list can just forward it to the Sugar maintainers. Eventually I'd like to add some more brains to the log server, like automatically identifying and emailing the author of an activity with an error, based on the log filename. But that's just to save work for the subscribers of the sugar-reports list. If the user wishes to follow up her report with the appropriate support team, they are also given a decimal Report ID which can be used to track down their logs. So they could chase the issue upstream on their own if they wish. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] Problem Reports
On Sun, Dec 13, 2009 at 9:30 PM, Wade Brainerd wad...@gmail.com wrote: On Sun, Dec 13, 2009 at 8:26 PM, James Cameron qu...@laptop.org wrote: On Sun, Dec 13, 2009 at 08:07:45PM -0500, Wade Brainerd wrote: On Sun, Dec 13, 2009 at 7:23 PM, James Cameron qu...@laptop.org wrote: Looks good ... though I haven't actually reviewed the patches. I hope you've thought about what will happen if people report problems that are part of the underlying software stack ... or even hardware. It does bundle a few system logs, so there may be clues there. Not just that, but how will your processes handle things that aren't outside your direct control? Will you elevate OLPC problems back to OLPC, for example? Will you have adequate translators? Actually, maybe I misunderstood you. Yes, if we see a ton of errors that look like OLPC's fault, I will forward them to cjb :) Regarding translation, I plan to make extensive use of GMail Labs' message translator. But Spanish speaking volunteers are welcome. Honestly, I really have no idea what kind of data we'll get through the feature. But any data is better than silence IMO. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] File Share Activity
+1 from me too, for all of Gary's reasons. Looking forward to checking the activity out. -Wade On Sat, Dec 12, 2009 at 1:28 PM, Gary C Martin g...@garycmartin.com wrote: Hi Justin, On 12 Dec 2009, at 16:17, Justin Lewis wrote: I am not the author of Bundle. If people would like to test it, fine by me. This was written mainly to get some sort of file transfer system on the olpc. Another reason is on the 84, it seems you have to pick a file and send it to a specific user, where this system lets you pick files and then send them to anyone who has joined. +1! Being able to publish a number of items for download is a very useful feature (imagine a teacher sharing several resources for a specific class lesson). Thanks for stepping up to do this. There has been talk on Journal at some future point providing something similar, but to be honest a really clean/simple/robust activity would be better, why? 1). Journal could be kept clean and simple instead of trying to overload it with multiple types of sharing features (technically possible, but the design will just get more and more unusable until it looks like a Microsoft office product). 2). As a separate activity it can be developed out side of the Sucrose development/release cycle and team. 3) As a separate activity it can be used by folks not running the latest and greatest version of Sugar (think a generation of hundreds of thousands of kids who use 0.82, and perhaps only ever will). I have not had much testing with it yet so if they would like to test it, that would be great. I still have a few things I need to work on, but any feedback would be great. I'll try and give it some testing, I might have some UI/design type feedback as well if that's OK with you? ;-) Couple of quick questions: - Is it possible to create your git repository on http://git.sugarlabs.org/ or is it already somewhere public? - You named your bundle FileShare-2009-12-11.xo, I'd just go with FileShare-1.xo to stick with current convention, and start bumping up the version integer for each new release from now on (that way Sugar will happily upgrade a previous version correctly). Thanks again for having a go at tackling this one! Regards, --Gary P.S. I think Tomeu mentioned the Bundle activity (I never saw it correctly working when I tested), as there could be a workflow where basically a zip of a bunch of Journal entries could be created by an Activity, and then transferred in one go as a single compressed file (or perhaps in chunks like a torrent). Your File Share activity could potentially subsume this workflow, or do something similar i.e. could provide Download All as the primary button that would trigger a downloading of a single zip of everything; then have little download buttons next to each file if folks want to get just a few (and avoid the need for users to have to select file rows and click on a separate download button). Sorry just rambling, only looked at your screen shot so far ;-) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Zero-calorie bundles?
On Fri, Dec 11, 2009 at 8:00 PM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, I've coded[1] initial implementation[2] for standalone 0install mode, w/o any support from shell. So, activity could bundle saccharin module to .xo and maybe 0install pure python library as well(otherwise system should have already installed zeroinstall-injector package, it could be any version - saccharin will update it from the web on the first start). So, any devs interested in such features are welcome to test it. I'm planing to complete PackageKit integration to 0install and start implementing feeds for ASLO activities that have bundled binary blobs. This is great - as a big user of binary blobs this will relieve a big headache for me. Nice to know it won't require a Sugar update too. Let me know what I need to do to get my activities ported over. I'd like to at least ship the 32bit py2.5 blobs with the activities if possible. Thanks, Wade -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Feature] Problem Reports
Hi all, Here is my feature proposal for Sugar Problem Reports. It's a quick way for users to provide feedback about Sugar. Reports automatically bundle relevant log files, and the PHP log server some simple scraping for Python exceptions, logger.error() calls, etc. The patches are all posted to http://trac.sugarlabs.org/ticket/1439, the wiki page which this content came from is http://wiki.sugarlabs.org/index.php?title=Features/Problem_Reports. Best, -Wade == Summary == The Report a problem control panel provides a way for the user to report issues with the Sugar shell and activities. The control panel uploads system information and logs, along with the user's description of the problem. == Owner == * Name: Wade Brainerd * Email: wad...@gmail.com == Current status == * Targeted release: 0.88 * Last updated: October 16th, 2009 * Percentage of completion: 90% == Detailed Description == A new control panel will be added, titled Report a problem. This panel contains a description box and an Upload report button. When the button is pressed, the description and system logs are uploaded to a central Sugar Labs server. The central server logs the problem reports in a database and stores a copy of the logs. It also analyzes the logs for specific errors (such as Python Tracebacks). When a problem report is added, the server sends an email out to a mailing list of developers and interested parties. When a problem is detected in an Activity, such as failure to launch, Sugar will offer a Report problem button which takes the user directly to the control panel. After uploading, the user is given a Report ID number (a small decimal number). They can use this if they wish to follow up with the Sugar developers by email. == Benefit to Sugar == Currently there is no mechanism for non-technical users to submit problem reports. In order to inform the Sugar or Activity developers of a problem, a user has two options: * Create a Trac account and enter a bug. * Write an email to sugar-de...@lists.sugarlabs.org. The first option is time consuming and requires the user to fill in confusing fields such as Component and Version manually. The second option requires the user to have an email account, and the report is not logged anywhere. Neither option is convenient or provides relevant details about the problem. The new control panel offers a way for casual users to report problems encountered in Sugar. It also supplies a high level of detail about the problem to the developers. The reason problem reports are not added directly to Trac is that we don't want to spam the database with spurious reports. Problem reports are intended to be triaged by subscribers to the mailing list, and then either bugged or noted on an existing ticket. == Scope == A prototype of the control panel and server have been finished and posted to [http://trac.sugarlabs.org/ticket/1439 #1439] as patches. The collection server is currently running at logcollect.sugarlabs.org. Logs are emailed out to the sugar-repo...@lists.sugarlabs.org mailing list. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.84 maintenance
On Sun, Dec 6, 2009 at 6:26 PM, Walter Bender walter.ben...@gmail.com wrote: On Sun, Dec 6, 2009 at 6:20 PM, Gary C Martin g...@garycmartin.com wrote: I think this is a current policy of the activity team? The word policy seems a little official, but yes, I'd certainly not want one of the activities I help maintain to intentionally break under 0.84 (or 0.82 for that matter). Yeah, that's my feeling as well. On the other hand, it is getting to be more and more difficult as an activity developer to keep on top of all the details necessary to maintain backward compatibility. The toolbar is one thing--but changes to journal interactions, json, rainbow, drivers, etc. are less easy--for me--to juggle. Aleksey's sugar-ports [1] library helps mitigate this for me. You just copy modules such as json, toolbar, objectpicker, etc. from sugar-ports into your activity and use them instead of the native Sugar APIs. However, testing is probably the biggest issue. Not sure what the best course of action is--perhaps any large deployment that is running an old Sugar could assign a testing team to that version to provide feedback to activity developers? Agreed - Though, as long as users are getting activities via ASLO, hopefully they are using the Support links when things are broken. -Wade [1] http://git.sugarlabs.org/projects/sugar-port ___ 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
+1 from me for this feature proposal! Both the under-the-hood and user experience simplifications are clear improvements. I would like to see this as a step towards removing the activity list view, which starts to become redundant once activities can be uninstalled from the Journal. I disagree that showing activities in the Journal, in addition to activity instances and MIME objects, will cause confusion. Many activities are more like content. Activities can be downloaded, copied, modified, and deleted. In Sugar terminology, Activities are intended to be verbs while Journal objects are like proper nouns. But if an activity is a verb, the object which performs the activity can still be a noun. For example, the word hammer is both a noun and a verb. The noun in the Journal (Hammer.xo) is an object which enables the verb in the Home view (Hammer Activity). It's quite simple. Best, -Wade On Fri, Nov 27, 2009 at 5:16 PM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, While preparing new 0.88 features, I encountered some in consistence in activities vs. activity bundles case, so I'm going to reveal Activity as regular objects(see [1] ml thread) feature but make it less invasive in case existed user experience. http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object The major reason for this feature is eliminating confusion when: * theres are activities(in Home view) and activity bundles(in Journal) * user can remove bundle from Journal and activity will be preserved(and vise versa) * activities could not have bundles in journal(were deleted or its a system wide activity), so user can't copy activity(e.g. to share it via USB stick) using regular shell workflow(Journal) and should be aware of stuff like Terminal Feature declares: * every activity which is accessible in sugar has Journal entry o for activity came from bundles, entry will have .xo's metadata(timestamp, title etc) o for system wide activities, based of /usr directory properties * there is strong linkage between activity in Home view and journal entry, removing activity in one place, removes it from another o in fact, Home view could be treated as a predefined set(with query terms to show only activities) of Journal entries which is viewed in Home plugin * reflect on system wide activities update, Journal entry's metadata will be changed with keeping only one object per activity * reflect on uploading to Journal new .xo version of existed activity, could be: o follow the same forkflow like with system activities, remove previous .xo from Journal or even do not store uploaded .xo at all, on upload, unzip it to ~/Activities and follow system activities way(entry which represent activity) o storing in Journal several versions of the same activity(including system) and on clicking on particular version in Journal, if it its not installed, ask user to upgrade/downgrade activity(to ~/Activities directory) and then start Benefit to Sugar * feature eliminates confusion, e.g. in case of removing activities, when there are activities(in Home view) and .xo bundles in the Journal(that could be absent - .xo deleted, system activity) * let users, that are not experienced in command line applications, copy existed activity(even system) just by draging Journal entry to USB source * since all activities have Journal representation, keep useful information in entry fields(time of installing activity, additional info in description etc.) Except opinions about feature itself, I'm especially interested in reflect on uploading to Journal new .xo version of existed activity part of it [1] http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06944.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Mon, Nov 30, 2009 at 2:58 PM, Daniel Drake d...@laptop.org wrote: 2009/11/30 Wade Brainerd wad...@gmail.com: I disagree that showing activities in the Journal, in addition to activity instances and MIME objects, will cause confusion. Many activities are more like content. Activities can be downloaded, copied, modified, and deleted. In Sugar terminology, Activities are intended to be verbs while Journal objects are like proper nouns. But if an activity is a verb, the object which performs the activity can still be a noun. For example, the word hammer is both a noun and a verb. The noun in the Journal (Hammer.xo) is an object which enables the verb in the Home view (Hammer Activity). It's quite simple. I agree. I find it simple too. I'd have no problem with it. The problem is when you give it to 6 year olds -- do you also expect them to be able to understand this? Have you followed the number of problems caused to deployments by the activity removal feature that was added to sugar-0.82? The children do this because they think they are removing work created with the activity. No, but perhaps we could take this opportunity to reduce this problem... 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. Really delete Hammer? If the Hammer activity is deleted, all 14 Hammer entries will no longer be usable. Some of the other operations Aleksey mentioned, like upgrading activities, ought to display similar alerts. Regards, Wade ___ 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
On Mon, Nov 30, 2009 at 4:05 PM, Daniel Drake d...@laptop.org wrote: 2009/11/30 Wade Brainerd wad...@gmail.com: No, but perhaps we could take this opportunity to reduce this problem... 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. Really delete Hammer? If the Hammer activity is deleted, all 14 Hammer entries will no longer be usable. There is already a warning not too dissimilar from this. My experience in the field is that children have trouble understanding such dialogs and either give random responses, or continue sticking to their guns that they are removing their work, not the application code itself. Well, with this proposed feature, they could at least get a friend to send the activity to them after they realize their mistake :) Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
A problem with introducing dotted version numbers is that Sugar
versions 0.82-0.86 parse the activity version field using the Python
int() function.
a = int('100.3')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: invalid literal for int() with base 10: '100.3'
If we introduce periods into activity version strings, Sugar will
throw a MalformedBundleException when parsing activity.info. The
effect would be that Sugar would simply fail to register the activity;
it would not appear in the Home view etc.
So, introducing period syntax into an activity bundle automatically
makes it incompatible with Sugar versions 0.82 - 0.86.
This is too harsh for me, so like Gary I would just keep using integers.
On Tue, Nov 24, 2009 at 8:54 AM, Aleksey Lim alsr...@member.fsf.org wrote:
Yes, good point. We should revisit the current activities in Fructose
and think if it makes sense to keep them in Fructose. As you said, one
point is if an activity has dependencies on the platform itself like
Browse (Hulahop).
Has anyone looked into what would be needed to just make Browse work
with older versions of Hulahop?
Anecdote: My XO ran out of space over Thanksgiving and automatically
deleted Browse at boot time. I downloaded the latest version, but it
failed to launch as my XO is running the OLPC 8.2.0 build. This was
pretty annoying to me as I didn't have a web browser available to go
find out which version *would* work.
In mind thats wrong way, some activities have non-sugar SP dependencies
and can work fine with several SP releases, I guess its better to not add
additioanl complexity and use only one source for compatibility info -
on ASLO(moreove we have fructose activities on ASLO).
+1 to keeping activity version numbers totally separate from SP version.
BTW for 0.88 can exclude fructose from core packages at all and let
deployers decide what should be included to deployments.
I support this - ASLO works well enough that Fructose isn't strictly needed.
Wade
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancement suggestion - Maze
I love the faces! Joshua, what do you think about Gary's change? -Wade On Sun, Nov 29, 2009 at 2:05 PM, Gary C Martin g...@garycmartin.com wrote: Hi Tim, On 29 Nov 2009, at 09:15, Tim McNamara wrote: Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. Any thoughts? You could give it a quick try and see if it helps: 1) look in the directory ~/Activities/Maze.activity 2) edit the text file called player.py 3) at line 45 note the line that says border = size / 10. 5) change it to read something like border = size / 5. to double the thickness (see attached screen shot): Testing such changes on real children would be gold class feedback! :-) I'd like to suggest a different change to try. How about a simple face inside the circle to use more of the stroke colour? Here's my quick hack on the code, with screenshot, if you want to give it a try (if folks like this face idea, shout and I'll submit a proper patch): ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Sun, Nov 29, 2009 at 3:28 PM, Jonas Smedegaard d...@jones.dk wrote: On Sun, Nov 29, 2009 at 01:23:22PM -0500, Wade Brainerd wrote: Anecdote: My XO ran out of space over Thanksgiving and automatically deleted Browse at boot time. I downloaded the latest version, but it failed to launch as my XO is running the OLPC 8.2.0 build. This was pretty annoying to me as I didn't have a web browser available to go find out which version *would* work. Hmmm - I believe we were promised that ASLO would ensure that only Activities supported by the client branch of Sugar would be served. Was that a brain fart of mine, a single glitch in an otherwise reliable ASLO version handling, or whould we simply warn Sugar 0.82 users to *not* use ASLO? ASLO does that by checking for the Browse user agent - in my situation, I had to use scp to download Browse from download.sugarlabs.org. Still, the latest Browse is only about 3400 lines of Python code - I wonder how hard it would be to make it backwards compatible with 0.82. Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Backwards compatible Browse
I cloned Browse v114 and spent a few hours hacking on backwards compatibility. I added compatibility fallbacks for the toolbars and a few other modules. The repository is here: http://git.sugarlabs.org/projects/browse/repos/backwards-compatibility On OLPC build 8.2.0, the patched Browse v114 starts and basically works. A few features like typeahead find are broken and beyond my ability to trivially fix, but someone with more experience hacking XPCOM could probably figure it out quickly. Is there any interest in re-forging the compatibility chain, so that the latest Browse will work on old versions of Sugar? Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] .swf files visualization and bundling
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. 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
Re: [Sugar-devel] .swf files visualization and bundling
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
Re: [Sugar-devel] Sharing in Terminal
Hey Sayamindu, This sounds great to me! It was on my TODO list when I added tabs, but I never got around to attempting it. I too like the idea of shared tabs. The way I would do the UI is: When the Terminal activity is shared (either the Share toolbar button has been clicked, or the activity was launched in response to an invitation), an extra button appears in the Tabs toolbar: New Shared Tab Any user can click this button; tab that is created will be visible by all participants. The shared tab's title bar will be prefixed with the owner's buddy name and could even display their buddy icon. -Wade On Sun, Nov 22, 2009 at 5:32 PM, Sayamindu Dasgupta sayami...@gmail.com wrote: On Tue, Nov 17, 2009 at 8:09 AM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Sayamindu Dasgupta wrote: Hello, While going through Ben Schwartz's Shared Term feature proposal discussion page (http://wiki.sugarlabs.org/go/Talk:Features/Terminal_Sharing), I started to wonder if we could somehow implement readonly mode for sharing in the Terminal activity. After a weekend of hacking : I have managed to come up with the following: I like it. A read-only mode is definitely useful, albeit in a very different way from a shared interactive terminal. I couldn't figure out a way to grab the text from the terminal, so I ended up implementing Watch Me, which provides the same functionality (and much more general functionality), but in a much less efficient and integrated way. There are some UI things that will need to be worked out. Most obviously, the hidden split-screen is currently totally non-discoverable. I also think that N-to-N sharing might be more generally useful. For example, it could use the Terminal's tabs mechanism to show one tab for each user to all users. Perhaps both modes could be subsumed into one by providing a button for each user to show or hide her terminal. I can't tell from your e-mail what is working, exactly. I think it's important that TUIs like nano and less work properly, as far as possible. For users with different screen or font sizes, some difficulty is inevitable. Thanks for the feedback. I checked with Nano and VIM and they render fine (though a small problem is that the action is often hidden from view as the initial text manipulation happens in the top of the screen, which remains out of the viewport in the shared terminal view). I like your ideas on utilizing the tab mechanism for N-N sharing, since at the moment, the sharing happens blindly in 1-N fashion from the first tab only, which I think is a bit clumsy. I think I'll propose read only shared terminal as a feature for 0.88 Thanks again, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Bugs] #1447 NORM: Display a message when an activity fails to start
Screencast: http://www.youtube.com/watch?v=gSLhWEKchVE I agree that the new terminology is weird. My original version said Blah failed to start. and the button said Close. That made a bit more sense to me since Stop implies that something *has* started. -Wade On Thu, Nov 19, 2009 at 9:11 AM, Tomeu Vizoso to...@sugarlabs.org wrote: 2009/11/4 Gary C Martin g...@garycmartin.com: Hi Wade, Just wanted to ping on this; have been running with your 0001-Notify- shell-when-activity-process-terminates.patch and 0001-Added-Close- button-to-activity-launcher-rewrote-lay.patch applied to sugar-jhbuild for the last ~4 days, and it has been working very well. Some of quick comments: - On just one occasion (have not been able to reproducible) I saw the 'Stop' button briefly display before the activity successfully launched. - I'm trying to find a different error message 'activity failed to start.' now that 'Stop' is the button text. My mind keeps grating against the dilemma of stopping something that never actually started :-) - The pulse pause feels a little long, perhaps 1 or 1.5 sec would be long enough. I really need to try and get this patch on XO-1 HW and see what the launch time savings are like (I'm sure even a 1:1 ratio of animation to pause should save us a couple of 2 seconds in many cases). - What ever the final pulse animation timing/pause ends up at (assuming we see some XO-1 load improvement) it should also be used for the other pulsing animations as well (activity tray activity icons when launching, corner notification effects). Again, fab work! It really makes activity developing test cycle much more friendly :-) So, do we have a positive vote from the design team on this? Wonder what would be the best way to get some feedback from the field, is there already a screencast we can pass around? Thanks, Tomeu Regards, --Gary On 31 Oct 2009, at 02:06, Sugar Labs Bugs wrote: #1447: Display a message when an activity fails to start +--- Reporter: wadeb | Owner: wadeb Type: enhancement | Status: accepted Priority: Normal | Milestone: 0.88 Component: sugar | Version: Git as of bugdate Severity: Unspecified | Keywords: Distribution: Unspecified | Status_field: Unconfirmed +--- Comment(by wadeb): I posted a brand new patch for Sugar. * Improves the layout so the icon doesn't move when the error appears * Uses Stop as suggested by Gary * Delays for a few seconds between pulses to give the user something to count and potentially improve performance. -- Ticket URL: http://bugs.sugarlabs.org/ticket/1447#comment:10 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Bugs mailing list b...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/bugs ___ 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] [ANNOUNCE] Sugargame v1.0
http://wiki.sugarlabs.org/go/Development_Team/Sugargame == Sugargame == Sugargame is a Python package which allows [http://www.pygame.org/ Pygame] programs to run well under Sugar. It is fork of the olcpgames framework, which is no longer maintained. http://git.sugarlabs.org/projects/sugargame What it does: * Wraps a Sugar activity around an existing Pygame program with few changes * Allows Sugar toolbars and other widgets to be added to the activity UI * Provides hooks for saving to and restoring from the Journal Differences between Sugargame and olpcgames The olpcgames framework provides a wrapper around Pygame which attempts to allow a Pygame program to run mostly unmodified under Sugar. To this end, the Pygame program is run in a separate thread with its own Pygame message loop while the main thread runs the GTK message loop. Also, olpcgames wraps Sugar APIs such as the journal and mesh into a Pygame-like API. Sugargame takes a simpler approach; it provides a way to embed Pygame into a GTK widget. The Sugar APIs are used to interact with Sugar, the Pygame APIs are used for the game. Sugargame advantages: * Simpler code * More elegant interface between Pygame and GTK * Runs as a single thread: no thread related segfaults * Possible to use Sugar widgets with Pygame Sugargame limitations: * No support for Pango or SVG sprites (yet) See the Wiki page for usage information and examples. A port of Physics to Sugargame exists at http://git.sugarlabs.org/projects/physics/repos/wadebs-clone. My hope is that Physics and other olpcgames-based activities will migrate to Sugargame, and that more hybrid PyGTK + Sugargame activities will appear. Best, -Wade ___ 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
Looks like a nice improvement to me. But, per thread from a few weeks ago, I think the Keep vs Stop concept needs attention and this feature should probably become a part of whatever solution we reach for that difficult problem. On Thu, Nov 19, 2009 at 4:10 PM, Eduardo H. Silva hoboprim...@gmail.com wrote: I like the idea, and much prefer it. As for the design, what about using as a toolbar icon the journal+pencil icon? It would imply that you are writing something into the journal, in this case the title and description and tags of the current activity. There is a potential problem of adding another persistent icon to the toolbar, which is it shrinks the space for the activity's icons. If this is the case, perhaps this functionality should be merged with the Keep button in some way, but since Keep is/will be used to Keep new versions and also to Keep the activiy in a different format it would need a new design. Perhaps these options (Keep new version, Keep as X) could be added as buttons on the top or bottom of the description window which would be a secondary palette of the Keep button. Just food for thought. Eduardo 2009/11/19 Walter Bender walter.ben...@gmail.com: 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 :) Comments? -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-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking feedback on sketch of a new color selector
I like it, especially the version with arrows instead of undo. The best part for me is that it allows you to go backwards, if you decide you liked an earlier color better. -Wade On Wed, Nov 11, 2009 at 12:42 PM, Walter Bender walter.ben...@gmail.com wrote: I just posted another version (no undo) and I think more clarity as to what is going on... You can click the buttons or the small XOs. -walter On Wed, Nov 11, 2009 at 12:31 PM, Gary C Martin g...@garycmartin.com wrote: Hi Walter, On 11 Nov 2009, at 15:48, Walter Bender wrote: I made a patch to the color selector on the About Me panel to make it a little easier to navigate the color selections. Please see my screen cast at http://dailymotion.virgilio.it/video/xb42um_color-selector_tech. I needed to watch through a number of times before I could work out the logic for the colours of the two smaller buddy icons. First couple of times through I thought one was a swapped fill/stroke, and the other was a 'light' version, then third time through I decided they must all just be random, finally I twigged that it was a scrolling history moving from right to left (small -- big -- small). Quick thoughts: - What you have now would be visually understandable after a single click if you added a brief transition animation so that the icons scroll left/right and resize (like a carousel). - Not convinced you need the undo icon if you can add the transition animation, it feels slightly odd at the moment that the undo is right next to the yet too be seen new colour combination (perhaps it could go above or below the centre icon if it really needs to stay in the design). - The alternative is to have N small buddy icons around the central large icon, where the small icons are a close variation of the central large icon colours. Clicking the centre icon picks a completely new random base set of colours; clicking any small icon moves it to the centre large position, and generates a new set of small variants. The colour variants could just be +/- small random steps from the main base colours, or have some spacial meaning (left/right could be +/- fill colour, up/down could be +/- stroke colour). Regards, --Gary -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [math4] slides to help a new sugar/pygtk developer
Hey Mike, Cool- Thanks for developing and posting this! On Tue, Nov 3, 2009 at 10:02 PM, Mike Major jmi...@bellsouth.net wrote: i started developing the activity back in june. at the time i was completely new to both sugar and python. i did a lot of searching on the sugarlabs and laptop.org wikis and felt generally lost for a while. Sorry to hear you felt lost, but I'm excited to see what you found were the key resources to getting started faster. They should probably be added to http://wiki.sugarlabs.org/go/Activity_Team/Resources - this is the central repository for getting started with activity development information. BTW, I went back and read some of your earlier posts about localization - did you end up with an acceptable solution and did you get your activity in Pootle? Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] New SoaS Snapshot ready!
FYI the .vmdk in soas04.zip halts with no text right after GRUB starts. Any suggestions for kernel parameters to try? Strawberry was quite different- the root was specified by some kind of hash code, was mounted rw (now it's ro) and the liveimage, quiet and rghb options were set. Blueberry has none of these. Can we renamed soas04.zip to soas04virtualbox.zip in future builds? It's confusing to me because .zip does not have any connection to virtual machines. Keep up the good work! -Wade On Sat, Oct 31, 2009 at 9:32 AM, Sebastian Dziallas sebast...@when.com wrote: Hi all, here's the next snapshot on our way to SoaS v2 Blueberry. This one fixes some issues and introduces new features, namely: * the updated FoodForce2, Slideruler and SocialCalc activities * the gtk-recordmydesktop tool - execute it from the terminal * new sample content - Alice's Adventures in Wonderland - see below * fix boot issues of XO builds - Martin Dengler The snapshot is available here (following the soas04 naming scheme): http://download.sugarlabs.org/soas/snapshots/2/ Known issues (https://bugs.launchpad.net/soas/+bugs) include: * Sugar crashes on XO if vertical scrollbar accessed * Record fails to launch on a Classmate 2 (Magalhãls) * No sample maps appear in v2 Snapshots * Read crashes when trying to display EPUB sample * CartoonBuilder Activity fails to launch In case you've an idea what's going on with these issues, please comment in their tickets or just reply here, as they're pretty critical for the upcoming SoaS release! Thanks, --Sebastian ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] New SoaS Snapshot ready!
On Tue, Nov 3, 2009 at 8:54 AM, Martin Dengler mar...@martindengler.com wrote: On Tue, Nov 03, 2009 at 08:08:54AM -0500, Wade Brainerd wrote: Can we renamed soas04.zip to soas04virtualbox.zip in future builds? It's confusing to me because .zip does not have any connection to virtual machines. Due to a typo in the Makefile the file that was supposed to be called soas*.vmdk.zip has been called soas*.zip. I chose .vmdk.zip because the file-that-is-zipped is soas*.vmdk. I have fixed the typo. Do you think soas*.vmdk.zip is sensible? Yeah, .vmdk.zip would be fine. I suggested soas04virtualbox.zip to mirror soas04xo.zip but either way is good. -Wade -Wade Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] (Please read) Re: Proposed Trac - Launchpad migration
I have no experience with Launchpad, but am often frustrated by the performance of SL Trac. At my office we switched from Trac to Redmine for internal project development, since Trac's development seems to have slowed to a crawl. Provided a high priority is placed on migrating bug numbers and keeping links to dev.sugarlabs.org working, I'm not opposed. I'll probably take Gary's approach and let the dust settle though. Now that 0.86 is out it's probably the best time to do this. Any chance OLPC would consider moving over too, so we could have true connections between OLPC and SL bugs? -Wade On Mon, Nov 2, 2009 at 8:55 AM, Luke Faraone l...@faraone.cc wrote: On Sun, Nov 1, 2009 at 22:36, Gary C Martin g...@garycmartin.com wrote: * Existing bug data will be imported, but the bug numbers won't be the same. So the git commit messages referencing trac bug tickets will be future information garbage, oh joy. As stated, there will be both a conversion table and a redirect service available for the considerable future. We already have fragmentation between SL bugs and OLPC bugs. Launchpad will allow us to keep our old bug numbers Is there anything else that would make this work better for everyone? An example of the redirection scheme: https://launchpad.net/sugar/+bug/slbugs1534 points to a page titled Bug #460049 (slbugs1534). We can change the nickname prefix to whatever we'd like. * It will be hosted by Canonical externally, rather than by SL as Trac currently is. If any of these are not to your liking, the time to speak up is now, before it all happens. :) Not to my liking, but if some really smart/committed folks are willing to do the work, have it well tested, say this is really worth the pain, and don't mind some folks ignoring the move for a few months... Though, I would first really love to see a clear explanation of why this is a good idea, and how the move benefits us. To quote Bernie, our system administrator and current manager of Sugar Labs' Trac instance: bernie: my #1 reason for switching is that our trac instance is a wreck and nobody wants to maintain it. bernie: me less than anyone else. it's an awful application to maintain... especially now that it is riddled by spammers Switching to Launchpad would free up admin time to work on improving other services, such as ASLO and the wiki. Launchpad is already many times faster than the current Sugar Labs bug tracker, and Canonical has committed to add capacity as the service grows. In addition, Launchpad allows developers to manipulate bugs by email (a la bugs.debian.org), permitting developers to choose their own workflow. Launchpad also is better suited for multi-project collaboration, both within Sugarlabs and with other distributions. We can easily track the status of bugs that affect both upstream Sugar and the Sugar packages in, say, Ubuntu, Fedora, Debian, and Gentoo, all from the same page. We've been testing Launchpad with the Sugar on a Stick project for a few months now, and it's been working pretty well. Finally, we would be able to migrate away from Launchpad at any time. Thanks, Luke Faraone http://luke.faraone.cc ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
+1 from me! Resume by Default inhibits learning the difference between Activity and Activity Instance which is a key computer concept. Back-porting to 0.84 and 0.86 sounds great to me; is the patch simple? -Wade On Wed, Oct 28, 2009 at 2:14 PM, Gary C Martin g...@garycmartin.com wrote: On 14 Oct 2009, at 17:39, Eben Eliason wrote: On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer si...@schampijer.de wrote: On 10/13/2009 04:36 AM, Bernie Innocenti wrote: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. (please, let's not add another configurable knob!) From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001 From: Michael Stonemich...@laptop.org Date: Mon, 14 Sep 2009 22:33:12 -0400 Subject: Make various palette animations happen more quickly. Can you describe what the patch will change from the user point of view? Is this to get rid of the delayed build up of palettes when hovering over icons? You can use right click to get the menu immediately. The delay is on purpose. We should definitely get feedback. I wouldn't be entirely opposed to a change, but I do want to make sure that we make such a change for the right reasons, and that it's actually the right change to make. The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. Kids should be able to start activities, resume activities, join activities, write, paint, stop, etc. without ever seeing a palette at all. [1] This is the low floor. For kids with more experience or curiosity, we decided to provide contextual palettes which grouped related actions and provided more complex interactions with the system. This is no ceiling. Furthermore, we wanted to help introduce kids to the availability of additional options in a discoverable way, which is why the hover effect was chosen to provide increasing levels of detail and interaction for a given object. Finding that many kids were actually waiting for the palette to appear always, instead of, for instance, simply clicking on an activity icon to join it, encouraged us to INcrease the delay on the palettes to help emphasize this as a secondary mechanism for interaction. A agree that hovering in one place to click in another isn't great; but that's also not the intended primary means of interaction, and should only really be done when one of the secondary actions is desired. Removing the delay pushes us, I fear, even farther away from an interface in which nice friendly large clickable icons can be directly manipulated and encourages every action to be done through a contextual menu with a bunch of text in it. Is that really what we want kids to face? Just for fun, I might suggest an alternate possibility which actually decreases the discoverability of the secondary palette. We could reveal the primary palette (label) on a delay as we do now, with some indication of more options that can be clicked to expand the menu to reveal the secondary items. This would provide the (essential) primary palette as a label and introduce kids to the existence of more controls without encouraging them to use this as a primary method of interaction. Advanced users, of course, could still right-click to invoke the full menu in one shot. Eben [1] Incidentally, one of my major complaints with the resume by default behavior is that it makes starting new activities hard to do, and virtually impossible to do without using a secondary action, which is the wrong approach in my mind. I think starting from home, with the option to resume, while encouraging one-click resume from the Journal is still the correct approach. I think offering the option to enter resume by default mode is great, but I'm not sure it should be, itself, the default for Home view. In practice, it seems it has worked too well. It used to be that kids never resumed activities. Now, it seems, they never start new ones. The solution seems to be in encouraging use of the Journal and the Home view for these different default actions, and in clarifying the UI such that kids understand and desire to do so. Just wanted to ping the list with a mockup and comment I've attached to a trac ticket regarding reverting the 'resume by default' home view feature: http://bugs.sugarlabs.org/ticket/1382 The direct link to the mockup image is: http://bugs.sugarlabs.org/attachment/ticket/1382/home_mockup_with_start_new_as_default.png One worry I have is that we're generating feature churn, especially if OLPC starts shipping real quantities of 0.84 in a few months... Sugar 0.82
Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse
Yeah, Stop and Don't Stop sound best to me. Cancel is almost never an appropriate button; we should grep the codebase for it :) On Mon, Oct 19, 2009 at 8:35 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Oct 19, 2009 at 13:32, Gabriel Eirea gei...@gmail.com wrote: How about Quit and Don't quit? That would be better, though activities are stopped, rather than quitted. Thanks, Tomeu 2009/10/19 Tomeu Vizoso to...@sugarlabs.org: Any ideas for a better wording? Thanks, Tomeu On Sat, Oct 17, 2009 at 00:40, Sugar Labs Bugs bugtracker-nore...@sugarlabs.org wrote: #1508: confusing wording on download from Browse --+- Reporter: walter | Owner: erikos Type: enhancement | Status: new Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team Component: Browse | Version: Git as of bugdate Severity: Trivial | Keywords: Distribution: Unspecified | Status_field: Unconfirmed --+- If you try to quit Browse in the middle of a download, you are told that quiting will cancel the download and you are presented with two buttons: cancel and stop. Hitting the stop button will cancel the download and hitting the cancel button will cancel the quitting, hence not cancel the download. I wonder if there are better words we can use to make this a bit less confusing. -- Ticket URL: http://bugs.sugarlabs.org/ticket/1508 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Bugs mailing list b...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/bugs -- «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 mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse
On Mon, Oct 19, 2009 at 10:12 AM, Eben Eliason e...@laptop.org wrote: To stop the activity now now you must cancel your ongoing download. [Cancel download] [Continue download] This sounds well thought out, but imagining the experience in my head makes me wonder a little. Two user perspectives: 1) Do I want to keep downloading or not? Continuing the activity is the implicit choice. 2) Do I want to keep using the activity or not? Continuing the download is the implicit choice. Since I clicked the [Stop] button, 2) feels more natural. Whether to stop the activity should be the primary choice, with the download's continuation being implicit, since stopping the activity was the initiating action. In other words making a decision, then being asked an orthogonal question (with an implicit effect on the decision I made), seems off. Side note: Since the Journal displays the progress bar as files are downloaded, wouldn't it be cool if Browse just handed the download off to the Journal? That would allow the download to continue even after Browse stops. It would also allow the download to be resumed if the machine is restarted, network connection lost, etc. Worthy Journal feature request? -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse
On Mon, Oct 19, 2009 at 3:04 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Oct 19, 2009 at 20:01, Wade Brainerd wad...@gmail.com wrote: Side note: Since the Journal displays the progress bar as files are downloaded, wouldn't it be cool if Browse just handed the download off to the Journal? That would allow the download to continue even after Browse stops. It would also allow the download to be resumed if the machine is restarted, network connection lost, etc. Worthy Journal feature request? This was the desired user experience, but mozilla's architecture made it quite hard without losing the ability to download inside existing http sessions. I see what you mean about sessions. Is there some way to detect whether a download is dependent on the browser session? Another option, though it would not allow later resuming, would be to let the Browse instance keep running even after the activity has stopped. It would just hide its main window and send some other termination notice to the Sugar shell. The activity failure notice patch might be a good start; Browse could just send a NotifyActivityEnded message to the shell without terminating its process. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Zero-install-devel] Summary of the chat on #sugar-meeting
On Mon, Oct 19, 2009 at 6:59 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, Oct 18, 2009 at 21:27, Michael Stone mich...@laptop.org wrote: Dear z-i folks and sugar folks, Three members of the 0install.net community [1] met with several members of the Sugar community [2] yesterday to exchange knowledge and, in the case of the Sugar folks, to learn more about z-i and whether it might be a good fit for use in Sugar activity installation. Hey, this is great stuff, thanks all and look forward for the next steps. Indeed! BTW, this is further out (years, if ever) but a friend of a friend is working on a kernel patch that will help simplify packaging for multiple architectures. http://icculus.org/fatelf/ Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
On Sat, Oct 17, 2009 at 11:18 PM, Paul Fox p...@laptop.org wrote: i agree with others that the new proposal isn't nearly as nice, or as much fun, as the current pulsing icon (though i think other aspects, like the close button, are good). i think that avi is spot on when he says: Ok, seems like there are opinions in both directions - big surprise :) I for one was a bit offended when the pulsing icon appeared. Activities were taking 30 seconds to launch on XO and it seemed wrong to blow a bunch of CPU time on animation when the poor machine was obviously overtaxed! But, I guess the lesson is Bling given, cannot be taken away, which makes sense. The close button is already posted as a separate patch: http://dev.sugarlabs.org/ticket/1447 (That's why I was in the code) I'm going to shelve the dots for now, but if someone from design wants to take it over and produce an official spec I'd be happy to implement that. Best, Wade PS- Eben, I didn't realize it, but I think I was actually arguing against the progress bar! Never really liked those things; always halting at weird places, and never accurate. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] friendview.py
Yeah, P2P activity sharing would be awesome. http://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles says Activities are meant to be shared between children. If a child doesn't have the activity, it is automatically transfered to the child when he or she joins the shared activity. but I don't believe this was ever implemented...? -Wade On Sat, Oct 17, 2009 at 9:35 AM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Tim McNamara wrote: Naturally, people will probably want to click on that question mark. Would we be able to have a dialogue like Search for activity %s? % name, which if accepted opens up Browse and searches http://activities.sugarlabs.org to download it? That would be about ten times better than the current behavior. This would be easiest if you can p2p file share activities... I've played around a bit, but it doesn't look especially obvious. Yes, that would be, by far, even better. It shouldn't be incredibly difficult, since Telepathy provides us with a high-level file transfer operation, but there's still some code required to (1) request the transfer, (2) create a bundle if necessary, (3) transfer the bundle, (4) install the bundle, and then (5) launch it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
On Sat, Oct 17, 2009 at 5:43 PM, Walter Bender walter.ben...@gmail.com wrote: What is the behavior for activities that have a long launch time (I am thinking for example of the first time you launch Turtle Art, when it has to generate a lot of artwork for the data directory)? Heh, the mockup stops adding dots after 12 seconds :) It seems like there is enough interest to clean it up though; I'll come up with something and post a longer video including edge cases. Also, there has been some discussion about making a journal entry for failed launches. Is that part of this patch? I'll include it. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design mockup of a different activity launcher
Hi Eben, thanks for the feedback! On Sat, Oct 17, 2009 at 7:27 PM, Eben Eliason e...@laptop.org wrote: On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd wad...@gmail.com wrote: http://www.youtube.com/watch?v=OvDdN1t-0yE I was in the code and have wanted to try this for awhile! If anyone else thinks it would be better than the pulsing icon, I'll clean up and post the patch to a Feature on the wiki. Rationale: 1) Less flashy Perhaps, although the screen actually feels busier to me. Perhaps with some visual tweaks it would work (smaller ring, maybe?), since showing how long it will take to launch is useful feedback. I'm happy to make any tweaks to the layout, colors, sizes of the dots, spacing, etc. If design can provide a mockup, that would be great! But if not, I'm happy to take suggestions and try to improve it. I lament the loss of the pulsing icon, though. This approach doesn't retain the transition from outline to fill that's important to the activity paradigm. Could we retain that, or is that the flashy part you aim to eliminate? I wanted to stop drawing something big every frame while the activity is trying to start; that's the supposed performance improvement. Blinking would be fine, or a brief fade in at the beginning. 2) Clock theme represents time I don't understand how we know how long the launch is going to take. Is that something that we can estimate to a reasonable degree? Or do you plan to estimate the average launch time across many launches? No - the clock just displays one new dot per second. So an activity which launches in 3 seconds shows 3 dots. I could implement some estimation capacity, but that would mean the dots appear faster or slower. I prefer to let the user see there is a different amount of work involved in starting each activity, instead of implying that the same amount of work is being done at a different rate. 3) Ability to count how many seconds the launch takes I'm not sure I see usefulness in knowing how long it takes overall; knowing how much longer it will take is definitely something a kid will want to know, though, so it's good to show that. The way it's implemented now, the kid has to remember how many dots an activity takes to start up. But I think that could aid children who are learning to count :) (WARNING: Heresay!!) 4) Close button (instead of timeout) when there is an error This is definitely a big improvement. I like this a lot, and think we should also add options for looking at the crash reports and/or submitting a bug containing them to the maintainer of the activity, eventually. I did some work towards this, with a patch ready for 0.88, in http://wiki.sugarlabs.org/go/Features/Problem_Reports. I will definitely make it automatically save the activity log to the Journal, though. 5) Possibly less startup overhead; needs to be tested on XO True. If CPU is a concern, I'd vote to simply blink the icon between stroke and fill states, instead of pulsing, in order to reduce the animation overhead while retaining the visual metaphor. Blinking would definitely be ok. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Activity version compatibility
On Tue, Oct 13, 2009 at 6:15 PM, Gary C Martin g...@garycmartin.com wrote: On 13 Oct 2009, at 15:29, Tomeu Vizoso wrote: On Wed, Sep 30, 2009 at 05:35, Wade Brainerd wad...@gmail.com wrote: BTW, we should still answer the question of the activity.info field... Seems like there 3 options to me: 1) Deprecate host_version in the activity.info spec. Activity developers write code to test for presence non-BC APIs and provide fallbacks (or else let activities fail to launch/work). FWIW 1) is the one I've been following (testing for available features, providing fallbacks, accept failure to launch reports as bugs to fix). It seems to just be a small number of current Sucrose activities that are genuinely backwards incompatible with previous Sugar releases. 2) Keep host_version as an incrementing number, make activityfactory respect it, and bump the Sugar number from 1 to 2 in 0.86.1 to reflect the toolbar changes. 3) Deprecate host_version, introduce sugar_version which is set to the oldest Sugar version number the activity is compatible with. I'd not object to 3) if someone really has a bee in their bonnet ;-b but I'd be unlikely to use it, and don't see it helping in many real user cases (it just provides an opportunity to show a prettier error message). Sugar platform releases seem pretty far down the scale of reasons for most launch failures, 95% of such cases will be covered by a smarter pulsing-window launcher for when an Activity fails (bad distro installs, latest architecture flavour of the week, missing platform dependancies, new changes in Sugar that break old code, un-anticipitated security permissions, actual bugs, users hacking on and breaking code). Regards, --Gary I'm also in favor of 1) as a starting point. I will submit a patch to remove all references to host_version and remove it from the documentation. If in the future we realize we need something better, we could talk about 3) again. Totally agree w.r.t. most activity failures. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
I take two points from this exchange: #1 User interaction changes are always subjective. Patches, requests, suggestions, etc. should not be submitted with duh as a rationale. They should be backed up with a clear rationale; better yet, hard data. #2 The Sugar UI is not sacred. There needs to be a process to collect and evaluate data, and to design and implement improvements. With changes to the user experience, writing the code is expected to be the simplest part of the process so the patch may be trivial, but acceptance may not. I could submit a patch changing the Home background color to a lovely blue; it would be trivial to apply and motivating for me, but not necessarily a good idea! The correct way to submit this patch is to file an enhancement bug, post the patch to the bug, and create a wiki page under http://wiki.sugarlabs.org/go/Features using the provided template. An improvement to this patch that would increase its likelihood of acceptance would be to make it a toggle. Even better would be to report delayed menu item clicks to a usability log server. Work with a deployment to distribute both versions randomly, analyze the results, and include that in the feature request. I'd like to put my designer hat on for a minute and offer an alternative to Bernie/Michael's patch and the current behavior: Any time the mouse hovers over a part of the screen with a delayed action, that part must immediately highlight itself. With the frame, that would be a 1px rectangle around the screen. With icons, this could be a border rectangle. Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Zero-calorie bundles?
On Thu, Oct 15, 2009 at 11:05 AM, DancesWithCars danceswithc...@gmail.com wrote: yes, what is you exec overview/ why are you proposing to discard .xo bundling? or is this an option? I don't think that we're discussing discarding .xo bundling. I think we're discussing augmenting .xo bundling with 0install to bring in dependencies. My only question about 0install is how does it hold up when there is no infrastructure access? Can I still transfer a .xo bundle to someone under a tree and expect it to work? With the current apple-like include everything approach it works. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Strings missing in 0.86 r. 04_10_2009 ReadEtext
On Mon, Oct 12, 2009 at 10:50 AM, Carlo Falciola cfalci...@yahoo.it wrote: Wade, I agree on the point, anyway the string I referenced is not part of aany lesson and is already present in Pootle... see the attached image.. then if it should not being translated it would be better to purge from the .po files, otherwise it should appear (translated) in the software.. ciao e grazie! carlo Gotcha - I'll make sure that in future versions the strings are present in the UI or else not in Pootle. Thanks for letting me know! -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Namespace for 0.84 updates to Browse and Chat?
On Tue, Oct 13, 2009 at 1:38 PM, Tomeu Vizoso to...@sugarlabs.org wrote: Remains to see what existing versions of Sugar would do with a bundle with a dot in the version number. It's parsed as int(version) [1] - so it's not going to work well! Is there some reason that we are forced to patch Browse and Chat such? Are newer versions of the activities not backwards compatible with older versions of Sugar? I think it's best if we can avoid user confusion as much as possible; especially given parallel sources of activities: apt-get, the activity updater, ASLO, etc. Best, Wade [1] http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/blobs/master/src/sugar/bundle/activitybundle.py#line187 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Live USB Creator (Fedora) and experimental SoaS builds
Hear hear! BTW, I submitted a patch to LiveUSB creator to build a proper installer for the program; I'm not sure if it was ever rolled into the official version. Best, Wade On Tue, Oct 13, 2009 at 2:29 PM, Art Hunkins abhun...@uncg.edu wrote: I've been unable to build any SoaS other than Strawberry with Fedora's Live USB Creator. Are the experimental versions (including SoaS02.iso) this way by design? As a person basically working within the Windows OS, the Live USB Creator is a godsend to me. I'm sure it's a godsend to anyone not steeped in Linux. Without such an easy way of accessing Sugar and its activities, users unfamiliar with Linux are unlikely, at least on an individual basis, to become involved with Sugar. This includes developers such as myself. I so much hope that significant improvements to Sugar can be made available through Live USB Creator. If this occurs, those outside the Linux community can readily get involved and offer crucial feedback. Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Strings missing in 0.86 r. 04_10_2009 ReadEtext
Hi Carlo, On Mon, Oct 12, 2009 at 9:41 AM, Carlo Falciola cfalci...@yahoo.it wrote: - Typing Turtle Most of comments strings: like: Hihowahyah! Ready to learn the secret of fast typing?\n Typing Turtle doesn't use the standard localization system for its lesson data: different keyboard layouts change the lessons too much for it to make any sense. The latest version does ship with a GUI lesson editor though, and if anyone wants to help out with the lesson development effort they're welcome to! (Hmmm, perhaps for translators I should include a dummy string like TRANSLATORS: To translate lesson content, ...) -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] XO emulator for Linux
Hi Walther, http://wiki.sugarlabs.org/go/Activity_Team/Resources links to options for setting up Activity development environment on Windows, Linux and MacOS X. Briefly: For Linux hosts you can use native packages, jhbuild or a virtual machine. The best Windows and Mac option is VirtualBox. The resources page also links to various tutorials, wiki pages, and other references that are useful when learning Activity development. Regarding automated testing, please check the Sugarbot project at http://code.google.com/p/sugarbot/. It looks like it's been idle for about a year, and I'm not sure what stage of completion it reached (who was the mentor btw?), but it may make a good starting point! Best regards, Wade On Thu, Oct 8, 2009 at 8:57 AM, Walther Neuper neu...@ist.tugraz.at wrote: Hi Tomeu, thank you for your mail ! You ask: Can you give us some more details about what do you plan to develop and how do you expect it to be deployed? Christoph Derndorfer established a project in Austria, where 25 kids of 8-9 years got XOs in 2008. And our Institute will contribute with a new activity requested by the teacher of these kids http://www.ist.tugraz.at/projects/isac/rp/reckonprimer.html Last summer semester 1 student built a prototype, and there are several students (a selection from those listening cc) who want to contribute to this activity during this winter semester. Time scheduled for this is not much more than 100h, thus it is too short to build up a complicated development environment, and too short for getting familiar with complicated things. But we would like to have # our repository somewhere at http://git.sugarlabs.org/projects/ # a test-driven development, having something like /usr/share/activities/ReckonPrimer.activity /usr/share/activities/ReckonPrimer.tests # ??? presently I have no more ideas what details to mention. Most students have Linux (Ubuntu etc) on their computers, some Windows. Any suggestions are welcome ! Walther PS: About deployment: our present focus is the school teaching the 25 kids mentioned. If our product will turn out interesting for others, we would be even more motivated ! -- 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 Tomeu Vizoso wrote: Hi Walther, On Thu, Oct 8, 2009 at 12:56, Walther Neuper neu...@ist.tugraz.at wrote: Hi, following the instructions on http://wiki.laptop.org/go/Emulating_the_XO/Quick_Start/Linux leads for Linux users to olpc-redhat-stream-ship.2-devel_ext3.img.bz2 29-Feb-2008 19:49 206M olpc-redhat-stream-ship.2-build-659-20080229_1949-devel_ext3.img.bz2 http://xs-dev.laptop.org/cscott/olpc/streams/ship.2/latest/devel_ext3/olpc-redhat-stream-ship.2-build-659-20080229_1949-devel_ext3.img.bz2 29-Feb-2008 19:49 206M Christoph Derndorfer pointed out, that both are an outdated versions. Where can we get the actual version for Linux ? Or askel more generally: What kind of development environment would you recommend for Linux ? There are many versions of Sugar, and the differences matter depending on what kind of development you want to do. Can you give us some more details about what do you plan to develop and how do you expect it to be deployed? Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Conozco Uruguay in karma
Cool, can't wait to see the finished product. So far the code looks reasonably straightforward and intuitive (and I'm a JS neophyte). -Wade On Thu, Oct 8, 2009 at 1:04 PM, Ze maria zemari...@gmail.com wrote: Hello guys, I started a port of the activity Conozco Uruguay (available at http://activities.sugarlabs.org/en-US/sugar/addon/4199) from Python to the new Karma framework (downloaded from: http://git.sugarlabs.org/projects/karma). I'm new to html5 and to the canvas element so don't be scared by the lookn'feel :) Currently to only thing implemented is the capital game, where a person guesses where which capital of the state is located. By the way, I coulnd't get to work the Raphael function 'print', every time I try to use I get a : Error: f.fonts is undefined Source File: file:///Users/zemariamm/workspace/olenepal/mainline/js/raphael-min.js Line: 7 The code is available at http://github.com/zemariamm/Conozco-UruguayComments, critics and sugestions are all welcome :) (To run the code just download the new karma framework and drop the urugay activity code in the lessons directory) Take care, Jose ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Talk at New Zealand PyCon : Support from dev team needed
Hey Tim, On Sun, Oct 4, 2009 at 11:19 PM, Tim McNamara paperl...@timmcnamara.co.nzwrote: 1) What kinds of things are likely to be of great interest to the general python community? What made you get involved with Sugar? Perhaps I could sow those seeds in local developers' minds... Mostly just the promise of children all over the world learning with your software. Insert lots of pictures of kids smiling with XOs and other computers running Sugar (preferably with laptops *open*; that bugs me about much of the marketing). Also, Sugar is a nice platform to work on as a developer: clean code, great community, nice looking and progressive UI, cool technologies under the hood, great web infrastructure. Activities tend to be only a thousand or so lines of code. An experienced developer with a good plan can usually crank one out in a weekend. 2) Are there any bite-sized projects (eggs spam) that a hackfest could get involved with over the weekend? Install jhbuild or a SoaS VM and Adopt an activity. We have a page going which lists activities that are unmaintained and need to be adopted, with links to their source: http://wiki.sugarlabs.org/go/Activity_Team/Activity_Status A developer can pick an activity, contact its authors, copy it to the Sugar Labs' infrastructure, make it work well on SoaS, and upload it to activities.sugarlabs.org. If the developer doesn't feel like becoming the support contact for the activity for all time, they can simply list the author as Activity Team and we will take care of maintenance. There are tons more activities that aren't linked on the Activity Status page, just googling for Sugar Activity is likely to turn up dozens of half finished activities in need of maintenance. 3) Are there any main sized meals (eggs, spam, spam, spam spam) that individuals groups can get involved with on this side of the world? E.g. there seems to be *lots* of Sugar going on, but where is the starting line? There are plenty of larger tasks up for grabs. For people interested in writing activities: http://wiki.sugarlabs.org/go/Activity_Team/Project_Ideas For people wishing to work on improving Sugar: http://wiki.sugarlabs.org/go/Features. Finally, there is always bug reproducing, triaging and squashing: http://dev.sugarlabs.org/query?status=acceptedstatus=assignedstatus=newstatus=reopenedcol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=componentorder=priority Best regards, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Talk at New Zealand PyCon : Support from dev team needed
On Mon, Oct 5, 2009 at 11:11 AM, Gary C Martin g...@garycmartin.com wrote: Hi Wade, On 5 Oct 2009, at 14:36, Wade Brainerd wrote: Install jhbuild or a SoaS VM and Adopt an activity. We have a page going which lists activities that are unmaintained and need to be adopted, with links to their source: http://wiki.sugarlabs.org/go/Activity_Team/Activity_Status This is a pretty dead page – both unmaintained and way, way out of date. It needs a real hack, slash and burn to get it into useful shape... Now that you've promoted it, do you agree we should at least delete all the dead wood (stuff already migrated) and tidy things up? To be honest I was hoping we would not have to maintain a wiki blacklist type page of old cruft, but I guess there are still some old activities out there that could do with adopting, though most new arrivals will really be interested in creating something original of their own. Yep! I would love to see it cleaned up, but removal is okay if you think that all value has been obtained from it. I had just added it to my TODO list, along with cleaning up the Activity Team TODO list and Project Ideas pages. Any and all help would of course be greatly appreciated. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Display a message when an activity fails to start
http://dev.sugarlabs.org/ticket/1447 Would love to get some testing on the latest patch! There was an occasional crash bug but it seems to be fixed now. Just make your activity fault during launch and see what happens. Thanks, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Sucrose 0.86 Branching - Activity versions
On Thu, Oct 1, 2009 at 5:20 AM, Simon Schampijer si...@schampijer.dewrote: *Activity versions* As we use integers for activity versions (this really has to change for 0.88 with introducing minor versions), we need to cope for the famous: stable/unstable version issue. I would say to leave at least 3 version numbers open when doing a new unstable release. An example: Walter has submitted TurtleArt 69 for 0.86. He reserves the numbers 70, 71, 72 for bug fix releases. When he is doing a release from the unstable master branch (0.88 development) he is using numbers 72. I'm still against this plan. Does anyone else feel like the integer numbers are a good thing? We have been striving to keep activity releases backwards compatible as far as possible; there should be no need to branch activities for sucrose releases. If a bug is found, sucrose can be updated to the latest version. Regards, -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Sucrose 0.86 Branching - Activity
On Thu, Oct 1, 2009 at 9:47 AM, Michael Stone mich...@laptop.org wrote: Wade wrote: We have been striving to keep activity releases backwards compatible as far as possible; there should be no need to branch activities for sucrose releases. If a bug is found, sucrose can be updated to the latest version. Perhaps you meant that the activity can be updated to the latest version? That's right- I meant that sucrose can be changed to reference the latest version of the activity. Thanks for the clarification, -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Activity version compatibility
BTW, we should still answer the question of the activity.info field... Seems like there 3 options to me: 1) Deprecate host_version in the activity.info spec. Activity developers write code to test for presence non-BC APIs and provide fallbacks (or else let activities fail to launch/work). 2) Keep host_version as an incrementing number, make activityfactory respect it, and bump the Sugar number from 1 to 2 in 0.86.1 to reflect the toolbar changes. 3) Deprecate host_version, introduce sugar_version which is set to the oldest Sugar version number the activity is compatible with. I'm fine with any of these, let me know and I'll provide the patch. -Wade On Tue, Sep 29, 2009 at 12:12 PM, Gary C Martin g...@garycmartin.comwrote: On 29 Sep 2009, at 14:00, Wade Brainerd wrote: On Mon, Sep 28, 2009 at 8:15 PM, Gary C Martin g...@garycmartin.com wrote: I have a prototype patch which fixes the launch window and adds an error message. I'll try to get it posted soon. Cool :-) Ok, a prototype patch is posted at http://dev.sugarlabs.org/ticket/1447. When an activity fails to start, it immediately displays a Name failed to start. with a close button. If anyone can test it out I would greatly appreciate it. Also if you have a theory about the occasional segfault when clicking Close, or know how to get a traceback when running jhbuild, let me know. Fantastic, looks great, I'm hacking on new Labyrinth toolbars just now so, I will apply this and test it on all the tracebacks I get ;-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Activity version compatibility
Hey Bert, I wasn't aware of host_version - it looks like it's supported for content bundles, with any value other than 1 (hardcoded) raising a MalformedBundleException. It's ignored for activity bundles. So basically it was written into the spec and then dropped. I suppose we could resurrect host_version, or else add the new field. I'm open to either avenue. (Though I feel like just using the Sugar version as the value would be simpler than maintaining an independent version number) -Wade On Mon, Sep 28, 2009 at 7:43 AM, Bert Freudenberg b...@freudenbergs.dewrote: (moving to devel list) I thought that's what host_version is for? - Bert - On 28.09.2009, at 02:40, Wade Brainerd wrote: Tentative patches posted to http://dev.sugarlabs.org/ticket/1442. An Alert when attempting to install the .xo bundle would be really nice, but this at least prevents the activity from appearing in the list. It also adds the raw data, which could be displayed in the bundle's metadata. -Wade On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd wad...@gmail.com wrote: This might be a good time to introduce an optional sugar_version=... field into activity.info, so we can display a human readable error message when this mistake happens. The activity will not launch unless Sugar's version is greater than or equal to the activity.info field. Most activities will not need it, but in case of using non-backwards compatible APIs it will be handy. Is this too big a change to patch 0.84 and 0.86 with? It will take at least two releases before it can have any real benefit. Regards, -Wade On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin g...@garycmartin.com wrote: Hi Gerald, Many thanks for the feedback. On 27 Sep 2009, at 02:52, Gerald Ardito wrote: Gary, This image came from Caroline Meeks at Solution Grove. It came as part of a version of SOAS that she put together for me. Gerald OK, looks like a SoaS build mistake. Caroline, just a quick ping. Checking activities.sugarlabs.org, it tells me Write-63 was the last version compatible with Sugar 0.84.x. I believe Aleksey started working on the new 0.85.x toolbar code as of version 64, breaking compatibility with earlier versions of Sugar: http://activities.sugarlabs.org/en-US/sugar/addons/versions/4201 Regards, --Gary ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Activity version compatibility
On Mon, Sep 28, 2009 at 3:42 PM, Gary C Martin g...@garycmartin.com wrote: My main concern is, how will most developers know what versions of Sugar their activity will work under? This is going to be an ever growing .info string that will need constant maintenance once added. Will it be a white list of sugar versions, a black list of sugar versions, a combination of both, with omissions assuming it works, or fails? So we end up with something like this in the .info that we may need to update on every release: host_version = +0.82; -0.83; +0.84; +0.86 In the patch I posted, I assume that activities pick the oldest version of Sugar they are compatible with. For example, new Toolbar classes were introduced in 0.86, so the latest Terminal will write: host_version = 0.86.0 If you are a lazy activity developer, you simply write the version that you tested the activity for. There is no + or -, since we assume that Sugar will not break old versions of activities with new releases. This is not a new concept; we have always had the monotonically incrementing host_version. It's just never been incremented (or properly supported) before. I arrived here from a pragmatic place: I cloned Terminal from Gitorious and realized it doesn't launch on my version of Sugar (SoaS Strawberry). I briefly looked into fixing it, but didn't see the immediate way to do that. That left me with two options: 1) Do the work to maintain backwards compatibility 2) Accept that users will experience crashes I'd much rather have a third option, especially if we plan to make further additions to the sugar toolkit along the lines of the new toolbars. (Aleksey's sugar-ports library does go a long way towards making 1 easier - way to go!) I'd much rather put the effort into fixing the launch pulsing window, so it is not so stupid. It needs to recognise when a process failed to start, and, at the very least, exit quickly back to the rest of the UI. I have a prototype patch which fixes the launch window and adds an error message. I'll try to get it posted soon. [1] I cleaned up Walters TA bug icon for use in the new Log toolbar, but it didn't make it in this time around http://wiki.sugarlabs.org/go/File:Toolbar-bug.png Awesome! Mind if I use this in http://wiki.sugarlabs.org/go/Features/Problem_Reports? Sorry to be seeming to rain a little on the idea of release version checking, but I'm not sure most developers will ever fill this out correctly, and we're better of just being smarter about catching Activity (start-up) tracebacks quickly. And happy to help in this area if folks think this a good direction. I agree that it's not likely that developers will fill it out consistently, but at least they don't ever need to if they don't care about it. It's just a way for activity developers like me who want to inform users that their activities have a limit w.r.t. backwards compatibility. Best, -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Activity version compatibility
Hey Gary, On Mon, Sep 28, 2009 at 8:15 PM, Gary C Martin g...@garycmartin.com wrote: Hmmm. So what happens when Sugar depreciates some API and breaks old activities? Say in a year or so when the core folks decide to remove the old toolbar API code? Or perhaps some of Telepathy and its API which is getting rather overdue for a fix'er'upper effort? Yikes I really hope this never happens - the old toolbar code just depends on GTK, right? And if we drop some part of the collaboration API, couldn't the Sugar team at least include a compatibility shim? I guess it'll always come down to a decision about how many activities are being broken and how likely they are to be fixed. 1) Do the work to maintain backwards compatibility See this is where I'm at. I'm very tempted to go back and add the old toolbar support back into Write (I already did this for Calculate and it's not too painful, working on the same for Labyrinth just now). The core devs don't think this is worth the effort, because they want folks to move up to newer versions of Sugar (and get to use all the great new features they have worked on), but the Activity developers also want their activities to be a maximum benefit right now, which means supporting 0.82 for the ~98% of our user base right now. Ok then, I'm inspired :) Is there a list of the activities that have been ported to the new toolbar design somewhere, which need compatibility code written? It didn't seem trivial for Terminal, but it's only a few dozen lines of code after all. If it's just for developers that want to specifically warn that their activity won't work. Why not let them just pop in a try/except around the sensitive API and show an alert within their Activity? If they already know enough to know it will fail, they'll know where and why. Yep - an alert would work, or if there were a way for the activity to pass a human readable launch failure message back to the launcher window we would be all set. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-pippy dependencies
I wouldn't mind seeing a custom PyGame for Sugar (let's call it sugargame). Ryan Gordon made a GTK backend for SDL which would allow the PyGame display to coexist with GTK widgets[1]. Also, Nirav Patel has written a sweet PyGame camera module which supports object tracking etc. There's probably a bunch of other useful stuff that could be rolled into PyGame beyond what the (unmaintained) OLPCGames wrapper provides. -Wade [1] - http://lists.laptop.org/pipermail/games/2007-April/89.html http://lists.laptop.org/pipermail/games/2007-April/89.html On Mon, Sep 28, 2009 at 9:33 PM, Bernie Innocenti ber...@codewiz.orgwrote: Hello, the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples. So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB). The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package. Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Hi Daniel, It sounds like you're advocating major architectural and process shifts to combat hypothetical problems. (Java? C#? I could see JavaScript perhaps :)) Most activities do not require custom binaries. Those that do have solved the problem within the .xo format. If you download Colors! from ASLO, it contains linux32 and linux64 binaries for Python 2.5 and 2.6, plus the source code and a Makefile. The .xo file size is only 700k, and again most activities do not require this. If you want to talk about Activity reliability, there are plenty of pure Python activities with much worse behavior than assuming x86... like failing to start if OFW is not present or if the filesystem is not set up exactly like an XO. To me, something good that has come out of this discussion is that Sugar needs to give better error messages when an activity fails to start. The infinite pulsing icon is kind of criminal since the poor user will assume it's still working. And it needs to support reporting failures to authors somehow - at a minimum we should try and get Log.activity's uploader working once more. I've added this to my TODO list. A quick improvement that could be done right away would be to add a metadata field to activity.info, indicating which versions of Sugar the activity will run on. ASLO could pick up this field when the bundle is loaded and automatically fill in its own information. It could also check Browse's User Agent string and warn before downloading activities to an incompatible Sugar instance. Regards, Wade On Thu, Sep 24, 2009 at 5:51 AM, Daniel Drake d...@laptop.org wrote: Hi, 2009/9/22 Benjamin M. Schwartz bmsch...@fas.harvard.edu: This is incompatible with our (or at least my) goal of allowing users to throw packages around as atomic objects, without internet access and without having to understand anything beyond my friend has Sugar, so it will work. It is also incompatible with allowing novices to generate first-class Activities. And to throw in a contrasting view: I feel it's unrealistic and uninteresting for the field. (even though I would personally be thrilled to see this) Before I go further, I want to re-enumerate the items of discussion and the outstanding problems with the .xo format. First of all the problems with our current activity packaging: 1. Versioning system sucks, in that it's not obvious which version of Sugar's activity-exposed APIs each activity is compatible with and you can't even specify this in the metadata, and hence Sugar can't even reject activities that we know simply will not work on version x.y.z. 2. Because there is no user-friendly way of installing system-level libraries, and the bundles itself cannot specify dependencies to be automatically installed, and even because of a variance of system libraries available on different sugar distros, we end up with a common practice of including precompiled libraries within activities. This is a waste of disk space, makes bundles architecture-specific, sometimes even makes the bundle specific to a certain set of system libraries or a specific ABI even within the same architecture, and includes the usual disadvantages equivalent to regular software using static instead of dynamic linking (if a single bug in a supporting library is uncovered, multiple bits of software must be patched, released, distributed, built, and installed). 3. Sometimes, even though the activity does not require any extra libraries, an activity bundle includes native code -- for example, someone ports a C/GTK+ app to Sugar - this often involves the C code being compiled for Fedora/x86 then bundled up with a Python wrapper inside a .xo bundle. This has some of the same disadvantages as above - it becomes architecture-specific and ABI-specific. and, in addition to solutions to the problems described above, people want: 4. The ability to send a Sugar activity to any other Sugar user, regardless of Sugar version, underlying distribution and version, and even system architecture 5. The ability to modify activities, revert modifications, and share modified versions with other Sugar users. (there are other difficult/controversial things that people want too -- for example, a guarantee that a shared activity instance of ActivityX on Sugar-0.86 will continue to be compatible with the shared activity instance of ActivityX on Sugar-0.94, but I'll try and keep this discussion limited to the .xo bundle format itself) and features that we have already that people regard as important: 6. The ability to create a .xo bundle in a simple way from any platform, and ease of installation onto XO My own thoughts: 1. Versioning scheme - probably the easiest thing to discuss as it can be solved easily within the current format. My vote would be to adopt GNOME's versioning scheme of basing component and application versions on the version number of the platform. e.g.
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Sugar could report an error message on startup: This Activity contains executable code which was not compiled for this platform. Please contact the activity author for support. This would fall into the general category of displaying better error messages when activities fail to start. If ARM becomes a really popular Sugar platform, those authors whose activities embed compiled code will be encouraged by their users to provide updated bundles with binaries for more platforms. I personally feel the simplicity of the .xo bundle format is a big advantage. After years of developing for Sugar, I still have no idea how to compile a .rpm file and have no desire to learn :) One more hurdle to cross when starting out. Best, Wade PS- A friend just told me that whenever his iPhone app crashes for a user, it sends a little log back to a central server (if the user has opted in). The logs are grouped and sent to the app author automatically. What a way to encourage a stable activity ecosystem!! That even gives Apple the ability to theoretically penalize an App author whose activity crashes too often. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Smile activity version 1
Hi Tony, Sorry for taking so long to respond to this one. I had a similar problem in Colors! and solved it by adding a timer event while playback was running: 1350def start_update_timer(self): 1351if self.update_timer: 1352gobject.source_remove(self.update_timer) 1353 1354# The timer priority is chosen to be above PRIORITY_REDRAW (which is PRIORITY_HIGH_IDLE_20, but not defined in PyGTK). 1355self.update_timer = gobject.timeout_add(1, self.update, priority=gobject.PRIORITY_HIGH_IDLE+30) The update event would trigger a paint event and return True when playback was active, else return False if playback was done. When playback was started again it would start the timer running again. This starting and stopping prevents pegging the CPU all the time. Anyway, this might help solve your problem by forcing the event loop to run, although it does sound like the root problem could be a different issue. Best, Wade On Thu, Sep 3, 2009 at 12:02 PM, Tony Anderson t...@olenepal.org wrote: Hi, I am always tempted to blame my code, but the same problem appeared in the Ambulant demo wrapper (player_pygtk.py) on Ubuntu. It appears only in the python wrapper (not the C++ version). The Ambulant team has opened a ticket. The problem appears to be an interaction between the gtk.main() event loop and the Ambulant redraw logic. Player_pygtk.py doesn't call gtk.main but instead uses a loop: while gtk.events_pending(): gtk.main_iteration() I think it is safe to rule out Sugar as a culprit, but not my building of the Ambulant package! Yours, Tony Tomeu Vizoso wrote: On Wed, Sep 2, 2009 at 18:31, Tony Andersont...@olenepal.org wrote: I posted version 1 of the Smile activity to activities.sugarlabs.org. It matches the code posted on gitorious. The Smile activity implements the open source Ambulant SMIL3 player. It plays a variety of media types. More importantly it can play a complex multimedia presentation including text, images, audio, and video using a standard SMIL script. My goal is to use the Smile activity to play children's stories so that they can see the text highlighted karaoke-style while listening to the story's audio track and looking at background images. Similar to the Quiz and ShowNTell activities, the Smile activity plays a bundle with an extension '.smxo' and mime_type 'application/x-smile' which contains the controlling SMIL script and the associated media files. Version 1 has two serious problems. Video playback and multimedia playback does not redraw correctly (playback is advanced by moving the mouse!). In addition, it is possible to replay only be re-selecting the presentation. The pause and stop buttons do not work correctly. I hope that both of these problems will be resolved in version 2 by the end of September. Hi Tony, do you know if the cause for these problems in the Ambulant SMIL3 player or in the activity code? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] Labyrinth-5
On Sat, Apr 11, 2009 at 4:44 AM, Gary C Martin g...@garycmartin.com wrote: Hi Michael, On 11 Apr 2009, at 06:48, Michael Stone wrote: P.S. One notable bug for XO 8.2 distro users, is that adding images from the Journal is currently broken (bumping into rainbow), adding images works fine on sugar-jhbuild and should be fine on Soas distros and xo-rawhide (though I haven't tested there just yet). Gary, Could you please send me a link to a ticket with logs? Sorry if I wasn't clear, it's not a Rainbow bug, but an issue I need to fix in Labyrinth. I had a few early passes at fixing Journal image import integration but not quite there yet. Basically the issue is that Labyrinths image loading code is buried deep down in multiple levels of class and/or Python modules, so I don't have obvious access to the various Activity name spaces for knowing where is safe to save. Line 51 if you want a quick peek: http://git.sugarlabs.org/projects/labyrinth/repos/mainline/blobs/master/src/ImageThought.py Let me take another shot (might have some time on Sunday), alsroot made some changes here after my initial attempts, but I think he was fixing something else, need to catch up with what he was after. A strategy that has worked for me in the past is to chdir to the right directory in the activity module startup. That way you don't have to import sugar modules into low level source code. Another way to deal with it is to use the environment variables instead of the sugar APIs, and just test for the presence of the environment variables before using them. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Unified Objects (was Unified bundles)
On Wed, Apr 8, 2009 at 9:12 AM, Eben Eliason eben.elia...@gmail.com wrote: On Wed, Apr 8, 2009 at 2:20 AM, Aleksey Lim alsr...@member.fsf.org wrote: Proposal. To achieve this target, instead of inventing new versioning scheme in sugar (in addition to Journal), I propose treat Activities as regular Journal objects. I'm a little confused by this comment, as this is already the case. Activities have entries in the Journal just as anything else does, and are, in fact, objects in that sense. They're special objects since they spawn fresh new objects by default, but the activity bundle is still an object in itself, and should be resumable with other activities which understand that object type (develop is one example; a future bundle (zip) activity would be another). I think the Journal is capable of holding activity *bundles* as objects. But the actual activity that you launch lives in /home/user/Activities or in /usr/share/sugar/activities and has no connection back to its downloaded Journal object. It sounds like Aleksey is proposing unpacking the activity bundles into the Journal, which is a really interesting idea! It would certainly provide a future path for activity versioning, promote the creation and modification of activities to be at the same level as creating and modifying activity instances, allow users a way to transfer their created activities around, etc. My only concern is that it might blur activities and activity instances for users, which could inhibit the conceptual development of this important computer concept. Cheers, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Unified Objects (was Unified bundles)
The idea that activities actually exist in the Journal (and only in the Journal) is really exciting to me. To fully realize this, we should unpack their .xo bundles *into their Journal entry directory*, not /home/user/Activities. Also, the default Activities should be present in the Journal, which means the Journal would not be empty at install time. And finally, the Home view should actually be a special view of the Journal, showing all Journal entries that are activities. As Aleksey says, this would open up all kinds of possibilities for alternate Home views which are different views of the Journal. Is this the direction we should be moving in? -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Binary Blobs (was: Re: [IAEP] Fwd: Heart Rate Monitor Peripheral)
I would really like to have an official mechanism for dealing with this, as it's preventing several of my activities from working on SoaS. I used to just include x86 Python 2.5 compiled modules in my bundles, but now we are supporting more architectures. One proposal is to have a build machine which supports cross compiling all our supported architectures, which can compile the blobs. Then we include all the blobs inside the .xo bundle. This is like what OSX does with Application bundles. Another is to support compile-on-install. This requires a build system to be present on the user's machine, which is a steep requirement. I'm leaning towards #1, we just need to work out the details and get it set up. -Wade On Wed, Apr 8, 2009 at 12:00 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Note: Follow up from a discussion on iaep. On Wed, Apr 08, 2009 at 08:31:15AM -0400, Walter Bender wrote: (At one point, Sascha had helped me include a script that would build the appropriate binaries at install time, but that solution depends upon a build environment be installed, which is not the default for most OLPC systems. Oops.) Actually, the latest version contained support for precompiled binary blobs as well (choosing the right one for the architecture and validating currency), but we agreed to pull it from regular TA because it was late in the release cycle. We might try again now (in the 0.86 branch) and see how well it works. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJJ3MorAAoJELpz82VMF3DaqSUH/0ckdAJd8Tidpb41YaaHlhLX hZ3SOEeRt73yjRgJkW75pYQU3jhXka29EJH+QWgwgAUlPTym7samNsMsFUUQQFla uKH0O+u47iWfIzqFslPGHJLXJ0vFZWgcd/uNdF1EB9T/qoY+KrMv9n7JefGGT81L THnUz5rvcem30ajGgmUjZEaRPXdp+TVkbvMIkyZf4de4Qq1FwaOfdr7WCu5nP/Ul nFCWWBjJusyOkNI1yNxrgErKknT5hrvKpH4DbvR99NVj975RGq6JVgVi6VzrXbP0 R5sSO/UIZV7XDpjXjz3RmsuH5ldRAxvRaMFyzESGEVsB/p0lQSvd7zWZ+6gwiu4= =IEcS -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Unified Objects (was Unified bundles)
Wow, you're right- the entire Activity List View is no longer needed! Activities can be erased, starred and tagged from the Journal just like any other entry. The Journal icon can move over into the upper right hand corner of the Home view, taking the List View icon's place. That reinforces the notion that the Activity circle view is just an alternate Journal view. The Journal interface thus moves into the F3 level, making it even more accessible. I love it when improvements result in less code and fewer screens. Eben, would you be onboard with this Home view + Journal list view merging in the UI? Best, Wade On Wed, Apr 8, 2009 at 7:25 PM, Gary C Martin g...@garycmartin.com wrote: On 8 Apr 2009, at 20:17, Wade Brainerd wrote: The idea that activities actually exist in the Journal (and only in the Journal) is really exciting to me. Yes, it's a right old lucky dip mess for what you find in Journal for Activity bundles just now. Old bundle versions that you're not sure if you erase if it will also de-install the newer version of it (I've had this happen a few time but haven't tested behaviour lately); and many bundles missing altogether from Journal as an activity arrived via some other non-journal route to you system (pre-installed, software-update, manual sugar-install-bundle). To fully realize this, we should unpack their .xo bundles *into their Journal entry directory*, not /home/user/Activities. I like it, that would resolve the distros from what seems like using arbitrary directories the user has no control over. Also, the default Activities should be present in the Journal, which means the Journal would not be empty at install time. And finally, the Home view should actually be a special view of the Journal, showing all Journal entries that are activities. As Aleksey says, this would open up all kinds of possibilities for alternate Home views which are different views of the Journal. Yep. The current home list view could die, no need for it, and the default ring view content would show an icon for each unique Activity bundle from the Journal providing the same view we see now. We could use the Journal favourite star for the same purpose as currently in the home list view, so any Activity bundle with a Journal favourite star would appear in the home ring. Home view is then just a view type of the Journal, actually you could finally drop the 'Journal as a separate activity object' and just have a home with a favourite view and (at least one but could be list and grid) journal view. Is this the direction we should be moving in? I do like that it seems to simplify the UI and reduce code needing to be maintained. Regards, --Gary -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
Re: [Sugar-devel] [RELEASE] Terminal v25 (attention distro managers!!)
On Wed, Apr 1, 2009 at 4:59 AM, Simon Schampijer si...@schampijer.dewrote: Tomeu Vizoso wrote: On Tue, Mar 31, 2009 at 22:55, Simon Schampijer si...@schampijer.de wrote: Wade Brainerd wrote: Yeah, v24 introduced tabs. v25 is a bugfix of v24. Hmmm, it has been packaged for Fedora 11 already. And F11 should only contain Sucrose 0.84. Please make clear what Sucrose version it is for when you announce new releases - since otherwise packagers pick it up and put it in 0.84? Wonder if that's a problem for SugarLabs? If a packager wants to include an activity that is not part of the stable release of Sugar that they are shipping, isn't that their choice? Regards, Tomeu Maybe that is right. But it is good to mark it like that. So packagers have the choice. [Sugar-devel] [RELEASE] Terminal v25 (attention distro managers!!) The message sounds more like a serious bug fix release to me :) Cheers, Simon Right, it *was* a serious bugfix of a bug that was introduced in v24 I should have made that more clear that if distro managers are using v23 there was no need to update. But it's not the end of the world, Terminal v25 works fine in 0.84. Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal oddity: metadata with no file?
On Mon, Mar 30, 2009 at 1:29 PM, Gary C Martin g...@garycmartin.com wrote: On 30 Mar 2009, at 17:27, Eben Eliason wrote: 2009/3/30 Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org: On Mon, Mar 30, 2009 at 05:11:46PM +0200, Martin Langhoff wrote: Only if something useful is stored. I was wrong to point a finger to Browse - the culprit is Terminal. Try the latest version of Terminal. It does store both current working directory and the scrollbuffer (awesome, BTW!). Fantastic! I've been awaiting that improvement. Does it restore the command history as well (and the environment, too, preferably)? I think that would be exceedingly useful, and would give even more reason to store separate terminal sessions for working in various directories, or on various projects. Just covers journal save/resume of tabs, scrollback and working directory so far – but that makes a big difference already for folks who live on the Terminal side :-) I do hope to eventually add environment save/restore, among other things. You should take a look from a UI design point of view as Wade added multiple tab support (toolbar buttons for tab add/remove and navigation, with the new tabs appearing along the bottom of the screen, a little like IRC does for rooms). I can see other Activity developers may pick up on this style so you might want to give it a once over re the design; perhaps at least standardise on some toolbar icons for tab functionality so other developers know what's good to pick-up on. http://dev.sugarlabs.org/ticket/648#comment:1 Yeah, I would love to see some better theming for gtk.Notebook - or an alternate Sugar toolkit class specifically for tabs. And tab specific toolbar icons would also be most welcome. I currently have: Open New Tab, Close Tab, Next Tab and Previous Tab. I also plan to add 'New Tab with Command' which prompts the user for a command using an Alert, and then re-executes that command each time the Terminal instance is resumed. The overall goal is to use the concept of resumable activities to make Terminal more like GNU screen :) Regards, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] StoryBuilder-14
Awesome, thank you! On Fri, Mar 27, 2009 at 2:06 PM, Aleksey Lim alsr...@member.fsf.org wrote: http://activities.sugarlabs.org/en-US/sugar/addon/4073 == Bundle == http://activities.sugarlabs.org/en-US/sugar/downloads/file/25998/xpi/story_builder-14.xo == NEWS == * Shrink screen resolution to 1024x700 from 1200x750 * Store stories in journal instead of files * Run activity with pygame-1.8.x -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Terminal v25 (attention distro managers!!)
http://activities.sugarlabs.org/en-US/sugar/addon/4043 Please update to this new version ASAP. Terminal v24 will not start properly on a clean install of Sugar, when the terminalrc file is not present! == Bundle == http://activities.sugarlabs.org/en-US/sugar/downloads/latest/4043 == Source == http://download.sugarlabs.org/sources/sucrose/fructose/Terminal/Terminal-25.tar.bz2 == NEWS == * Fix exception when starting with no terminalrc. * New translations ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
I've suggested something similar in past years, but Google prefers to avoid students projects working together at all. This includes working together on projects, or having dependencies on the results of other projects. There is a significant failure rate for GSoC projects and it's not fair for one student's success to be dependent on the work of another. If the projects can be made to work 100% independently and yet still complement each other, then we are good. Best, Wade On Thu, Mar 26, 2009 at 1:22 PM, Lucian Branescu lucian.brane...@gmail.comwrote: Hello, I have this proposal http://wiki.sugarlabs.org/go/Webified_Toolkit I've had a chat with mchua and homunq on #sugar, and here's an interesting idea homunq: if you'd need some limited common foundation, but most of your work would then be separate and compatible, you could both schedule the foundation work in the first couple weeks, then say we will then choose whose version of the foundation to standardize on We would both need Gears and some sort of javascript-dbus bridge. Gears should be just a plugin and javascript-dbus could be done through this http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge. Then subzero could focus on the 'framework to build sugar activities with web technologies' part and I could focus on the 'getting web apps like gmail running nicely on sugar'. There's also the choice between webkit/titanium and gecko/xulrunner/hulahop. I think it would be better to use xulrunner, since it's already a Sugar dependency. It shouldn't be significantly slower, but we should do some testing anyway. What do you all think? 2009/3/26 Wade Brainerd wad...@gmail.com: Just to be clear, this is a perfectly normal part of the GSoC application process. Last year with OLPC I had to choose between like 6 different Typing Turtle applications, several of which were quite good. And in the end, none of them was funded by Google. So, we'll analyze your designs, schedules, resumes, related projects, potential for future contribution to the project, etc. and choose the best one to attempt to have funded. That said, getting a head start on the project and getting involved in the community are great ways to ensure success. Check out http://wiki.sugarlabs.org/go/Print_Support for an example of an applicant who has written test programs, had his ideas evaluated several times on the mailing list, laid out a fairly clear technical design, etc. Keep in mind that we have no idea how many students we'll get from Google. So you are not only competing against those who submit a proposal for the same idea, you are competing against all the other project ideas as well. Best, Wade 2009/3/26 Jameson Quinn jameson.qu...@gmail.com Subzero, you have competition. Lucian, you should check out the mailing list threads for talk between Bryan and Felipe; they are talking about much the same ideas you are. Bryan, you should include Lucian in your forwards. This is not intended to endorse either Lucian or Subzero. This is one of our highest-priority projects for GSoC, and it is even conceivable that we could even accept both of your proposals, to be attempted independently. Both of you, feel free to take ideas from each other's proposals, but remember, we're assuming that you are doing that, and we'd like to see you give fair attribution. You're also both welcome to submit a backup proposal on another idea, either from the ideas list or of your own invention; it seems clear that you are both good applicants, and having a backup proposal will help us do you both justice in case you both make the cut. We will not let the presence or absence of backup proposals bias us in which one of you we choose to do the Karma idea. Good luck, may the best proposal win! Jameson 2009/3/24 Bryan Berry br...@olenepal.org http://hg.olenepal.org/6_Maths_CoOrdinates_22_swf/ Subzero, I think this might be a great flash activity to redo for Karma. Let me know if you have trouble running it on your regular machine. It is in Nepali but I think you will be able to figure it out. I really like how it demonstrates the concepts of coordinates and lets kids play w/ those concepts. You can also download our latest stable monster E-Paath bundle from here (224 MB) http://dev.olenepal.org/E-Paath-2/STABLE/ -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo
[Sugar-devel] ars technica
http://arstechnica.com/open-source/news/2009/03/sugar-labs-announces-new-version-of-sugar-learning-platform.ars Nice to see a positive article from Ars (if it is straight from the press release), since they panned just about everything OLPC did. BTW, the release mentions a mind map activity. Have either of the two development branches actually been released yet? -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
