Re: [Sugar-devel] [Marketing] press release opportunity...
On Thu, Jul 30, 2009 at 03:23, Caroline Meekscarol...@solutiongrove.com wrote: On Wed, Jul 29, 2009 at 9:14 PM, Gary C Martin g...@garycmartin.com wrote: On 29 Jul 2009, at 21:35, Walter Bender wrote: Begin handwaving. LiveUSB came from the world of LiveCD and with it came an overlay concept to enable writing in what had been a read-only world. It is not clear that the approach was intended for more than demonstration purposes, in order to show off the power of Fedora Linux. That would suggest that in the long run, we may need to revisit the way in which we manage user data on our images. End handwaving. +1 My gut feeling is we don't want a LiveUSB, we want a bootable USB with a regular install on it. Ideally being installed from a LiveCD, that can either directly boot and demo Sugar, install to a USB stick, or install to a hard-disk. Once booted we'd want the minimum of file writes to maximise a stick lifetime, and reduce the chance of a write landing as a child unplugs. Regards, --Gary +1 except I think that we need it sooner not later. It is the most likely suspect on most of our stick failures. We will have upset teachers and kids if its not more reliable plus added expense and time costs. It is a blocker on: Reading things you've created on your Sugar Stick on a Windows or Mac machine. Createing a VM that can switch stick based users without rebooting out of the native OS- This will help usability quite a bit on the Mac Laptops the GPA will be using next year. I'm going to try to create a spec and publicize our need for help to my network. I'd love help with both parts of that. The http://on-disk.com folks didn't offered their expertise on this? But anyway, we don't _need_ an expert. Rather an advanced linux user that can ask the right questions, read shell scripts, inspect a running system, etc. Already asked in the local linux user groups? Regards, Tomeu Regards, Tomeu -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Karma git, where to put my early UI designs
2009/7/30 Felipe López Toledo zer.subz...@gmail.com I have added u to as a Karma commiter :) After donkeying around (thanks to dsd_ for that expression;-) with cygwin + git + ssh for the better part of the afternoon (lots of swearing and crying included) I went the TortoiseGit + msysgit route and have now finally managed to make the first commit to the Karma repository (don't laugh, I know who you are!). i think u should put the different ui designs in ROOT/ as index1.html, index2.html, indexn.html +1 Okay, I added the current state of things to lessons/quadrilaterals/. Changes compared to yesterday's version: * moved download from a separate tab into the support tab * moved the lesson into an iFrame that loads lesson.html as suggested by Felipe (= this in turn has led to an odd issue as Firefox 3.5 now doesn't seem to load the complete lesson while Chrome 3 does it just fine; need to investigate that) * cleaned out the lesson specific .css and .js files from index.html While building the example I also noticed that the current examples/quadrilaterals lesson doesn't really meet our bundle requirements in terms of naming conventions (e.g. uses activity.(css|js) instead of lesson_name.(css|js)) and file locations (e.g. images in images/ instead of assets/*/images). Mentioning this just as a heads-up in case anyone looks at or works on that code in the future. Christoph 2009/7/29 Christoph Derndorfer christoph.derndor...@gmail.com Okay, then I'll do that for Chakra UI suggestions and put lesson related UI stuff into lesson/. Christoph 2009/7/29 Bryan Berry br...@olenepal.org i think u should put the different ui designs in ROOT/ as index1.html, index2.html, indexn.html On Tue, 2009-07-28 at 20:28 -0500, Felipe López Toledo wrote: Hi Christoph I think you should put the content where it supposed to go. I mean, if you're working around /index.html, then the fie must be /index.html in this way we will have the same content. btw. let me know your username in order to add you as a contributor into the project 2009/7/28 Christoph Derndorfer christoph.derndor...@gmail.com Finally managed to get cygwin + git up and running and now have a clone of mainline on my machine. Now I was wondering where I should put my early UI designs, examples/ or somewhere else? Thanks, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com -- Felipe López Toledo -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com -- Felipe López Toledo -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Assessment in Karma
On Wed, Jul 29, 2009 at 6:28 PM, Bryan Berry br...@olenepal.org wrote: ChristophD, we really need to talk to sunil and kamana about assessment as they probably have a lot of good ideas. Well, actually they created all the assessments for EPaath but we need to abstract their work to something broadly usable. Yes, we definitely need to do that. (Though unfortunately Kamana will be gone all August.) I've also started collected some very brief notes and thoughts at http://wiki.sugarlabs.org/go/Karma/Assessment ps: I intend to use Karma for interactive curriculum development for reasons Bryan Berry talked about a lot. is it time to for us to open a mailing list specific to karma? like sugar-ka...@l.s.o ? Nope, personally I think this would be premature. Let's keep the discussion here on sugar-devel as far as the more technical aspects are concerned, maybe use IAEP for talking about broader educational issues and increase our post frequency on the Karma blog so people who don't want to follow the discussions on the mailing lists can also find out what's going on. Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Assessment in Karma
2009/7/30 Christoph Derndorfer christoph.derndor...@gmail.com: On Wed, Jul 29, 2009 at 6:28 PM, Bryan Berry br...@olenepal.org wrote: ChristophD, we really need to talk to sunil and kamana about assessment as they probably have a lot of good ideas. Well, actually they created all the assessments for EPaath but we need to abstract their work to something broadly usable. Yes, we definitely need to do that. (Though unfortunately Kamana will be gone all August.) I've also started collected some very brief notes and thoughts at http://wiki.sugarlabs.org/go/Karma/Assessment ps: I intend to use Karma for interactive curriculum development for reasons Bryan Berry talked about a lot. is it time to for us to open a mailing list specific to karma? like sugar-ka...@l.s.o ? Nope, personally I think this would be premature. Let's keep the discussion here on sugar-devel as far as the more technical aspects are concerned, maybe use IAEP for talking about broader educational issues and increase our post frequency on the Karma blog so people who don't want to follow the discussions on the mailing lists can also find out what's going on. +1 I feel sorry when I hear that there's some group somewhere around the world doing Sugar stuff and not using the Sugar channels for their work. This means that the people here cannot help them even if we would like to. Regards, Tomeu Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ 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] Wireless connection
Hello, I live in India, there are not so many hotspots here. Is there really, any way with which I can connect wirelessly to the internet without USB modems? There are USB modems wireless connections, Can I connect to them too, WITHOUT actually owning an wireless USB modem? Please Try To Help. Thanks in advance. -- Abhishek Indoria OLPC Support, Volunteer Driven ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] press release opportunity...
Caroline Meeks wrote: On Wed, Jul 29, 2009 at 9:14 PM, Gary C Martin g...@garycmartin.com mailto:g...@garycmartin.com wrote: On 29 Jul 2009, at 21:35, Walter Bender wrote: Begin handwaving. LiveUSB came from the world of LiveCD and with it came an overlay concept to enable writing in what had been a read-only world. It is not clear that the approach was intended for more than demonstration purposes, in order to show off the power of Fedora Linux. That would suggest that in the long run, we may need to revisit the way in which we manage user data on our images. End handwaving. +1 My gut feeling is we don't want a LiveUSB, we want a bootable USB with a regular install on it. Ideally being installed from a LiveCD, that can either directly boot and demo Sugar, install to a USB stick, or install to a hard-disk. Once booted we'd want the minimum of file writes to maximise a stick lifetime, and reduce the chance of a write landing as a child unplugs. Regards, --Gary +1 except I think that we need it sooner not later. It is the most likely suspect on most of our stick failures. We will have upset teachers and kids if its not more reliable plus added expense and time costs. It is a blocker on: * Reading things you've created on your Sugar Stick on a Windows or Mac machine. * Createing a VM that can switch stick based users without rebooting out of the native OS- This will help usability quite a bit on the Mac Laptops the GPA will be using next year. I'm going to try to create a spec and publicize our need for help to my network. I'd love help with both parts of that. I'll throw my two cents in here, too. I agree with Walter that we might need to revisit the whole concept in the long term. However, it's probably the best we can get right now. Let me put it this way: Looking at my recent composes for SoaS, those were around 390 MB. This contains the compressed squashfs image. Because of this compression, it's read-only, but it's also that small. Now in comparison, we could obviously place the whole file tree on a USB key and hack up some magic to make it boot. In fact, that's from what I see already the somehow preferred way used for the XO. But for this, we'd also need to have the file tree uncompressed (since otherwise it would be read-only again). And that could become a problem. The compression works rather well for us, so if we'd try to go this way, we'd definitely need to move the USB key size requirement up (at least 2 GB, if not even more). And then, I'm not really sure if this solves the data corruption issue (which I haven't experienced myself, so far) - because files could get destroyed if the USB key is improperly removed anyway. Caroline, maybe you could explain the way you're using to make these keys, because I've lost track about what the current way is. Regarding reading contents one created in Sugar on Windows / Mac, I think this is still quite some time away. In fact, I'm wondering whether this isn't a datastore related feature. /me thinks about this... Cheers, --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Assessment in Karma
On Thu, 2009-07-30 at 16:46 +0545, Christoph Derndorfer wrote: On Wed, Jul 29, 2009 at 6:28 PM, Bryan Berry br...@olenepal.org wrote: ChristophD, we really need to talk to sunil and kamana about assessment as they probably have a lot of good ideas. Well, actually they created all the assessments for EPaath but we need to abstract their work to something broadly usable. Yes, we definitely need to do that. (Though unfortunately Kamana will be gone all August.) Kamana will probably be at home during that time. You can probably visit her at her home near Patan and discuss it w/ her. I've also started collected some very brief notes and thoughts at http://wiki.sugarlabs.org/go/Karma/Assessment ps: I intend to use Karma for interactive curriculum development for reasons Bryan Berry talked about a lot. is it time to for us to open a mailing list specific to karma? like sugar-ka...@l.s.o ? Nope, personally I think this would be premature. Let's keep the discussion here on sugar-devel as far as the more technical aspects are concerned, maybe use IAEP for talking about broader educational issues and increase our post frequency on the Karma blog so people who don't want to follow the discussions on the mailing lists can also find out what's going on. I think u are right. We should stick to the existing lists until people complain. Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com -- 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] will the one true browse please stand up?
Our site (Holy Mother School, Nashik, India) is having trouble getting the autologin feature of moodle-xs to work. It is suspected that browse is the culprit. I installed browse-102 by customization key on XO-1 build 802, yet suspiciously, this version does not have an edit tab in the toolbar. I have found more than one version of browse-102 (as measured by sha1sum) by downloading from sugarlabs or various different laptop.org pages. Can a person in-the-know assemble a browse-103 release with all the most recent bits? In the future, it would be nice if there was a 1-to-1 mapping between versions and sha1sums. Just a thought. -- American? Vote on the National Initiative for Democracy, http://votep2.us ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] press release opportunity...
As I noted in the wiki page about this: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO#Sticks_are_dieing_a_lot_-_Make_sticks_more_robust 2GB Sticks are $0.60 more then 1GB sticks. If it improves reliability its definitely worth it from a sheer TCO point of view. A full install also makes it possible to browse the files from other operating systems and allows the possiblity of a VM boot helper. On Thu, Jul 30, 2009 at 9:00 AM, Sebastian Dziallas sebast...@when.comwrote: Caroline Meeks wrote: On Wed, Jul 29, 2009 at 9:14 PM, Gary C Martin g...@garycmartin.com mailto:g...@garycmartin.com wrote: On 29 Jul 2009, at 21:35, Walter Bender wrote: Begin handwaving. LiveUSB came from the world of LiveCD and with it came an overlay concept to enable writing in what had been a read-only world. It is not clear that the approach was intended for more than demonstration purposes, in order to show off the power of Fedora Linux. That would suggest that in the long run, we may need to revisit the way in which we manage user data on our images. End handwaving. +1 My gut feeling is we don't want a LiveUSB, we want a bootable USB with a regular install on it. Ideally being installed from a LiveCD, that can either directly boot and demo Sugar, install to a USB stick, or install to a hard-disk. Once booted we'd want the minimum of file writes to maximise a stick lifetime, and reduce the chance of a write landing as a child unplugs. Regards, --Gary +1 except I think that we need it sooner not later. It is the most likely suspect on most of our stick failures. We will have upset teachers and kids if its not more reliable plus added expense and time costs. It is a blocker on: * Reading things you've created on your Sugar Stick on a Windows or Mac machine. * Createing a VM that can switch stick based users without rebooting out of the native OS- This will help usability quite a bit on the Mac Laptops the GPA will be using next year. I'm going to try to create a spec and publicize our need for help to my network. I'd love help with both parts of that. I'll throw my two cents in here, too. I agree with Walter that we might need to revisit the whole concept in the long term. However, it's probably the best we can get right now. Let me put it this way: Looking at my recent composes for SoaS, those were around 390 MB. This contains the compressed squashfs image. Because of this compression, it's read-only, but it's also that small. Now in comparison, we could obviously place the whole file tree on a USB key and hack up some magic to make it boot. In fact, that's from what I see already the somehow preferred way used for the XO. But for this, we'd also need to have the file tree uncompressed (since otherwise it would be read-only again). And that could become a problem. The compression works rather well for us, so if we'd try to go this way, we'd definitely need to move the USB key size requirement up (at least 2 GB, if not even more). And then, I'm not really sure if this solves the data corruption issue (which I haven't experienced myself, so far) - because files could get destroyed if the USB key is improperly removed anyway. Caroline, maybe you could explain the way you're using to make these keys, because I've lost track about what the current way is. Regarding reading contents one created in Sugar on Windows / Mac, I think this is still quite some time away. In fact, I'm wondering whether this isn't a datastore related feature. /me thinks about this... Cheers, --Sebastian -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] review of the new toolbars API
Hi Aleksey, I think this is excellent work, we are very close to commit this and start moving activities to the new toolbars design. Let me share some thoughts about the API before reviewing the actual sugar-toolkit patch. main_toolbar = Toolbar() We already have gtk.Toolbar, which is used by the individual toolbars below the main one. What about calling it MainToolbar or MasterToolbar instead? activity_button = ActivityToolbarButton(self) We have a circular reference here. Would be great if the activity hold a reference to the toolbar button but not the other way around. There may not be a solution that doesn't make it more cumbersome for activity authors, though. In that case this is good. main_toolbar.top.insert(activity_button, 0) What is top and why activity authors need to know about it? Would be great to have it private to the toolbar and have instead an insert method directly in MainToolbar. self.set_toolbox(main_toolbar) Should we add a method set_main_toolbar that does just the same? Would be more consistent for activity authors using the new API. undo = activity_button.undo_button(sensitive=False) main_toolbar.top.insert(undo, -1) In an early conversation I suggested making the func undo_button() a method of ActivityToolbarButton. That was an error, what would be more in line with the existing API is a set of subclasses UndoToolButton, PasteToolButton, etc so people can subclass them and share the same strings, icons, etc. Thanks a lot for your work, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS Getting stuck at the Fedora Login Screen
On Tue, Jul 28, 2009 at 8:07 PM, Caroline Meekscarol...@solutiongrove.com wrote: This week I'm focusing on issue that make it hard to deploy SoaS. One of these is stick failures. I believe there is more then one cause to stick failures so I'm going to try to attack them one a time, we don't have to get it to 0 but right now its a major disruption, almost every class someone has a broken stick. The most common sort of failure mode seems to be that the stick gets stuck at the Fedora Login Screen. Any ideas what is happening? I tested this. Test plan 1) Boot sugar 2) Right click on XO icon, shutdown. 3) When screen turns black, unlug the USB in a presumably unsafe manner 4) Restart with USB to see if it still works I had to do this two times. When I do Shutdown, the screen goes blank with a cursor, if I unplug there it is still OK. Then some text flashes on the screen, (i could to read it). If I unplug there it corrupts the USB. When I boot from the corrupted USB I get the Fedora login screen with no username entered. To fix I took a working SoaS and found the file /LiveOS/overlay-FEDORA-- and I copied that over the broken SoaS, keeping the original overlay-FEDORA-- filename. This is keyed into the boot parameters so you need to make sure it matches. In /syslinux/syslinux.cfg the kernel params root= and overlay= refer to this file. The file is named overlay-LABEL-- where - are apparently random alphanumeric characters. After replacing the overlay, i restarted again and booted sucessfully into sugar. Dave 1. Why do we go there at all during reboot? 2. Sometimes it goes there without liveuser filled in, then its impossible to continue. 3. Sometimes if has liveuser but when you press return it takes you back to the login screen. I wonder if we just have a bug somewhere and its not the sticks fault at all? -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Scaling options for sugar-emulator?
I'm wondering if the options for sugar-emulator are documented somewhere. I couldn't find anything. This is what I'm trying to do: I need to do a desktop recording of Sugar in action. When I try to do this with sugar-emulator running with no options the window size is much too large to record effectively. My computer can't keep up, and even if it could the final video I'd be making would likely be no larger than 640x480 so capturing a larger image should be unnecessary. This morning I tried running sugar-emulator with several values for -i. The one that worked best was -i 1000x600. I could capture this easily and none of the controls on the screen were chopped off. (The controls were larger than I would have liked but they fit). I notice however that sugar-emulator has other options, including one for scale, and I wonder if these options could give me still better results. It is not obvious to me what these options do and how to use them and I could not find a man page for sugar-emulator. The end result needs to be a 640x480 video where everything looks in proportion just like a real Sugar screen would look, or as close to that as possible. What sugar-emulator options can I use to achieve that? I am willing to capture at a larger size and resize the video Thanks, James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Scaling options for sugar-emulator?
try the --dimension option, e.g., --dimension 800x600 -walter On Thu, Jul 30, 2009 at 11:06 AM, Jim Simmonsnices...@gmail.com wrote: I'm wondering if the options for sugar-emulator are documented somewhere. I couldn't find anything. This is what I'm trying to do: I need to do a desktop recording of Sugar in action. When I try to do this with sugar-emulator running with no options the window size is much too large to record effectively. My computer can't keep up, and even if it could the final video I'd be making would likely be no larger than 640x480 so capturing a larger image should be unnecessary. This morning I tried running sugar-emulator with several values for -i. The one that worked best was -i 1000x600. I could capture this easily and none of the controls on the screen were chopped off. (The controls were larger than I would have liked but they fit). I notice however that sugar-emulator has other options, including one for scale, and I wonder if these options could give me still better results. It is not obvious to me what these options do and how to use them and I could not find a man page for sugar-emulator. The end result needs to be a 640x480 video where everything looks in proportion just like a real Sugar screen would look, or as close to that as possible. What sugar-emulator options can I use to achieve that? I am willing to capture at a larger size and resize the video Thanks, James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] review of the new toolbars API
On Thu, Jul 30, 2009 at 03:55:44PM +0200, Tomeu Vizoso wrote: Hi Aleksey, I think this is excellent work, we are very close to commit this and start moving activities to the new toolbars design. Let me share some thoughts about the API before reviewing the actual sugar-toolkit patch. main_toolbar = Toolbar() We already have gtk.Toolbar, which is used by the individual toolbars below the main one. What about calling it MainToolbar or MasterToolbar instead? I've renamed it to ToolbarBox activity_button = ActivityToolbarButton(self) We have a circular reference here. Would be great if the activity hold a reference to the toolbar button but not the other way around. There may not be a solution that doesn't make it more cumbersome for activity authors, though. In that case this is good. main_toolbar.top.insert(activity_button, 0) What is top and why activity authors need to know about it? Would be great to have it private to the toolbar and have instead an insert method directly in MainToolbar. the idea was not duplicating all gtk_toolbar_* methods, so user can use top as a regular GtkToolbar, I guess its a less evil self.set_toolbox(main_toolbar) Should we add a method set_main_toolbar that does just the same? Would be more consistent for activity authors using the new API. now its a set_toolbar_box() undo = activity_button.undo_button(sensitive=False) main_toolbar.top.insert(undo, -1) In an early conversation I suggested making the func undo_button() a method of ActivityToolbarButton. That was an error, what would be more in line with the existing API is a set of subclasses UndoToolButton, PasteToolButton, etc so people can subclass them and share the same strings, icons, etc. I've moved all activity related widgets to sugar.activity.widgets (users still can use deprecated sugar.activity module for these widgets) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wireless connection
On Thu, Jul 30, 2009 at 14:14, Abhishek Indoriahackerboymaya...@gmail.com wrote: Hello, I live in India, there are not so many hotspots here. Is there really, any way with which I can connect wirelessly to the internet without USB modems? There are USB modems wireless connections, Can I connect to them too, WITHOUT actually owning an wireless USB modem? Sugar should be able to connect to wifi and ethernet networks. Can you be more specific about your connectivity needs? Thanks, Tomeu Please Try To Help. Thanks in advance. -- Abhishek Indoria OLPC Support, Volunteer Driven ___ 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] Scaling options for sugar-emulator?
On Thu, Jul 30, 2009 at 10:06:26AM -0500, Jim Simmons wrote: I'm wondering if the options for sugar-emulator are documented somewhere. I couldn't find anything. Guessing from then rest of your message you seem to already have discovered the --help option. I don't think there's anything else, especially since sugar-emulator is barely more than a wrapper around Xephyr. This is what I'm trying to do: I need to do a desktop recording of Sugar in action. When I try to do this with sugar-emulator running with no options the window size is much too large to record effectively. Strange, the default should be 800x600. What does xdpyinfo say? I notice however that sugar-emulator has other options, including one for scale, and I wonder if these options could give me still better results. Currently the only supported values for SUGAR_SCALING (which is what --scale sets) are 72 (regular PC) and 100 (XO). The end result needs to be a 640x480 video where everything looks in proportion just like a real Sugar screen would look, or as close to that as possible. What sugar-emulator options can I use to achieve that? Others may have better suggestions, but how about reducing the capture rate (and doing the manual interactions slowly) instead of the screen size and postprocess the video to reduce screen size and speed it up? It's only a bad hack, but might at least work. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] review of the new toolbars API
On Thu, Jul 30, 2009 at 17:36, Aleksey Limalsr...@member.fsf.org wrote: On Thu, Jul 30, 2009 at 03:55:44PM +0200, Tomeu Vizoso wrote: Hi Aleksey, I think this is excellent work, we are very close to commit this and start moving activities to the new toolbars design. Let me share some thoughts about the API before reviewing the actual sugar-toolkit patch. main_toolbar = Toolbar() We already have gtk.Toolbar, which is used by the individual toolbars below the main one. What about calling it MainToolbar or MasterToolbar instead? I've renamed it to ToolbarBox activity_button = ActivityToolbarButton(self) We have a circular reference here. Would be great if the activity hold a reference to the toolbar button but not the other way around. There may not be a solution that doesn't make it more cumbersome for activity authors, though. In that case this is good. main_toolbar.top.insert(activity_button, 0) What is top and why activity authors need to know about it? Would be great to have it private to the toolbar and have instead an insert method directly in MainToolbar. the idea was not duplicating all gtk_toolbar_* methods, so user can use top as a regular GtkToolbar, I guess its a less evil I just find that the 'top' name leaves too much to guess for the activity author. What about 'toolbar' or 'top_toolbar'? Thanks, Tomeu self.set_toolbox(main_toolbar) Should we add a method set_main_toolbar that does just the same? Would be more consistent for activity authors using the new API. now its a set_toolbar_box() undo = activity_button.undo_button(sensitive=False) main_toolbar.top.insert(undo, -1) In an early conversation I suggested making the func undo_button() a method of ActivityToolbarButton. That was an error, what would be more in line with the existing API is a set of subclasses UndoToolButton, PasteToolButton, etc so people can subclass them and share the same strings, icons, etc. I've moved all activity related widgets to sugar.activity.widgets (users still can use deprecated sugar.activity module for these widgets) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] TamTam sound issues in SoaS
Hi all, today I noticed that there's an issue with TamTam on SoaS which results in no sound being played (except for very short dissonant sounds in TamTamMini). Sebastian noted that this is a known issue and asked me to bring it up on the mailing list so maybe someone can take a look at it and potentially fix it for SoaS v2 due in late November. Flipo later mentioned that Basically there's a small chunk of c code that deals with alsa communication, we had to do this to have proper timing on the xo and this is apparently blocking the correct playback on other non-XO hardware. Anyway, this is about as much as I know, hope someone can do something with this information:-) Thanks, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Current State of OLPC (XO) and Sugar on a Stick
Clarification of Testing Details (test described in previous mail, below): The following update/install commands *were* used relative to Context 3 (and are the ones recommended by Peter): su yum --enablerepo=updates-testing update csound yum install -y csound-python Personal Observations from Results (possibly erroneous?): 1) Out of the box, SoaS comes with OLPCsound (5.08) and Python2.6. Since 5.08 is compatible only with Python2.5, python/Sugar scripts calling Csound can't possibly work. 2) To run from Python, Csound5.10 is dependent upon the csound-python package which, up to now, is not installed with a 5.10 update (from updates-testing). Again, python/Sugar scripts can't possibly work. 3) Currently, when attempting to install csound-python there are dependency/version issues (csound-python vis-a-vis Csound5.10) that disallow the install of csound-python. (Scripts can't possibly work.) Peter says that the dependency/version issues will be resolved as soon as python and csound5.10 get working properly together. (Unfortunately, I'm unable at present to get them both on my USB drive. Do I need to do some rpm magic of which I'm unaware?) This, from the user standpoint, is the current state of affairs. I'm *most* hopeful that these issues can be resolved prior to the offering of SoaS-2. I'll help in any way I can Art Hunkins - Original Message - From: Peter Robinson pbrobin...@gmail.com To: Art Hunkins abhun...@uncg.edu Sent: Wednesday, July 29, 2009 3:11 AM Subject: Re: Current State of OLPC (XO) and Sugar on a Stick On Wed, Jul 29, 2009 at 3:57 AM, Art Hunkinsabhun...@uncg.edu wrote: I did a rather comprehensive test this evening working with Csound materials in the context of the OLPC (XO) and Sugar on a Stick. Here are the results. I'd appreciate continued help to resolve the outstanding issues. Three tests: Test 1: Running a .csd file from the terminal. ALSA driver specified Test 2: Running a .csd file from python from the terminal. No audio driver specified. Test 3: Running a .csd file as part of an Activity (python script) within Sugar. No driver specified. Context 1: On the OLPC (XO) computer (OLPCsound - 5.08.91) - out of the box Test 1: ran fine; ALSA driver used Test 2: ran fine; ALSA driver used Test 3: ran fine; ALSA driver used Obviously no problems here - except the limitation to OLPCsound (5.08) I configured a completely new USB stick (in Windows) to run the remaining tests. Context 2: Sugar on a Stick - out of the box (OLPCsound - 5.08.91) - no updates Test 1: ran fine; ALSA driver used Test 2: fails - cannot import csnd (note: csound-python is not present) Test 3: fails - during import _csnd; in libcsnd.so.5.1: undefined symbol: csoundGetInputBuffer Note: csnd.py, _csnd.so etc. *are* present in the /site-packages folder Context 3: SoaS with updates-testing update csound (to 5.10.1-9.fc11): includes fltk but not csound-python Test 1: ran fine; ALSA driver used Test 1 rerun, with *no driver specified*: fails - unknown rtaudio module: PortAudio This is the new audio driver glitch I referred to in the previous mail below. Note that the XO (5.08) install doesn't suffer this problem. Test 2: fails - cannot import csnd; no module named csnd Test 3: fails - cannot import csnd; no module named csnd Notes: *Before* Context 3, I tried to upgrade Csound by doing an install csound-python. (During a previous try at this, the install upgraded to a compatible build of 5.10; but not this time!) Csound-python would not install because it: conflicts with 5.08.92-15 (the existing OLPCsound). So, you must update Csound first, apparently. However... *After* Context 3, I tried another install csound-python. This time it fails with: requires csound 5.10.1.7.fc11 (a slight downgrade). Thus in this test sequence I was unable to test the latest of Peter's 5.10 Fedora builds with csound-python. (Since I believe I was able to do this before, and since Peter has not changed anything in the meantime, I'm at a loss to explain this result. Perhaps I ungraded/installed things in a different order? In any case, even when csound-python *was* installed I got the same results as the failures above, FWIW. Thinking about this again, I suspect you haven't enabled the updates-testing repository and that's why your not getting the latest csound group of packages. You still haven't given me a non sugar command line test to enable me to easily test any changes I might make. Think a hello world style app. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] review of the new toolbars API
On Thu, Jul 30, 2009 at 05:39:47PM +0200, Tomeu Vizoso wrote: On Thu, Jul 30, 2009 at 17:36, Aleksey Limalsr...@member.fsf.org wrote: On Thu, Jul 30, 2009 at 03:55:44PM +0200, Tomeu Vizoso wrote: Hi Aleksey, I think this is excellent work, we are very close to commit this and start moving activities to the new toolbars design. Let me share some thoughts about the API before reviewing the actual sugar-toolkit patch. main_toolbar = Toolbar() We already have gtk.Toolbar, which is used by the individual toolbars below the main one. What about calling it MainToolbar or MasterToolbar instead? I've renamed it to ToolbarBox activity_button = ActivityToolbarButton(self) We have a circular reference here. Would be great if the activity hold a reference to the toolbar button but not the other way around. There may not be a solution that doesn't make it more cumbersome for activity authors, though. In that case this is good. main_toolbar.top.insert(activity_button, 0) What is top and why activity authors need to know about it? Would be great to have it private to the toolbar and have instead an insert method directly in MainToolbar. the idea was not duplicating all gtk_toolbar_* methods, so user can use top as a regular GtkToolbar, I guess its a less evil I just find that the 'top' name leaves too much to guess for the activity author. What about 'toolbar' or 'top_toolbar'? ok, lets use toolbar then Thanks, Tomeu self.set_toolbox(main_toolbar) Should we add a method set_main_toolbar that does just the same? Would be more consistent for activity authors using the new API. now its a set_toolbar_box() undo = activity_button.undo_button(sensitive=False) main_toolbar.top.insert(undo, -1) In an early conversation I suggested making the func undo_button() a method of ActivityToolbarButton. That was an error, what would be more in line with the existing API is a set of subclasses UndoToolButton, PasteToolButton, etc so people can subclass them and share the same strings, icons, etc. I've moved all activity related widgets to sugar.activity.widgets (users still can use deprecated sugar.activity module for these widgets) -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] review of the new toolbars implementation
Hi,
have been looking at the code and have these comments:
+def set_toolbar_box(self, toolbar_box):
+# make more consistent using ToolbarBox instead of Toolbox
+self.set_toolbox(toolbar_box)
Maybe mark set_toolbox as DEPRECATED?
+ToolButton.__init__(self, 'activity-stop',
+tooltip=_('Stop'),
+accelerator='CtrlQ',
+**kwargs)
If you wanted to make me a happier person, you would set the
properties that don't fit in a single line in their own, like
self.props.tooltip = _('Stop') But is fine as-is.
+self.__private = RadioToolButton(
Why two underscores? (There are other instances of this)
+activity.connect('shared', self.__update_share)
Maybe name it self.__update_share_cb instead?
+if shared_activity:
Should be is not None? There are other instances of this.
+self.paste = ToolButton('edit-paste')
Why not using PasteButton?
+button.__palette_label = label
Accessing a private member of another class. (There are other instances of this)
+from sugar.graphics.palette import _PopupAnimation, _PopdownAnimation
Those are privates, we may need to add API to do what you want, or
move a class into s.g.palette. Maybe you need an invoker?
+toolbar = property(get_toolbar)
Would that be a ToolbarBox? Then maybe should we called toolbar_box?
+return bool(self.toolbar) and bool(self._page) and \
+self.toolbar._expanded_page() == self._page
More castings from None to False, specially dangerous as _page could
be a container that evaluates to False even if it's not None.
+self.toolbar._shrink_page(self._page)
Access to private member of another class. There are other instances
around this one.
+expanded = self.toolbar._expanded_page()
Better use nouns for variables, such as expanded_page.
+page_no = self.__notebook.page_num(widget._page)
Abbreviation, can we get something more verbose like page_num or page_number?
+self.__notebook = gtk.Notebook()
Why do we need a notebook?
+class _Palette(gtk.Window):
The palette class is very tricky and is a frequent source of bugs, we
shouldn't duplicate it. Either we add what you need to the existing
Palette, or we split it out in a BasePalette and Palette and then
inherit from BasePalette for this.
+def _align(box_class, widget):
Can we name it _align_center, _align_bottom, etc? As this isn't a
generic alignment func.
-self.connect('clicked', self.__button_clicked_cb)
This is very likely to cause problems in activities that override
do_clicked without knowing what the base class does there. Consider
listening to the signal and calling a method that can be overridden
from there instead.
Thanks!
Tomeu
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] will the one true browse please stand up?
On Thu, Jul 30, 2009 at 8:37 AM, Joshua N Pritikinjpriti...@pobox.com wrote: Our site (Holy Mother School, Nashik, India) is having trouble getting the autologin feature of moodle-xs to work. It is suspected that browse is the culprit. I installed browse-102 by customization key on XO-1 build 802, yet suspiciously, this version does not have an edit tab in the toolbar. I have found more than one version of browse-102 (as measured by sha1sum) by downloading from sugarlabs or various different laptop.org pages. Can a person in-the-know assemble a browse-103 release with all the most recent bits? It looks like Simon has release browse 103 on activities.sugarlabs.org http://activities.sugarlabs.org/en-US/sugar/addon/4024 Would you mind testing that package? david In the future, it would be nice if there was a 1-to-1 mapping between versions and sha1sums. Just a thought. -- American? Vote on the National Initiative for Democracy, http://votep2.us ___ 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] I've fallen, and I can't get up (was: Re: [Marketing] press release opportunity...)
On Thu, Jul 30, 2009 at 09:43:50AM -0400, Caroline Meeks wrote: As I noted in the wiki page about this: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO#Sticks_are_dieing_a_lot_-_Make_sticks_more_robust 2GB Sticks are $0.60 more then 1GB sticks. If it improves reliability its definitely worth it from a sheer TCO point of view. A full install also makes it possible to browse the files from other operating systems and allows the possiblity of a VM boot helper. Please stop this hand-waving and tell us what the problems are, or give us the means to find out. I almost deleted this whole discussion, as I have others on this subject, but I think it might be useful to say: this whole thread is misguided. We don't know the problems in any detail, yet we've decided to call into question the method of creating livecd sticks. It's completely non-productive - so much so that I can't think of how to concisely explain it without resorting to analogy: it's like seeing someone fall down and deciding that we might need to re-design the laws of gravity. What's needed is more information about the problems, as was promised by someone who had the broken USB sticks in their possession. Please, no more hand-waving until someone knows what the problem is. Otherwise we're going to teach the subscribers of this list that they can ignore problem reports from the field because they never contain actionable information. Please stop this hand-waving and tell us what the problems are, or give us the means to find out. Martin pgpD6f6Rd6JuM.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS Getting stuck at the Fedora Login Screen
I still have it, not sure how to poke around inside it, but I'll see if there is a way to mount it and look. Dave On Thu, Jul 30, 2009 at 3:37 PM, Martin Denglermar...@martindengler.com wrote: On Thu, Jul 30, 2009 at 11:03:52AM -0400, Dave Bauer wrote: After replacing the overlay, i restarted again and booted sucessfully into sugar. It'd be interesting to know what was in the overlay. Dave Martin -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? Thanks, Simon attachment: activity_toolbar.png___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. I often copy items from one open instance of an activity to another... e.g., grabbing a passage from a Write doc to paste into another. Keeping both open, as oppose to opening and closing is advantageous (I can alt-tab or use the frame to switch back and forth). But there is not an issue with names in those cases. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. Are there not tool tips? About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS Getting stuck at the Fedora Login Screen
I have updated the wiki with the latest data and a plan for next steps. http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO#Sticks_are_dieing_a_lot_-_Make_sticks_more_robust Basically trying a full install and an OpenSuse stick and seeing if either of those fail as easily. Would anyone like to help with the testing? Thanks, Caroline On Thu, Jul 30, 2009 at 3:45 PM, Dave Bauer dave.ba...@gmail.com wrote: I still have it, not sure how to poke around inside it, but I'll see if there is a way to mount it and look. Dave On Thu, Jul 30, 2009 at 3:37 PM, Martin Denglermar...@martindengler.com wrote: On Thu, Jul 30, 2009 at 11:03:52AM -0400, Dave Bauer wrote: After replacing the overlay, i restarted again and booted sucessfully into sugar. It'd be interesting to know what was in the overlay. Dave Martin -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] community influence on development
On Tue, Jul 28, 2009 at 04:17:56PM -0300, Bert Freudenberg wrote: On 28.07.2009, at 07:22, Martin Dengler wrote: On Tue, Jul 28, 2009 at 03:24:13PM +0545, Daniel Drake wrote: However, I feel like it could be better if the community (who I might even stretch to call customers) could have more influence. [...] What are the options for the community having more of an influence here? Influence on whom? Developers? There are no SugarLabs employed developers. But if we get feedback from the front line, from teachers actually using our software in the field, the volunteer developers I know struggle to find a way to make it easier for them. Nothing beats direct contact with children of course, but even meeting teachers from the deployments and hearing first-hand accounts of the problems (and successes!) is rather motivating. Reading these reports on a mailing list is less emotionally moving but still a great hint at how to prioritize one's spare time. I don't disagree with anything you said, but I'm struggling to see how it's relevant to the OP or my reply. Perhaps by the volunteer developers I know struggle to find a way to make it easier for them you're implying that we need to make it easier for volunteer developers to contribute? The problem is we get way too few feedback. Indeed. - Bert - Martin pgp6cablCXbw6.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On 07/30/2009 10:15 PM, Christian Marc Schmidt wrote: On 7/30/09 4:13 PM, Simon Schampijersi...@schampijer.de wrote: On 07/30/2009 10:02 PM, Walter Bender wrote: On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. I often copy items from one open instance of an activity to another... e.g., grabbing a passage from a Write doc to paste into another. Keeping both open, as oppose to opening and closing is advantageous (I can alt-tab or use the frame to switch back and forth). But there is not an issue with names in those cases. Ok, makes sense. Personally I would like to have the axtivity instance title entry available in the primary toolbar - as I think it is a quite important action. But I see as well the space issue... :/ Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. Are there not tool tips? Not like 'edit', 'view' or something similar. The name of the tab in the old design is gone. Hi Simon--actually, I think we did have a concept for showing tooltips for tabs. Will need to check with Eben--we are set to have a conversation about this and several other issues tonight. Looking great so far... Christian Nice, how could I even have thought a second that this is not thought through, yet ;D Happy designing, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Current State of OLPC (XO) and Sugar on a Stick
*Revised* comprehensive test - working with Csound materials in the context of the OLPC (XO) and Sugar on a Stick. Here are the results. I'd appreciate continued help to resolve the outstanding issues. Three tests: Test 1: Running a .csd file from the terminal. ALSA driver specified Test 2: Running a .csd file from python from the terminal. No audio driver specified. Test 3: Running a .csd file as part of an Activity (python script) within Sugar. No driver specified. Context 1: On the OLPC (XO) computer (OLPCsound - 5.08.91) - out of the box Test 1: ran fine; ALSA driver used Test 2: ran fine; ALSA driver used Test 3: ran fine; ALSA driver used Obviously no problems here - except the limitation to OLPCsound (5.08) I configured a completely new USB stick (in Windows) to run the remaining tests. Context 2: Sugar on a Stick - out of the box (OLPCsound - 5.08.91) - no updates Test 1: ran fine; ALSA driver used Test 2: fails - cannot import csnd (note: csound-python is not present) Test 3: fails - during import _csnd; in libcsnd.so.5.1: undefined symbol: csoundGetInputBuffer Note: csnd.py, _csnd.so etc. *are* present in the /site-packages folder Context 3: SoaS with updates-testing update csound (to 5.10.1-9.fc11), and updates-testing install csound-python (to same version): Test 1: ran fine; ALSA driver used Test 1 rerun, with *no driver specified*: fails - unknown rtaudio module: PortAudio This is the new audio driver glitch I referred to in a previous mail. Note that the original (OLPCsound [5.08]) install doesn't suffer this problem. Test 2: fails - error in csnd.py: import _csnd. No module named _csnd Test 3: fails - error in csnd.py: import _csnd. No module named _csnd Notes: *The Context 3 upgrade requires the following (revised) commands to get the right (latest) builds of both Csound and csound-python installed*: su yum --enablerepo=updates-testing update csound yum --enablerepo=updates-testing install csound-python Thanks to Peter for correcting me on this, and for his ongoing efforts to get this all working. Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] community influence on development
On 30.07.2009, at 22:23, Martin Dengler wrote: On Tue, Jul 28, 2009 at 04:17:56PM -0300, Bert Freudenberg wrote: On 28.07.2009, at 07:22, Martin Dengler wrote: On Tue, Jul 28, 2009 at 03:24:13PM +0545, Daniel Drake wrote: However, I feel like it could be better if the community (who I might even stretch to call customers) could have more influence. [...] What are the options for the community having more of an influence here? Influence on whom? Developers? There are no SugarLabs employed developers. But if we get feedback from the front line, from teachers actually using our software in the field, the volunteer developers I know struggle to find a way to make it easier for them. Nothing beats direct contact with children of course, but even meeting teachers from the deployments and hearing first-hand accounts of the problems (and successes!) is rather motivating. Reading these reports on a mailing list is less emotionally moving but still a great hint at how to prioritize one's spare time. I don't disagree with anything you said, but I'm struggling to see how it's relevant to the OP or my reply. Perhaps by the volunteer developers I know struggle to find a way to make it easier for them you're implying that we need to make it easier for volunteer developers to contribute? No, I meant the volunteer developers are motivated largely by feedback from users of their software. They then do all they can (sometimes even struggling) to help. At least that's what I see with the Etoys developers, which is similar to Sugar in that it's not a scratch-your- own-itch open-source project. - Bert - The problem is we get way too few feedback. Indeed. - Bert - Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I'll have to think about this idea more, but: we could also have the naming alert appear as a palette attached to the stop button, instead. It doesn't change the behavior too much (it requires 2 clicks to stop an activity for the first time if it hasn't been named), but the use of the palette might feel more consistent with Sugar in general. On the other hand, it could be strange to change the behavior of the stop button between the first and other cases. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. Yes, we had some thoughts. We'll hash it out some more. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? I think we should be thinking about this in the general case. Sometimes one will need to reach the other end to reach controls (and (though not for the activity toolbar) this depends on where the toolbar button sits within the primary toolbar). We should make sure that the palette behavior works well in these instances. For instance, it shouldn't disappear immediately on mouse-leave. Perhaps the delay should be longer than for normal palettes, due to their peculiar dimensions. That said, I'd be fine with aligning these buttons to the left in this instance. Eben PS a few notes on the design: 1. Is this screenshot showing the hover state of the toolbar button with the toolbar already locked in? If not, the small arrow beneath the activity icon should still be pointed downwards, to indicate that clicking on the button will lock it into place. It should appear pointing upward only when already locked in. 2. We should fix the style for the text entry so it appears correctly on black backgrounds. 3. I'll get you those scissors tonight, for real this time. Also, can we change the arrow to match those in the mockups? The one shown here competes with the icons themselves. 4. But these are nitpicks. Fantastic work!! Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
Here are the icons we used for the view, edit, and color toolbars, Sugarized of course. If anyone has suggestions for other common toolbars across activities that deserve icons in artwork, let me know. Eben On Thu, Jul 30, 2009 at 6:02 PM, Eben Eliasone...@laptop.org wrote: On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I'll have to think about this idea more, but: we could also have the naming alert appear as a palette attached to the stop button, instead. It doesn't change the behavior too much (it requires 2 clicks to stop an activity for the first time if it hasn't been named), but the use of the palette might feel more consistent with Sugar in general. On the other hand, it could be strange to change the behavior of the stop button between the first and other cases. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. Yes, we had some thoughts. We'll hash it out some more. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? I think we should be thinking about this in the general case. Sometimes one will need to reach the other end to reach controls (and (though not for the activity toolbar) this depends on where the toolbar button sits within the primary toolbar). We should make sure that the palette behavior works well in these instances. For instance, it shouldn't disappear immediately on mouse-leave. Perhaps the delay should be longer than for normal palettes, due to their peculiar dimensions. That said, I'd be fine with aligning these buttons to the left in this instance. Eben PS a few notes on the design: 1. Is this screenshot showing the hover state of the toolbar button with the toolbar already locked in? If not, the small arrow beneath the activity icon should still be pointed downwards, to indicate that clicking on the button will lock it into place. It should appear pointing upward only when already locked in. 2. We should fix the style for the text entry so it appears correctly on black backgrounds. 3. I'll get you those scissors tonight, for real this time. Also, can we change the arrow to match those in the mockups? The one shown here competes with the icons themselves. 4. But these are nitpicks. Fantastic work!! Thanks, Simon attachment: toolbar_edit.svgattachment: toolbar_view.svgattachment: toolbar_colors.svg___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] How big might a full install of Fedora Sugar be?
Id love to try it. Does anyone know where I can find instructions? I am putting off ordering USB Sticks just in case we will need 4GB ones. Does anyone see that as a possibility? Thanks, Caroline -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Physics] Rollerball
Hi, When we had our IRC meeting we talked about adding a rotational actuator that wasn't pinned. I suggested replacing the current motor with this free actuator. What was the concern raised by replacing the motor tool with the rotation actuator? I really think we should replace it completely, at least for now that we don't have a layered toolbar. The behavior I have in mind is somehow like what I showed you but It will apply the same angular acceleration to big and small objects until they reach a max angular velocity. I think that will be quite similar to the motor tool except that it wouldn't be pinned. Greetings, Asaf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wireless connection
On Thu, Jul 30, 2009 at 05:14:40AM -0700, Abhishek Indoria wrote: I live in India, there are not so many hotspots here. Is there really, any way with which I can connect wirelessly to the internet without USB modems? Yes, but only you would be able to locate the services and products. There are USB modems wireless connections, Can I connect to them too, WITHOUT actually owning an wireless USB modem? No. But, if someone who owns a wireless USB modem (a mobile telephone network modem), and they are willing to share that access, then there is a complex method available that uses an XO as a gateway for multiple others. It is a function of Linux. This is handled in the XS, server-devel mailing list. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Karma git, where to put my early UI designs
Hi man! After donkeying around (thanks to dsd_ for that expression;-) with cygwin + git + ssh for the better part of the afternoon (lots of swearing and crying included) I went the TortoiseGit + msysgit route and have now finally managed to make the first commit to the Karma repository (don't laugh, I know who you are!). don't worry... :) Okay, I added the current state of things to lessons/quadrilaterals/. Changes compared to yesterday's version: * moved download from a separate tab into the support tab * moved the lesson into an iFrame that loads lesson.html as suggested by Felipe (= this in turn has led to an odd issue as Firefox 3.5 now doesn't seem to load the complete lesson while Chrome 3 does it just fine; need to investigate that) * cleaned out the lesson specific .css and .js files from index.html yep, I got an error wit ff: Error: uncaught exception: [Exception... Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMCanvasRenderingContext2D.font] nsresult: 0x80004005 (NS_ERROR_FAILURE) location: JS frame :: file:///D:/Documents%20and%20Settings/Administrador/Escritorio/karma3/mainline/lessons/quadrilaterals/js/quadrilaterals.js :: anonymous :: line 153 data: no] line 153: ctx.font = bold 13px sans-serif; I think, it's not the font because it works fine when I load lesson.html on ff mmm, I'll work around this. While building the example I also noticed that the current examples/quadrilaterals lesson doesn't really meet our bundle requirements in terms of naming conventions (e.g. uses activity.(css|js) instead of lesson_name.(css|js)) and file locations (e.g. images in images/ instead of assets/* /images). Mentioning this just as a heads-up in case anyone looks at or works on that code in the future. I worked around the lesson and after that we defined the layout. That's an old version. I'll fix it. Regards. 2009/7/30 Christoph Derndorfer christoph.derndor...@gmail.com 2009/7/30 Felipe López Toledo zer.subz...@gmail.com I have added u to as a Karma commiter :) After donkeying around (thanks to dsd_ for that expression;-) with cygwin + git + ssh for the better part of the afternoon (lots of swearing and crying included) I went the TortoiseGit + msysgit route and have now finally managed to make the first commit to the Karma repository (don't laugh, I know who you are!). i think u should put the different ui designs in ROOT/ as index1.html, index2.html, indexn.html +1 Okay, I added the current state of things to lessons/quadrilaterals/. Changes compared to yesterday's version: * moved download from a separate tab into the support tab * moved the lesson into an iFrame that loads lesson.html as suggested by Felipe (= this in turn has led to an odd issue as Firefox 3.5 now doesn't seem to load the complete lesson while Chrome 3 does it just fine; need to investigate that) * cleaned out the lesson specific .css and .js files from index.html While building the example I also noticed that the current examples/quadrilaterals lesson doesn't really meet our bundle requirements in terms of naming conventions (e.g. uses activity.(css|js) instead of lesson_name.(css|js)) and file locations (e.g. images in images/ instead of assets/*/images). Mentioning this just as a heads-up in case anyone looks at or works on that code in the future. Christoph 2009/7/29 Christoph Derndorfer christoph.derndor...@gmail.com Okay, then I'll do that for Chakra UI suggestions and put lesson related UI stuff into lesson/. Christoph 2009/7/29 Bryan Berry br...@olenepal.org i think u should put the different ui designs in ROOT/ as index1.html, index2.html, indexn.html On Tue, 2009-07-28 at 20:28 -0500, Felipe López Toledo wrote: Hi Christoph I think you should put the content where it supposed to go. I mean, if you're working around /index.html, then the fie must be /index.html in this way we will have the same content. btw. let me know your username in order to add you as a contributor into the project 2009/7/28 Christoph Derndorfer christoph.derndor...@gmail.com Finally managed to get cygwin + git up and running and now have a clone of mainline on my machine. Now I was wondering where I should put my early UI designs, examples/ or somewhere else? Thanks, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com -- Felipe López Toledo -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com -- Felipe López Toledo -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com -- Felipe López Toledo ___ Sugar-devel mailing list
Re: [Sugar-devel] Initial implementation of toolbars design
Hi Eben, On 31 Jul 2009, at 01:18, Eben Eliason wrote: Here are the icons we used for the view, edit, and color toolbars, Sugarized of course. If anyone has suggestions for other common toolbars across activities that deserve icons in artwork, let me know. Eben Share with: is one, unless you're OK with one of the ones I knocked up, though if it's on a secondary palette and primary space isn't anymore an issue, then the full text menu can stay (and make the Activity palette less empty): http://wiki.sugarlabs.org/go/File:Toolbar_mockup_gary_share_with.png http://wiki.sugarlabs.org/go/File:Toolbar_mockup_gary_share_with_v2.png Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 06:02:00PM -0400, Eben Eliason wrote: On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I'll have to think about this idea more, but: we could also have the naming alert appear as a palette attached to the stop button, instead. It doesn't change the behavior too much (it requires 2 clicks to stop an activity for the first time if it hasn't been named), but the use of the palette might feel more consistent with Sugar in general. On the other hand, it could be strange to change the behavior of the stop button between the first and other cases. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. Yes, we had some thoughts. We'll hash it out some more. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? I think we should be thinking about this in the general case. Sometimes one will need to reach the other end to reach controls (and (though not for the activity toolbar) this depends on where the toolbar button sits within the primary toolbar). We should make sure that the palette behavior works well in these instances. For instance, it shouldn't disappear immediately on mouse-leave. Perhaps the delay should be longer than for normal palettes, due to their peculiar dimensions. That said, I'd be fine with aligning these buttons to the left in this instance. Eben PS a few notes on the design: 1. Is this screenshot showing the hover state of the toolbar button with the toolbar already locked in? Nope, in current implementation there is no way to open hover palette if toolbar is locked in If not, the small arrow beneath the activity icon should still be pointed downwards, to indicate that clicking on the button will lock it into place. It should appear pointing upward only when already locked in. 2. We should fix the style for the text entry so it appears correctly on black backgrounds. 3. I'll get you those scissors tonight, for real this time. Also, can we change the arrow to match those in the mockups? The one shown here competes with the icons themselves. What do you mean exactly, position, size or arrows shape (in case of shape it uses paint_arrow gtk function, I guess its much straight forward to use gtk function instead of custom images e.g. using the same shape like arrows in other widgets) 4. But these are nitpicks. Fantastic work!! Thanks, Simon -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Fri, Jul 31, 2009 at 02:21:40AM +0100, Gary C Martin wrote: On 30 Jul 2009, at 20:46, Simon Schampijer wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. OK, next nit pick (apologise as it is clearly a design oversight not implementation issue). Are we suggesting we make all the lovely, really simple, Activities (the ones who have managed to avoid tabs and just a title, keep, stop, and perhaps sharing) now show a 95% empty top bar (with just the activity icon at one end and the stop over at the other). And require popping up and potentially adjusting the canvas sizes to fit the Activity sub toolbar? Just did a very (very) quick/rough dig through. Pippy (though we could finally move run and stop into the toolbar). Maze IRC Chat Typing Turtle EToys (has title, sharing, keep, stop, and other buttons, ) Most (all?) of every MaMaMedia (Slider Puzzle, Jigsaw Puzzle, Poll builder, Story builder Joke Machine, etc...) et al... Ideally I'd like to see an activity icon, and its journal title appearing, so you have the best chance of knowing 'what' you are currently looking at. yeah, good idea OT: Activity icon followed by title makes an activity instance look like the Journal entry row it came from, which would be a good thing, but I couldn't find a reliable design for that formula. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I know what you mean. I did wonder once if a modal activity alert style pop-up, below the activity toolbar, would be less intrusive, and more in context with the activity than a pop-up dialogue that hides most of the Activity context. btw, why not following common way - auto numbering activity instances? e.g. Terminal Activity 1, Terminal Activity 2 ... One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. +1 Extremely good icons are essential or else WE FAIL and walk backwards here. :-( At least this is something we can iterate on before the 0.86 official release that gets documented and pushed out to deployments. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? My vote is for no right align. Put those icons (share with, keep) left aligned near any other icons (perhaps a tag feature can show here in future). My main concern here would be for a child trying to drive the mouse all the way over from the far left of the display, to the far right to hit a target. Regards, --Gary -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] will the one true browse please stand up?
2009/7/31 David Farning dfarn...@sugarlabs.org: On Thu, Jul 30, 2009 at 8:37 AM, Joshua N Pritikinjpriti...@pobox.com wrote: Can a person in-the-know assemble a browse-103 release with all the most recent bits? It looks like Simon has release browse 103 on activities.sugarlabs.org http://activities.sugarlabs.org/en-US/sugar/addon/4024 Would you mind testing that package? That's for Sugar-0.84. Here's the one you want: http://dev.laptop.org/~dsd/py-activities/Browse-102.xo this is the one on the OLPC 8.2 G1G1 activities page. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 10:07 PM, Gary C Marting...@garycmartin.com wrote: Hi Eben, On 31 Jul 2009, at 01:18, Eben Eliason wrote: Here are the icons we used for the view, edit, and color toolbars, Sugarized of course. If anyone has suggestions for other common toolbars across activities that deserve icons in artwork, let me know. Eben Share with: is one, unless you're OK with one of the ones I knocked up, though if it's on a secondary palette and primary space isn't anymore an issue, then the full text menu can stay (and make the Activity palette less empty): http://wiki.sugarlabs.org/go/File:Toolbar_mockup_gary_share_with.png http://wiki.sugarlabs.org/go/File:Toolbar_mockup_gary_share_with_v2.png I think the sharing scope should be indicated by the corresponding zoom level icons. It might be worth keeping the dropdown once we have proper group support, since the name of the group is important and not communicated by the icon itself. Eben Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 10:28 PM, Aleksey Limalsr...@member.fsf.org wrote: On Thu, Jul 30, 2009 at 06:02:00PM -0400, Eben Eliason wrote: On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I'll have to think about this idea more, but: we could also have the naming alert appear as a palette attached to the stop button, instead. It doesn't change the behavior too much (it requires 2 clicks to stop an activity for the first time if it hasn't been named), but the use of the palette might feel more consistent with Sugar in general. On the other hand, it could be strange to change the behavior of the stop button between the first and other cases. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. Yes, we had some thoughts. We'll hash it out some more. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? I think we should be thinking about this in the general case. Sometimes one will need to reach the other end to reach controls (and (though not for the activity toolbar) this depends on where the toolbar button sits within the primary toolbar). We should make sure that the palette behavior works well in these instances. For instance, it shouldn't disappear immediately on mouse-leave. Perhaps the delay should be longer than for normal palettes, due to their peculiar dimensions. That said, I'd be fine with aligning these buttons to the left in this instance. Eben PS a few notes on the design: 1. Is this screenshot showing the hover state of the toolbar button with the toolbar already locked in? Nope, in current implementation there is no way to open hover palette if toolbar is locked in OK, then the arrow should still be pointing down at this point, indicating that clicking the button will lock it in place below. Once locked in, it changes directions to point up indicating that a second click will close it. Refer to: http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#06 If not, the small arrow beneath the activity icon should still be pointed downwards, to indicate that clicking on the button will lock it into place. It should appear pointing upward only when already locked in. 2. We should fix the style for the text entry so it appears correctly on black backgrounds. 3. I'll get you those scissors tonight, for real this time. Also, can we change the arrow to match those in the mockups? The one shown here competes with the icons themselves. What do you mean exactly, position, size or arrows shape (in case of shape it uses paint_arrow gtk function, I guess its much straight forward to use gtk function instead of custom images e.g. using the same shape like arrows in other widgets) I'd like it to match the arrow in the mockups. In fact, I think we've intended to use this filled triangle everywhere in the UI (such as nested menus), so it would be fine to change this at the gtk level. Actually, I thought Ben B. had worked on that at one point, but I never saw the
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 9:21 PM, Gary C Marting...@garycmartin.com wrote: On 30 Jul 2009, at 20:46, Simon Schampijer wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. OK, next nit pick (apologise as it is clearly a design oversight not implementation issue). Are we suggesting we make all the lovely, really simple, Activities (the ones who have managed to avoid tabs and just a title, keep, stop, and perhaps sharing) now show a 95% empty top bar (with just the activity icon at one end and the stop over at the other). And require popping up and potentially adjusting the canvas sizes to fit the Activity sub toolbar? Just did a very (very) quick/rough dig through. That's an interesting question. I'll have to take a look at some of these activities. I actually find it odd that so many wouldn't have any use for buttons or other controls. Perhaps a number of them are revealing these controls in the canvas below instead of using toolbars? For what it's worth, I have always found it a bit odd when activities embed their own custom controls amidst the cross-activity controls. Perhaps we could institute a rule by which the primary toolbar will BE the only toolbar (not a toolbar button) if and only if the activity adds no toolbar controls at all. If, on the other hand, the activity wants their own controls, these would appear in the primary toolbar to the right of the activity icon. Pippy (though we could finally move run and stop into the toolbar). That would be great! Maze IRC Chat Typing Turtle EToys (has title, sharing, keep, stop, and other buttons, ) Etoys has always behaved slightly differently since it's not using GTK. Most (all?) of every MaMaMedia (Slider Puzzle, Jigsaw Puzzle, Poll builder, Story builder Joke Machine, etc...) et al... Ideally I'd like to see an activity icon, and its journal title appearing, so you have the best chance of knowing 'what' you are currently looking at. OT: Activity icon followed by title makes an activity instance look like the Journal entry row it came from, which would be a good thing, but I couldn't find a reliable design for that formula. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I know what you mean. I did wonder once if a modal activity alert style pop-up, below the activity toolbar, would be less intrusive, and more in context with the activity than a pop-up dialogue that hides most of the Activity context. That's a possibility, but as a general rule those alert bars are non-modal. However, clearly any naming alert when stopping the activity must be modal, since it needs to prevent the action from taking place until the dialog is settled. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. +1 Extremely good icons are essential or else WE FAIL and walk backwards here. :-( At least this is something we can iterate on before the 0.86 official release that gets documented and pushed out to deployments. Yup. I think providing a fairly extensive set of default icons would be a good thing, both to help activity developers out, and for consistency in the UI. I'd be happy to help out with this. It would also be nice to extend the default icon set further in general. There are lots of common icons that we should be providing, for the same reasons as above, that just never made it. I have a list, and perhaps many even designed already, somewhere. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? My vote is for no right align. Put those icons (share with, keep) left aligned near any other icons (perhaps a tag feature can show here in future). My main concern here would be for a child trying to drive the mouse all the way over from the far left of the display, to the far right to hit a target. Again, this depends on the context, and where a given toolbar buttons resides within the
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 11:05:19PM -0400, Eben Eliason wrote: On Thu, Jul 30, 2009 at 10:07 PM, Gary C Marting...@garycmartin.com wrote: Hi Eben, On 31 Jul 2009, at 01:18, Eben Eliason wrote: Here are the icons we used for the view, edit, and color toolbars, Sugarized of course. If anyone has suggestions for other common toolbars across activities that deserve icons in artwork, let me know. Eben Share with: is one, unless you're OK with one of the ones I knocked up, though if it's on a secondary palette and primary space isn't anymore an issue, then the full text menu can stay (and make the Activity palette less empty): http://wiki.sugarlabs.org/go/File:Toolbar_mockup_gary_share_with.png http://wiki.sugarlabs.org/go/File:Toolbar_mockup_gary_share_with_v2.png I think the sharing scope should be indicated by the corresponding zoom level icons. its already implemented, see Simon's screenshot It might be worth keeping the dropdown once we have proper group support, since the name of the group is important and not communicated by the icon itself. Eben Regards, --Gary -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 11:10:23PM -0400, Eben Eliason wrote: On Thu, Jul 30, 2009 at 10:28 PM, Aleksey Limalsr...@member.fsf.org wrote: On Thu, Jul 30, 2009 at 06:02:00PM -0400, Eben Eliason wrote: On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Hi Simon, On 29 Jul 2009, at 08:55, Simon Schampijer wrote: FWIW: Picking the top level tool set is going to be a real tough call in a number of cases as we loose toolbar space for each extra tab, plus the activity icon on far left (essential for Activity recognition), plus the stop icon on far right (essential, no questions, no doubts). The features that actually fit in the remaining space may seem quite an arbitrary hotchpotch. Gary, I am not sure I get your arguments right :/ Can you elaborate? What I conclude of all the answers, I think that space in the primary toolbar is an issue. So we need to decide what to put there. Does activity icon and stop icon sounds good to you as well? Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. Personally, I see more the issue of naming an activity, since as said in another post I am not really convinced about the naming alert. I'll have to think about this idea more, but: we could also have the naming alert appear as a palette attached to the stop button, instead. It doesn't change the behavior too much (it requires 2 clicks to stop an activity for the first time if it hasn't been named), but the use of the palette might feel more consistent with Sugar in general. On the other hand, it could be strange to change the behavior of the stop button between the first and other cases. One little thing I am a bit worried about, is that we miss labels for the sub-toolbars. I hope the icons are meaningful enough for the users - but then labels can be misleading as well, and many of our users can't possibly read. Yes, we had some thoughts. We'll hash it out some more. About alignment (attached is a snapshot), should we align the 'share button' and the 'keep one' to the left that the way to get to this button is not so long, when revealing the toolbar? I think we should be thinking about this in the general case. Sometimes one will need to reach the other end to reach controls (and (though not for the activity toolbar) this depends on where the toolbar button sits within the primary toolbar). We should make sure that the palette behavior works well in these instances. For instance, it shouldn't disappear immediately on mouse-leave. Perhaps the delay should be longer than for normal palettes, due to their peculiar dimensions. That said, I'd be fine with aligning these buttons to the left in this instance. Eben PS a few notes on the design: 1. Is this screenshot showing the hover state of the toolbar button with the toolbar already locked in? Nope, in current implementation there is no way to open hover palette if toolbar is locked in OK, then the arrow should still be pointing down at this point, indicating that clicking the button will lock it in place below. Once locked in, it changes directions to point up indicating that a second click will close it. Refer to: http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#06 done If not, the small arrow beneath the activity icon should still be pointed downwards, to indicate that clicking on the button will lock it into place. It should appear pointing upward only when already locked in. 2. We should fix the style for the text entry so it appears correctly on black backgrounds. 3. I'll get you those scissors tonight, for real this time. Also, can we change the arrow to match those in the mockups? The one shown here competes with the icons themselves. What do you mean exactly, position, size or arrows shape (in case of shape it uses paint_arrow gtk function, I guess its much straight forward to use gtk function instead of custom images e.g. using the same shape like arrows in other widgets) I'd like it to match the arrow in the mockups. In fact, I think we've intended to
Re: [Sugar-devel] Initial implementation of toolbars design
On Thu, Jul 30, 2009 at 11:21:27PM -0400, Eben Eliason wrote: On Thu, Jul 30, 2009 at 9:21 PM, Gary C Marting...@garycmartin.com wrote: On 30 Jul 2009, at 20:46, Simon Schampijer wrote: On 07/29/2009 07:03 PM, Gary C Martin wrote: Sorry if that wasn't clear. Activity icon and stop icon are essential. The Activity icon is going to be critical for identifying what activity you are in at a glance, especially if the actual title name is hidden away in a sub toolbar. A downside if we loose the title in the primary toolbar is reinforcement of knowing what activity you are in (say you are copy/pasting between two similar Write documents)... Ok, thanks for the explanation. The differentiation of the running instance of two activities of the same type is a good point. But, does this happen often? I guess many kids will run one activity of each type at a time, and remember performance constraints ;p And one can use the frame to distinguish the activities. OK, next nit pick (apologise as it is clearly a design oversight not implementation issue). Are we suggesting we make all the lovely, really simple, Activities (the ones who have managed to avoid tabs and just a title, keep, stop, and perhaps sharing) now show a 95% empty top bar (with just the activity icon at one end and the stop over at the other). And require popping up and potentially adjusting the canvas sizes to fit the Activity sub toolbar? Just did a very (very) quick/rough dig through. That's an interesting question. I'll have to take a look at some of these activities. I actually find it odd that so many wouldn't have any use for buttons or other controls. Perhaps a number of them are revealing these controls in the canvas below instead of using toolbars? For what it's worth, I have always found it a bit odd when activities embed their own custom controls amidst the cross-activity controls. Perhaps we could institute a rule by which the primary toolbar will BE the only toolbar (not a toolbar button) if and only if the activity adds no toolbar controls at all. If, on the other hand, the activity wants their own controls, these would appear in the primary toolbar to the right of the activity icon. At least in case of MamaMedia activities, I guess the purpose was supporting non-sugar(w/o toolbars) start, but for activities I'm maintaining I hope to switch them to sugar way in some day. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Karma git, where to put my early UI designs
2009/7/31 Felipe López Toledo zer.subz...@gmail.com Hi man! Hola, Okay, I added the current state of things to lessons/quadrilaterals/. Changes compared to yesterday's version: * moved download from a separate tab into the support tab * moved the lesson into an iFrame that loads lesson.html as suggested by Felipe (= this in turn has led to an odd issue as Firefox 3.5 now doesn't seem to load the complete lesson while Chrome 3 does it just fine; need to investigate that) * cleaned out the lesson specific .css and .js files from index.html yep, I got an error wit ff: Error: uncaught exception: [Exception... Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMCanvasRenderingContext2D.font] nsresult: 0x80004005 (NS_ERROR_FAILURE) location: JS frame :: file:///D:/Documents%20and%20Settings/Administrador/Escritorio/karma3/mainline/lessons/quadrilaterals/js/quadrilaterals.js :: anonymous :: line 153 data: no] line 153: ctx.font = bold 13px sans-serif; I think, it's not the font because it works fine when I load lesson.html on ff mmm, I'll work around this. Yeah, I spent some time on this issue last night but I couldn't really come up with a solution... :-( While building the example I also noticed that the current examples/quadrilaterals lesson doesn't really meet our bundle requirements in terms of naming conventions (e.g. uses activity.(css|js) instead of lesson_name.(css|js)) and file locations (e.g. images in images/ instead of assets/* /images). Mentioning this just as a heads-up in case anyone looks at or works on that code in the future. I worked around the lesson and after that we defined the layout. That's an old version. I'll fix it. I think if you're working on / enhancing the quadrilaterals example it makes more sense to base your work on what's stored in lessons/quadrilaterals/lesson.html (instead of fixing the old version) since that basically represent the latest version and ties in nicely with my menu work. Christoph Regards. 2009/7/30 Christoph Derndorfer christoph.derndor...@gmail.com 2009/7/30 Felipe López Toledo zer.subz...@gmail.com I have added u to as a Karma commiter :) After donkeying around (thanks to dsd_ for that expression;-) with cygwin + git + ssh for the better part of the afternoon (lots of swearing and crying included) I went the TortoiseGit + msysgit route and have now finally managed to make the first commit to the Karma repository (don't laugh, I know who you are!). i think u should put the different ui designs in ROOT/ as index1.html, index2.html, indexn.html +1 Okay, I added the current state of things to lessons/quadrilaterals/. Changes compared to yesterday's version: * moved download from a separate tab into the support tab * moved the lesson into an iFrame that loads lesson.html as suggested by Felipe (= this in turn has led to an odd issue as Firefox 3.5 now doesn't seem to load the complete lesson while Chrome 3 does it just fine; need to investigate that) * cleaned out the lesson specific .css and .js files from index.html While building the example I also noticed that the current examples/quadrilaterals lesson doesn't really meet our bundle requirements in terms of naming conventions (e.g. uses activity.(css|js) instead of lesson_name.(css|js)) and file locations (e.g. images in images/ instead of assets/*/images). Mentioning this just as a heads-up in case anyone looks at or works on that code in the future. Christoph 2009/7/29 Christoph Derndorfer christoph.derndor...@gmail.com Okay, then I'll do that for Chakra UI suggestions and put lesson related UI stuff into lesson/. Christoph 2009/7/29 Bryan Berry br...@olenepal.org i think u should put the different ui designs in ROOT/ as index1.html, index2.html, indexn.html On Tue, 2009-07-28 at 20:28 -0500, Felipe López Toledo wrote: Hi Christoph I think you should put the content where it supposed to go. I mean, if you're working around /index.html, then the fie must be /index.html in this way we will have the same content. btw. let me know your username in order to add you as a contributor into the project 2009/7/28 Christoph Derndorfer christoph.derndor...@gmail.com Finally managed to get cygwin + git up and running and now have a clone of mainline on my machine. Now I was wondering where I should put my early UI designs, examples/ or somewhere else? Thanks, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com -- Felipe López Toledo -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com -- Felipe López Toledo -- Christoph Derndorfer co-editor, olpcnews
