[Sugar-devel] Bounties
I wonder if we should try to use bountysource.com to fund a few things we consider strategic for Sugar Labs. Just an idea. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap.
Top posting again, sorry. - Future availability of the XO From my perspective I don't see alternatives to a wait and see approach. Maybe someone more into OLPC things does though... - Hardware alternatives A few good options was brought in the other threads, a couple for deployments * Classmate * Chromebook Another couple more for community evaluation (evaluation, testing, marketing) * Linux compatible ARM boards * Virtualbox We need properly evaluate them, which raise the question of RD resources. - RD resources I feel balance with addressing existing deployments needs is not a question Sugar Labs can or should answer. We should encourage and support both, it's up to companies and volunteers involved to see how much of either they could or should be doing. We are not a company, we have no resources to allocate. But there are lots of concrete things we can do to encourage people to allocate them. I'm really glad to see that Activity Central figured out how to devote resources to RD. I hope you will be able to keep it up and more people will follow that example. We can leverage initiatives like Google Code. We can try crowd funding. We can apply for grants, as we have been doing sometimes successfully. We can keep lowering the barriers for volunteers, we have been making great progress on that. We can finally solve the un-marketability issue, attracting attention and energies and hence hopefully contributions. - Strategy I'm all for talking strategy, free software is usually bad at it but the Sugar community is special... We have people around with skills that normally not easily available to free software projects. Let's leverage that strength. Though if we want doers to productively participate to these discussions, and we obviously do, we need to get more concrete. On Friday, 8 November 2013, David Farning wrote: Daniel recently started a related thread called Tech Roadmap and Sean started a marketing thread related to naming. To reduce confusion I thought that it might be valuable to take a step back and look at an overall Sugar Labs Roadmap. After reviewing the various threads over the last couple of days it seemed that one of the sources of communication has been the 'level' of communication. IE Ecosystem strategy, deployment/organizational strategy, or technical implementation. This has resulted in people, including me, talking past each other rather than to each other. As the ecosystem adopts to the reduced roll of the Association, at least on the laptop side of the project, this might be a good time to re-evaluate the role of Sugar Labs and it's relationships. The three immediate questions appear to be: 1. What is the future availability of XO hardware? What are the alternatives? What hardware choices are deployments going to make for their next and future rounds of purchasing. 2. How effectively does Sugar run on the available hardware options? What will it take to bring Sugar up to a deployment level quality on this hardware? 3. What resources are required to make this happen? In general there seem to be three branches of this decision tree. XOs, commodity laptops and tablets. After considering the hardware issue, a second round of questions is how do we get there? This implies a balance between supporting existing deployments and the RD necessary to make the next step possible. This balance question implies gathering knowledge of existing deployments and their needs. This level of strategy might seem rather hand-wavy or business like :( But, it is helpful for everyone to have an understanding of were the project is going, how we are planning on getting there, and how one's own interest and abilities can add value. -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar tryout (was Re: sugarlabs.org redesign) [Sugar-devel Digest, Vol 61, Issue 55]
The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. Although the hardware specs are a good target for Sugar3, I believe that suggesting a really small box with 5 cables connected to it to showcase a K-9 educational platform, may retract from the feasibility and thoroughness of the project. A decent rooted tablet (ie Nexus 7) running Sugar on top of Linux, even if the performance is not the best, would be much more catchy and maybe suggestive of a Sugar-on-Android to come. You can still do the CuBox thing but not for journalists and teachers. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). This is certainly a good idea but it must work as advertised ie in 1 click after the VM software is installed. I would only add Parallels-VM/VMware appliances since may already be present in these closed OSs and can really provide a single click to Sugar. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar tryout (was Re: sugarlabs.org redesign) [Sugar-devel Digest, Vol 61, Issue 55]
I don't think we should be suggestive of Sugar on a tablet until we have a minimally realistic idea of how to get it done. There is enough talk about this Sugar-on-Android which is not coming... :) Though you are right that the Cubox-i might send the wrong message. I was seeing it more like a vehicle for the software but, yeah, the hardware won't be ignored. It would a better way to demo to developers or possible hardware partners. Another idea. Sugar in a web browser. It would be the easiest to get running for the users and it's consistent with the current direction of development. Lots of work left to have enough activities for it to be a compelling experience... Maybe virtualized Sugar is the short term goal, Sugar in a web browser is the long term one. On Friday, 8 November 2013, Yioryos Asprobounitis wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. Although the hardware specs are a good target for Sugar3, I believe that suggesting a really small box with 5 cables connected to it to showcase a K-9 educational platform, may retract from the feasibility and thoroughness of the project. A decent rooted tablet (ie Nexus 7) running Sugar on top of Linux, even if the performance is not the best, would be much more catchy and maybe suggestive of a Sugar-on-Android to come. You can still do the CuBox thing but not for journalists and teachers. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). This is certainly a good idea but it must work as advertised ie in 1 click after the VM software is installed. I would only add Parallels-VM/VMware appliances since may already be present in these closed OSs and can really provide a single click to Sugar. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Web activities + CoffeeScript
Hi Rogelio, On Thu, Nov 7, 2013 at 5:13 PM, Rogelio Mita rogeliom...@activitycentral.com wrote: Hi all!, working with web activities urges me to use CoffeeScript. - Is there any decision taken on this? - Do you discussed this topic in some occasion? or is irrelevant? It appeared a few times. In January when sugar-web didn't exist: http://lists.sugarlabs.org/archive/sugar-devel/2013-January/041616.html Then in August I wrote, after doing Gears activity: http://lists.sugarlabs.org/archive/sugar-devel/2013-August/05.html (GearSketch) It is written in coffeescript, and after playing for a bit, I can see it as a possible choice for activity developers. Its syntax sugar makes the code look more like the gtk activities written in python. One of the reasons we went for plain js for sugar-web was because of the View Source feature. Well, seems that since I researched a few months ago, Source Maps has improved a lot, and I can see coffee code in the web inspector. If the code breaks or if I add a breakpoint, for example. Nice! Also, GitHub does a nice job displaying only the coffee changes, and hidding the JS changes by default: So yes, it is a potable option for web activity developers. Now, in some real projects it happened to me that I started using Coffe or TypeScript and ended falling back to straight JS. Think about A. the compilation step B. no way to try things in the inspector console C. need to translate code examples and known solutions from JS to Coffee -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar tryout (was Re: sugarlabs.org redesign) [Sugar-devel Digest, Vol 61, Issue 55]
On 11/08/2013 03:28 AM, Daniel Narvaez wrote: I don't think we should be suggestive of Sugar on a tablet until we have a minimally realistic idea of how to get it done. There is enough talk about this Sugar-on-Android which is not coming... :) Though you are right that the Cubox-i might send the wrong message. I was seeing it more like a vehicle for the software but, yeah, the hardware won't be ignored. It would a better way to demo to developers or possible hardware partners. Another idea. Sugar in a web browser. It would be the easiest to get running for the users and it's consistent with the current direction of development. Lots of work left to have enough activities for it to be a compelling experience... Maybe virtualized Sugar is the short term goal,* Sugar in a web browser is the long term one. *Many of these are already available here: http://wiki.sugarlabs.org/go/Sugar_Creation_Kit/sck/Sugar-in-Virtualization http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Virtual_machines There are many distributions where sugar is supported: http://wiki.sugarlabs.org/go/Sugar_Creation_Kit#Linux_distributions_where_Sugar_is_available Tom Gilliard satellit on #sugar, #schoolserver, and #fedora-qa on freenode IRC On Friday, 8 November 2013, Yioryos Asprobounitis wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. Although the hardware specs are a good target for Sugar3, I believe that suggesting a really small box with 5 cables connected to it to showcase a K-9 educational platform, may retract from the feasibility and thoroughness of the project. A decent rooted tablet (ie Nexus 7) running Sugar on top of Linux, even if the performance is not the best, would be much more catchy and maybe suggestive of a Sugar-on-Android to come. You can still do the CuBox thing but not for journalists and teachers. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). This is certainly a good idea but it must work as advertised ie in 1 click after the VM software is installed. I would only add Parallels-VM/VMware appliances since may already be present in these closed OSs and can really provide a single click to Sugar. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ 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] Sugar tryout (was Re: sugarlabs.org redesign) [Sugar-devel Digest, Vol 61, Issue 55]
On Fri, 2013-11-08 at 12:28 +0100, Daniel Narvaez wrote: I don't think we should be suggestive of Sugar on a tablet until we have a minimally realistic idea of how to get it done. There is enough talk about this Sugar-on-Android which is not coming... :) Though you are right that the Cubox-i might send the wrong message. I was seeing it more like a vehicle for the software but, yeah, the hardware won't be ignored. It would a better way to demo to developers or possible hardware partners. Another idea. Sugar in a web browser. It would be the easiest to get running for the users and it's consistent with the current direction of development. Lots of work left to have enough activities for it to be a compelling experience... Maybe virtualized Sugar is the short term goal, Sugar in a web browser is the long term one. On Friday, 8 November 2013, Yioryos Asprobounitis wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. Although the hardware specs are a good target for Sugar3, I believe that suggesting a really small box with 5 cables connected to it to showcase a K-9 educational platform, may retract from the feasibility and thoroughness of the project. Agreed, but when presented as Sugar_on_a_Set_Top_Box, this is not so unusual. Screwed to the back of a monitor, with power from the monitor, and wifi, the wires can be reduced to zero. Iain Brown Douglas A decent rooted tablet (ie Nexus 7) running Sugar on top of Linux, even if the performance is not the best, would be much more catchy and maybe suggestive of a Sugar-on-Android to come. You can still do the CuBox thing but not for journalists and teachers. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). This is certainly a good idea but it must work as advertised ie in 1 click after the VM software is installed. I would only add Parallels-VM/VMware appliances since may already be present in these closed OSs and can really provide a single click to Sugar. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ 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] Bounties
First, we need to decide what are those strategic things. -walter On Fri, Nov 8, 2013 at 3:32 AM, Daniel Narvaez dwnarv...@gmail.com wrote: I wonder if we should try to use bountysource.com to fund a few things we consider strategic for Sugar Labs. Just an idea. -- Daniel Narvaez ___ 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] Sugar Labs Roadmap.
On Fri, Nov 8, 2013 at 5:33 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Top posting again, sorry. - Future availability of the XO From my perspective I don't see alternatives to a wait and see approach. Maybe someone more into OLPC things does though... - Hardware alternatives A few good options was brought in the other threads, a couple for deployments * Classmate Classmate and Classmate variants are already quick wide spread in some deployments, e.g., Argentina * Chromebook At least one deployment is looking at this option. Another couple more for community evaluation (evaluation, testing, marketing) * Linux compatible ARM boards * Virtualbox SoaS is our current offering for Virtualbox (As you pointed out in a previous thread, it is a two-step process to install. In my experience, that is 1 too many for our audience. Something we may be able to address by approaching some of the VM suppliers.) We need properly evaluate them, which raise the question of RD resources. - RD resources I feel balance with addressing existing deployments needs is not a question Sugar Labs can or should answer. We should encourage and support both, it's up to companies and volunteers involved to see how much of either they could or should be doing. +1 That said, the discipline you have imparted on us regarding unit tests is a step that the community can take. Maybe one of our priorities should be to dust off some basic automatic testing for activities as well. OLPC used to have such a system in place. We are not a company, we have no resources to allocate. But there are lots of concrete things we can do to encourage people to allocate them. I'm really glad to see that Activity Central figured out how to devote resources to RD. I hope you will be able to keep it up and more people will follow that example. We can leverage initiatives like Google Code. We can try crowd funding. We can apply for grants, as we have been doing sometimes successfully. We can keep lowering the barriers for volunteers, we have been making great progress on that. We can finally solve the un-marketability issue, attracting attention and energies and hence hopefully contributions. Google Code In starts on Nov. 18. But we can keep adding tasks over the course of the contest. Please don't be shy about suggesting tasks. And we could also use a few more mentors. - Strategy I'm all for talking strategy, free software is usually bad at it but the Sugar community is special... We have people around with skills that normally not easily available to free software projects. Let's leverage that strength. Though if we want doers to productively participate to these discussions, and we obviously do, we need to get more concrete. On Friday, 8 November 2013, David Farning wrote: Daniel recently started a related thread called Tech Roadmap and Sean started a marketing thread related to naming. To reduce confusion I thought that it might be valuable to take a step back and look at an overall Sugar Labs Roadmap. After reviewing the various threads over the last couple of days it seemed that one of the sources of communication has been the 'level' of communication. IE Ecosystem strategy, deployment/organizational strategy, or technical implementation. This has resulted in people, including me, talking past each other rather than to each other. As the ecosystem adopts to the reduced roll of the Association, at least on the laptop side of the project, this might be a good time to re-evaluate the role of Sugar Labs and it's relationships. The three immediate questions appear to be: 1. What is the future availability of XO hardware? What are the alternatives? What hardware choices are deployments going to make for their next and future rounds of purchasing. 2. How effectively does Sugar run on the available hardware options? What will it take to bring Sugar up to a deployment level quality on this hardware? 3. What resources are required to make this happen? In general there seem to be three branches of this decision tree. XOs, commodity laptops and tablets. After considering the hardware issue, a second round of questions is how do we get there? This implies a balance between supporting existing deployments and the RD necessary to make the next step possible. This balance question implies gathering knowledge of existing deployments and their needs. This level of strategy might seem rather hand-wavy or business like :( But, it is helpful for everyone to have an understanding of were the project is going, how we are planning on getting there, and how one's own interest and abilities can add value. -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez
Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
A bit tricky because we don't have that key anymore (but we could come up with some other key combination to enable it). Also, are you planning to use stickers or some other way to add the proper glyths to the keyboard? Happy to explore this with you further. regards. -walter On Fri, Nov 8, 2013 at 12:23 AM, Basanta Shrestha basanta.shres...@olenepal.org wrote: Hi, I am writing this mail seeking a clue on where to start looking to enable Nepali input in XO4. For XO-1 we had nepali keyboard and there was a button just below the enter button which would switch input between English and Nepali. And that was very convenient. But for XO-4 we will just be getting ones with English layout. I was wondering how we can enable nepali keyboard input on it. I can see that the key maping file for nepali is already there under /usr/share/X11/xkb/symbols/ Thank you . -- Basanta Shrestha OLE Nepal ___ 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] Bounties
Yes, certainly, as seen in the various threads we are still figuring out a strategy. I brought this up now because the issue of how to resource work has been coming up a lot in these discussions (and because I just learned about this service). On Friday, 8 November 2013, Walter Bender wrote: First, we need to decide what are those strategic things. -walter On Fri, Nov 8, 2013 at 3:32 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: I wonder if we should try to use bountysource.com to fund a few things we consider strategic for Sugar Labs. Just an idea. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] Sugar tryout (was Re: sugarlabs.org redesign)
At least the virtualbox looks doable and a good way to show Sugar. Gonzalo On Thu, Nov 7, 2013 at 9:44 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 7 November 2013, Sean DALY wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). Thoughts? Other ideas? If we can agree on one or two concrete, realistic approaches, I think we can at least attempt to get them done for 3.102. -- Daniel Narvaez ___ 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] [Marketing] RFC: Make Sugar 0.102 = Sugar 1.0[ Sugar-devel Digest, Vol 61, Issue 43]
I also think w should change the major number when we have something different to show (when we achieved the goal) Gonzalo On Thu, Nov 7, 2013 at 8:02 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Thanks, I now see where I was confused... Normally in developer versioning you bump the major number when you achieved a certain goal (say have an Online experience you can be proud of). Here we are bumping when starting to work towards the goal instead. I don't see that as an issue, just need to be clear about it. So the proposal for next release is version 3.102. Thoughts? Is the rationale clear? Anyone unhappy with it? On Thursday, 7 November 2013, Sean DALY wrote: Daniel - if we can work out where SL is going, we can build a PR story. If we aren't sure, it's better to communicate other aspects (TA Days, Google Code-In, the TripAdvisor grant). I like v3 as a major version, step versions could be called 3.102, 3.103, 3.104 by developers, while marketing would call it 3 and a name. If we are lucky and the name (Online, Touch, Hand, Cloud, or whatever - this needs work) catches on, we can keep it through step versions. It's important to understand that in the complete absence of a marketing/promotion budget (with the exception of the newswire 10-pack which was voted by the SLOBs), effective PR is our chief resource-effective way to build awareness. This means we tell news based on the possibility of press coverage, not automatically every time there is a version. 102 can become v3.102 and we can announce the html/javascript browser approach, ideally associated with a method for teachers to try Sugar - SoaS with extra teacher-friendly bits, or VMs. If that is too ambitious, the v3 marketing push could wait until 3.104. Sugar brand awareness is on the nonexistent end of the scale for our ten million teachers, this means we can set the schedule. It's harder when there is buzz and momentum, a situation we had after SoaS v1 Strawberry. Sean. On Thu, Nov 7, 2013 at 10:53 PM, Daniel Narvaez dwnarv...@gmail.comwrote: I agree with you about major.minor, with major being the marketing version and minor the developers one. Did I get that right? Does anyone disagree? What I'm not sure to understand is which major number you would like to be used for the next release. To make it easier let's say we are currently v2 as Yioryos suggested. My understanding is that * If it's a release we can PR, developers will call it 3.102, marketing 3 + some name. * if we cannot PR it, developers will call it 2.103, marketing... just won't call it :) Is that correct? On Thursday, 7 November 2013, Sean DALY wrote: cc'ing marketing for... a marketing issue Nope, the GTK3 change just passed under the radar. As stated previously I lobbied for a v1 six years ago which is why we are ready for a v2. Or even a v3. For building a PR story I can work with v2 or v3, just not v1. The issue with 2.2, 2.4 is that from a marketing perspective we get boxed into a major number step timeframe irrespective of marketing needs. A major number change should ideally happen when it's ready, or when we need to communicate a major shift. I still think associating the existing numbering behind a major number (e.g. 2.102) keeps continuity. PR will communicate the major number, probably with a name. And not an unmarketable obscure name, either. Sean Sugar Labs Marketing Coordinator On Thu, Nov 7, 2013 at 8:36 PM, Daniel Narvaez dwnarv...@gmail.comwrote: Hmm I suppose the 1.x - 2.x switch would have not made sense to marketing because there wasn't major user visible changes? On Thursday, 7 November 2013, Yioryos Asprobounitis wrote: For sugar developers their is certainly a continuation in development and the current numbering makes a lot of sense. However, looking from outside 0.102 should be Sugar 3.x where 1.x is the original, 2.x is the Gtk3/introspection move and now the html5/jc (online/ultrabook/tablet) version. If you actually consider 0.100 as 3.0 then it can go 3.2, 3.4 etc to keep up with current numbering. Should make marketing happy with minimal disruption. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez ___ 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] [Marketing] RFC: Make Sugar 0.102 = Sugar 1.0[ Sugar-devel Digest, Vol 61, Issue 43]
Hi, I think it's wrong to bump marketing version numbers on acount of technology shifts. I don't see how i'ts relevant for users that we switched to GTK3, or even that it is now possible to build native web activities (it was always possible with a wrapper). I see as a much more interesting development, the sudden appearance in Sugar of user-customizable bits, which have been developed by kids. The ability to customize Sugar has been desired by users from the very beginning, and the freestyle homeview was not sufficient. Kids would even use ASCII art on the nickname to personalize their desktop, sorry learning environment. This is a fun pic: http://blog.laptop.org/wp-content/uploads/2010/03/paraguay-homescreen1.jpg So, maybe Sugar 3.100 is really Your Sugar, or Freedom Sugar or Personal Sugar. Extra points to put the Freedom back in the priorities. Just a little humble opinion, Regards, Sebastian El 08/11/13 07:29, Gonzalo Odiard escribió: I also think w should change the major number when we have something different to show (when we achieved the goal) Gonzalo On Thu, Nov 7, 2013 at 8:02 PM, Daniel Narvaez dwnarv...@gmail.com mailto:dwnarv...@gmail.com wrote: Thanks, I now see where I was confused... Normally in developer versioning you bump the major number when you achieved a certain goal (say have an Online experience you can be proud of). Here we are bumping when starting to work towards the goal instead. I don't see that as an issue, just need to be clear about it. So the proposal for next release is version 3.102. Thoughts? Is the rationale clear? Anyone unhappy with it? On Thursday, 7 November 2013, Sean DALY wrote: Daniel - if we can work out where SL is going, we can build a PR story. If we aren't sure, it's better to communicate other aspects (TA Days, Google Code-In, the TripAdvisor grant). I like v3 as a major version, step versions could be called 3.102, 3.103, 3.104 by developers, while marketing would call it 3 and a name. If we are lucky and the name (Online, Touch, Hand, Cloud, or whatever - this needs work) catches on, we can keep it through step versions. It's important to understand that in the complete absence of a marketing/promotion budget (with the exception of the newswire 10-pack which was voted by the SLOBs), effective PR is our chief resource-effective way to build awareness. This means we tell news based on the possibility of press coverage, not automatically every time there is a version. 102 can become v3.102 and we can announce the html/javascript browser approach, ideally associated with a method for teachers to try Sugar - SoaS with extra teacher-friendly bits, or VMs. If that is too ambitious, the v3 marketing push could wait until 3.104. Sugar brand awareness is on the nonexistent end of the scale for our ten million teachers, this means we can set the schedule. It's harder when there is buzz and momentum, a situation we had after SoaS v1 Strawberry. Sean. On Thu, Nov 7, 2013 at 10:53 PM, Daniel Narvaez dwnarv...@gmail.com wrote: I agree with you about major.minor, with major being the marketing version and minor the developers one. Did I get that right? Does anyone disagree? What I'm not sure to understand is which major number you would like to be used for the next release. To make it easier let's say we are currently v2 as Yioryos suggested. My understanding is that * If it's a release we can PR, developers will call it 3.102, marketing 3 + some name. * if we cannot PR it, developers will call it 2.103, marketing... just won't call it :) Is that correct? On Thursday, 7 November 2013, Sean DALY wrote: cc'ing marketing for... a marketing issue Nope, the GTK3 change just passed under the radar. As stated previously I lobbied for a v1 six years ago which is why we are ready for a v2. Or even a v3. For building a PR story I can work with v2 or v3, just not v1. The issue with 2.2, 2.4 is that from a marketing perspective we get boxed into a major number step timeframe irrespective of marketing needs. A major number change should ideally happen when it's ready, or when we need to communicate a major shift. I still think associating the existing numbering behind a major number (e.g. 2.102) keeps continuity. PR will communicate the major number, probably with a name. And not an unmarketable obscure name, either.
Re: [Sugar-devel] native HTML activity
I think is a interesting development, but also I am worried about include more C code in the toolkit. The true is we don't have enough expertise in the community. By example we have a error closing sugar [1] I am pretty sure is related to one part of code in C, but was not able to solve it, and nobody else solved it neither. And webactivities are just starting, then more changes will be needed. Maybe you can compromise to maintain it as a compatible alternative, available to be used when needed. Gonzalo [1] http://dev.laptop.org/ticket/12593 On Thu, Nov 7, 2013 at 6:36 PM, NoiseEHC noise...@gmail.com wrote: Hi! Just to prove that it can be done, I have hacked a little bit more on the native HTML activity which can be found here: https://github.com/NoiseEHC/sugar-webkit-native I tried to create virtual pages by using WebKit1's or Soap's url rewriting callbacks but it turns out that no matter what you do, the thing wants to use the data from the TCP stream... So I turned to starting a (Soap) HTTP server inside the native activity (on a random port) and it works. Now the activity runs from localhost (/activity and /web subfolders) and there is a virtual folder called /journal. It has only one hacked file, the /journal/journal.html, which has links to all the things in the journal. It queries the journal service via DBUS. I have to tell you that working with GVariant from C is a real PITA, so I did not implement the load/store of the real journal files, but it is clearly possible... (Beware, it leaks every possible resources, it is just a proof of concept.) Now, I do not know what is the problem with WebKit1, it seems to work for me, and at least it does not crash on an XO-1.75 as WebKit2 does. On the other hand I cannot try it on my XO-1.75 as it is not possible anymore to install webkitgtk-devel on the machine as I told you last time... This whole project has the following benefits: - It is much-much faster than the python one. It does matter on an XO. - It does not depend on the WebKitGTK python bindings to be maintained, it can use all WebKitGTK's features. - It does not have a dependency on Node.js. - It does not use WebSocket, which would require using WebKit2... So now it is your decision whether you use it or not. Thanks, Andrew ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
Hi Walter We don't have plans to use stickers at the moment. The stickers won't last long in the hands of kids. But we need to have some mechanism to input Nepali characters. For now we can give them a printout of the keyboard layout. Regards, Basanta On Fri, Nov 8, 2013 at 5:58 PM, Walter Bender walter.ben...@gmail.comwrote: A bit tricky because we don't have that key anymore (but we could come up with some other key combination to enable it). Also, are you planning to use stickers or some other way to add the proper glyths to the keyboard? Happy to explore this with you further. regards. -walter On Fri, Nov 8, 2013 at 12:23 AM, Basanta Shrestha basanta.shres...@olenepal.org wrote: Hi, I am writing this mail seeking a clue on where to start looking to enable Nepali input in XO4. For XO-1 we had nepali keyboard and there was a button just below the enter button which would switch input between English and Nepali. And that was very convenient. But for XO-4 we will just be getting ones with English layout. I was wondering how we can enable nepali keyboard input on it. I can see that the key maping file for nepali is already there under /usr/share/X11/xkb/symbols/ Thank you . -- Basanta Shrestha OLE Nepal ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Basanta Shrestha Network Engineer Open Learning Exchange (OLE) Nepal Tel: +977.1.551, 5520075 Ext. 303 Cell: +977.9818 605110 http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] RFC: Make Sugar 0.102 = Sugar 1.0[ Sugar-devel Digest, Vol 61, Issue 43]
thanks for that Sebastian We haven't had a marketing version number until now (excepting SoaS v1 in 2009 which we implied in our communications was v1), so from a marketing perspective the only question is whether to go v2 or v3. I don't have a strong opinion, but the key is that a marketing version number bump should indeed happen only because of marketing needs and not technical version number changes or on a timetable. Marketing needs can include: * Seizing an opportunity (winning an award, obtaining funding, a milestone such as 3MM Learners, ...) * Technical (Reaching a technological goal, adding compatibility with new/popular hardware, opening up a new line of development) * Partnerships (OLPC, SFC, FSF, Nexcopy, GNOME, Team Chipotle) * Building up our brand values and project identity, highlighting differentiators such as our language support * Showing that we are alive and kicking, keeping buzz momentum going * etc. Concerning technological development, some is uninteresting to teachers (Gtk3), while some is very interesting (try Sugar on a $5 USB stick). There is no direct correlation between how hard the work is and its marketing value. There will be a name, but that needs work, we will keep your suggestions in mind. Sean On Fri, Nov 8, 2013 at 1:48 PM, Sebastian Silva sebast...@fuentelibre.orgwrote: Hi, I think it's wrong to bump marketing version numbers on acount of technology shifts. I don't see how i'ts relevant for users that we switched to GTK3, or even that it is now possible to build native web activities (it was always possible with a wrapper). I see as a much more interesting development, the sudden appearance in Sugar of user-customizable bits, which have been developed by kids. The ability to customize Sugar has been desired by users from the very beginning, and the freestyle homeview was not sufficient. Kids would even use ASCII art on the nickname to personalize their desktop, sorry learning environment. This is a fun pic: http://blog.laptop.org/wp-content/uploads/2010/03/paraguay-homescreen1.jpg So, maybe Sugar 3.100 is really Your Sugar, or Freedom Sugar or Personal Sugar. Extra points to put the Freedom back in the priorities. Just a little humble opinion, Regards, Sebastian El 08/11/13 07:29, Gonzalo Odiard escribió: I also think w should change the major number when we have something different to show (when we achieved the goal) Gonzalo On Thu, Nov 7, 2013 at 8:02 PM, Daniel Narvaez dwnarv...@gmail.comwrote: Thanks, I now see where I was confused... Normally in developer versioning you bump the major number when you achieved a certain goal (say have an Online experience you can be proud of). Here we are bumping when starting to work towards the goal instead. I don't see that as an issue, just need to be clear about it. So the proposal for next release is version 3.102. Thoughts? Is the rationale clear? Anyone unhappy with it? On Thursday, 7 November 2013, Sean DALY wrote: Daniel - if we can work out where SL is going, we can build a PR story. If we aren't sure, it's better to communicate other aspects (TA Days, Google Code-In, the TripAdvisor grant). I like v3 as a major version, step versions could be called 3.102, 3.103, 3.104 by developers, while marketing would call it 3 and a name. If we are lucky and the name (Online, Touch, Hand, Cloud, or whatever - this needs work) catches on, we can keep it through step versions. It's important to understand that in the complete absence of a marketing/promotion budget (with the exception of the newswire 10-pack which was voted by the SLOBs), effective PR is our chief resource-effective way to build awareness. This means we tell news based on the possibility of press coverage, not automatically every time there is a version. 102 can become v3.102 and we can announce the html/javascript browser approach, ideally associated with a method for teachers to try Sugar - SoaS with extra teacher-friendly bits, or VMs. If that is too ambitious, the v3 marketing push could wait until 3.104. Sugar brand awareness is on the nonexistent end of the scale for our ten million teachers, this means we can set the schedule. It's harder when there is buzz and momentum, a situation we had after SoaS v1 Strawberry. Sean. On Thu, Nov 7, 2013 at 10:53 PM, Daniel Narvaez dwnarv...@gmail.comwrote: I agree with you about major.minor, with major being the marketing version and minor the developers one. Did I get that right? Does anyone disagree? What I'm not sure to understand is which major number you would like to be used for the next release. To make it easier let's say we are currently v2 as Yioryos suggested. My understanding is that * If it's a release we can PR, developers will call it 3.102, marketing 3 + some name. * if we cannot PR it, developers will call it 2.103, marketing... just won't call it :) Is that correct? On Thursday, 7
[Sugar-devel] [ASLO] Release Write-94
Activity Homepage: http://activities.sugarlabs.org/addon/4201 Sugar Platform: 0.96 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28818/write-94.xo Release notes: *Improved startup time Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] Sugar tryout (was Re: sugarlabs.org redesign)
Not only doable, has been done for some time now [1,2] and is multi-platform ( what I use to demo Sugar on a Mac) The Oracle PUEL license [3] very interestingly permits free redistribution for educational purposes, opening the possibility of a single installer, ideal for our needs. In the past I have suggested approaching Oracle for a marketing partnership under a CSR (corporate social responsibility) banner. Sean 1. http://wiki.sugarlabs.org/go/VirtualBox 2. https://wiki.sugarlabs.org/go/Sugar_Creation_Kit/VirtualBox 2. https://www.virtualbox.org/wiki/VirtualBox_PUEL On Fri, Nov 8, 2013 at 1:25 PM, Gonzalo Odiard gonz...@laptop.org wrote: At least the virtualbox looks doable and a good way to show Sugar. Gonzalo On Thu, Nov 7, 2013 at 9:44 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On Thursday, 7 November 2013, Sean DALY wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). Thoughts? Other ideas? If we can agree on one or two concrete, realistic approaches, I think we can at least attempt to get them done for 3.102. -- Daniel Narvaez ___ 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] seeking help to enable nepali keyboard input for XO-4
What about a virtual touch keyboard layout? Just wondering? On Fri, Nov 8, 2013 at 8:46 AM, Basanta Shrestha basanta.shres...@olenepal.org wrote: Hi Walter We don't have plans to use stickers at the moment. The stickers won't last long in the hands of kids. But we need to have some mechanism to input Nepali characters. For now we can give them a printout of the keyboard layout. Regards, Basanta On Fri, Nov 8, 2013 at 5:58 PM, Walter Bender walter.ben...@gmail.com wrote: A bit tricky because we don't have that key anymore (but we could come up with some other key combination to enable it). Also, are you planning to use stickers or some other way to add the proper glyths to the keyboard? Happy to explore this with you further. regards. -walter On Fri, Nov 8, 2013 at 12:23 AM, Basanta Shrestha basanta.shres...@olenepal.org wrote: Hi, I am writing this mail seeking a clue on where to start looking to enable Nepali input in XO4. For XO-1 we had nepali keyboard and there was a button just below the enter button which would switch input between English and Nepali. And that was very convenient. But for XO-4 we will just be getting ones with English layout. I was wondering how we can enable nepali keyboard input on it. I can see that the key maping file for nepali is already there under /usr/share/X11/xkb/symbols/ Thank you . -- Basanta Shrestha OLE Nepal ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Basanta Shrestha Network Engineer Open Learning Exchange (OLE) Nepal Tel: +977.1.551, 5520075 Ext. 303 Cell: +977.9818 605110 http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sur] [IAEP] Sugar oversight board meeting
David - what I meant was, no strategic partnership between the distros. Ubuntu wouldn't pose so many difficulties if M. Shuttleworth/Canonical got behind Sugar for example. Sean On Thu, Nov 7, 2013 at 10:46 AM, David Farning dfarn...@activitycentral.com wrote: On Thu, Nov 7, 2013 at 3:07 AM, Sean DALY sdaly...@gmail.com wrote: I'm sorry Sebastian, yes I should have been more clear about which Sebastian :-) At the time, Sugar was perceived as being only available on OLPC XOs, so our effort was designed to show that it was available for other platforms. Indeed, our claim has always been that it was hardware-agnostic (on Mac using virtualization), cf. our press releases (sl.o/press). And, SoaS as a marketing concept was meant to be distro-agnostic too (SuSE...), a position fought tooth and nail by the Fedorans by the way. Pre-tablets, when small netbooks sales were exploding, Windows was dominant on PCs but ran poorly or not at all on netbooks and moreover there was an installation barrier for Windows on GNU/Linux netbooks. We were interested in reaching the 92% or so of teachers using Windows and widening Sugar availability on machines with pre-installed GNU/Linux (all 2% or so of them). Microsoft and Intel worked quickly to block GNU/Linux netbooks by pressuring OEMs to build faster machines, then tablets arrived and killed off netbooks. It's unfortunate that Sugar was not fully embraced by the GNU/Linux distros who missed a great opportunity in the education market where Microsoft had and has weaknesses, but that has been a symptom of free software projects struggling with strategic initiatives while concentrating on technical aspects. How does Sugar on Ubuntu (DXU) and Sugar on Tablets (DX experimental) affect this equation for Sugar Labs? Dismal marketing has contributed to dismal desktop market share (Microsoft's well-documented maneuvers played a role too of course). Installation: As Peter has mentioned, SoaS can be used for installation on a target PC, this is documented in the wiki. Concerning translations, language selection was available in at least several versions of SoaS, I remember switching French and US locale and keyboard demoing SoaS at an Educatec-Educatice convention in Paris. I have no doubt that solutions are possible, but do remember that Peter has been continuing SoaS work singlehandedly for some time now. Looking forward, I see a dual challenge for Sugar Labs: supporting the XO installed base (including hopefully keeping XO-4 availability alive), and transitioning to the wild new world of handheld devices. Sean On Thu, Nov 7, 2013 at 12:21 AM, Sebastian Silva sebast...@fuentelibre.org wrote: El 06/11/13 17:35, Sean DALY escribió: On Mon, Nov 4, 2013 at 11:05 PM, Peter Robinson pbrobin...@gmail.com wrote: But you have for a long time refused to actually even market SoaS! That's right, at the time SoaS became an official Fedora spin, Mel and Sebastian decided to take over marketing, which included coming up with unmarketable names, linking with Fedora announcements, and opening a Fedora hosted minisite (the home of SoaS), none of which was done with any consultation of the SL marketing team. Please try to include last names, you mean Sebastian Dzallas, original developer of Sugar On A Stick. Now that we're on the topic... the concept Sugar On A Stick has several problems. 1.- It suggests it's the only possible Sugar OS on a USB. 2.- It suggests it's not a serious OS to be installed on a computer. 3.- It's impossible to translate. 4.- It suggests it's not regular GNU/Linux, with availability of the Myriad other GNU/Linux educational tools. Regards, Sebastian Silva R+D SomosAzúcar Sugar Labs Perú @icarito ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] Sugar tryout (was Re: sugarlabs.org redesign)
On Fri, Nov 8, 2013 at 9:11 AM, Sean DALY sdaly...@gmail.com wrote: Not only doable, has been done for some time now [1,2] and is multi-platform ( what I use to demo Sugar on a Mac) The Oracle PUEL license [3] very interestingly permits free redistribution for educational purposes, opening the possibility of a single installer, ideal for our needs. In the past I have suggested approaching Oracle for a marketing partnership under a CSR (corporate social responsibility) banner. One issue we bump up against is the stricture to only host FOSS materials. So if we were to have such a partnership, it may have to hosted elsewhere. (VMWare has a similar program) -walter Sean 1. http://wiki.sugarlabs.org/go/VirtualBox 2. https://wiki.sugarlabs.org/go/Sugar_Creation_Kit/VirtualBox 2. https://www.virtualbox.org/wiki/VirtualBox_PUEL On Fri, Nov 8, 2013 at 1:25 PM, Gonzalo Odiard gonz...@laptop.org wrote: At least the virtualbox looks doable and a good way to show Sugar. Gonzalo On Thu, Nov 7, 2013 at 9:44 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 7 November 2013, Sean DALY wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). Thoughts? Other ideas? If we can agree on one or two concrete, realistic approaches, I think we can at least attempt to get them done for 3.102. -- Daniel Narvaez ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing -- 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] [Marketing] Sugar tryout (was Re: sugarlabs.org redesign)
I believe Oracle GPL'd the code itself, as I remember it was the extension pack installer that had licensing issues... in any case, topics for the SFC to help with Sean On Fri, Nov 8, 2013 at 3:40 PM, Walter Bender walter.ben...@gmail.comwrote: On Fri, Nov 8, 2013 at 9:11 AM, Sean DALY sdaly...@gmail.com wrote: Not only doable, has been done for some time now [1,2] and is multi-platform ( what I use to demo Sugar on a Mac) The Oracle PUEL license [3] very interestingly permits free redistribution for educational purposes, opening the possibility of a single installer, ideal for our needs. In the past I have suggested approaching Oracle for a marketing partnership under a CSR (corporate social responsibility) banner. One issue we bump up against is the stricture to only host FOSS materials. So if we were to have such a partnership, it may have to hosted elsewhere. (VMWare has a similar program) -walter Sean 1. http://wiki.sugarlabs.org/go/VirtualBox 2. https://wiki.sugarlabs.org/go/Sugar_Creation_Kit/VirtualBox 2. https://www.virtualbox.org/wiki/VirtualBox_PUEL On Fri, Nov 8, 2013 at 1:25 PM, Gonzalo Odiard gonz...@laptop.org wrote: At least the virtualbox looks doable and a good way to show Sugar. Gonzalo On Thu, Nov 7, 2013 at 9:44 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 7 November 2013, Sean DALY wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). Thoughts? Other ideas? If we can agree on one or two concrete, realistic approaches, I think we can at least attempt to get them done for 3.102. -- Daniel Narvaez ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing -- 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] Sugar tryout (was Re: sugarlabs.org redesign)
I knew it's possible to run Sugar in VirtualBox. I didn't know we was
producing vmdk images, I remember Peter was opposed to that. With those
images, is the installation one-click (reasonably close to it) assuming you
have virtualbox already installed?
The wiki page is terribly complicated...
On Friday, 8 November 2013, Sean DALY wrote:
Not only doable, has been done for some time now [1,2] and is
multi-platform ( what I use to demo Sugar on a Mac)
The Oracle PUEL license [3] very interestingly permits free redistribution
for educational purposes, opening the possibility of a single installer,
ideal for our needs.
In the past I have suggested approaching Oracle for a marketing
partnership under a CSR (corporate social responsibility) banner.
Sean
1. http://wiki.sugarlabs.org/go/VirtualBox
2. https://wiki.sugarlabs.org/go/Sugar_Creation_Kit/VirtualBox
2. https://www.virtualbox.org/wiki/VirtualBox_PUEL
On Fri, Nov 8, 2013 at 1:25 PM, Gonzalo Odiard
gonz...@laptop.orgjavascript:_e({}, 'cvml', 'gonz...@laptop.org');
wrote:
At least the virtualbox looks doable and a good way to show Sugar.
Gonzalo
On Thu, Nov 7, 2013 at 9:44 PM, Daniel Narvaez
dwnarv...@gmail.comjavascript:_e({}, 'cvml', 'dwnarv...@gmail.com');
wrote:
On Thursday, 7 November 2013, Sean DALY wrote:
The larger problem is the absence of a marketing strategy, we need to
know where we are going to communicate effectively. In particular, we need
to choose and implement how to offer Sugar tryout to teachers and
journalists.
I can think of a couple of approaches
* Get Sugar running well on the CuBox-i. Find budget to buy a few of
those to distribute to chosen journalist and teachers. Try to partner with
SolidRun to offer Sugar as an out-of-the-box installation option.
* Make it easy to run Sugar inside VirtualBox on Windows and OS X.
Without having investigated too deeply it seems that a two step process
would be both realistically implementable and easy enough for the user
1 Install virtualbox
2 Install a Sugar application (which would take care of setting up the
appliance).
Thoughts? Other ideas? If we can agree on one or two concrete,
realistic approaches, I think we can at least attempt to get them done for
3.102.
--
Daniel Narvaez
___
Marketing mailing list
market...@lists.sugarlabs.org javascript:_e({}, 'cvml',
'market...@lists.sugarlabs.org');
http://lists.sugarlabs.org/listinfo/marketing
--
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] different perspectives
On Fri, Nov 8, 2013 at 1:56 AM, David Farning dfarn...@activitycentral.comwrote: The highest rate of progress happens when the parties focus on getting ahead of the other guys rather then when they focus on holding others back. Progress tends to stop when one party gets so far ahead that it is not worth it for others to compete. I don't disagree, but I would qualify that: The highest rate of progress happens when the parties focus on getting ahead of the other guys by changing the game. This is why I maintain that GNU/Linux distros considering each other as competitors is pointless at the end of the day when 92% or so of the desktop/laptop market is running MS Windows. Sean ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] Sugar tryout (was Re: sugarlabs.org redesign)
On 11/8/2013 6:55 AM, Daniel Narvaez wrote:
I knew it's possible to run Sugar in VirtualBox. I didn't know we was
producing vmdk images, I remember Peter was opposed to that. With
those images, is the installation one-click (reasonably close to
it) assuming you have virtualbox already installed?
If you have Oracle VirtualBox [2] installed:
Click on the ova icon for:
http://people.sugarlabs.org/Tgillard/sugar_trisquel_6.ova (as an
example) [1][3]
And the file will be imported into VirtualBox
Note:
You can also save this VM as a desktop shortcut from the VirtualBox top
menu.
Machine/Create Shortcut on Desktop
[1] http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Virtual_machines
[2]
http://www.oracle.com/technetwork/server-storage/virtualbox/downloads/index.html
[3]
http://wiki.sugarlabs.org/go/Sugar_Creation_Kit/sck/Sugar-in-Virtualization
Tom Gilliard
satellit
The wiki page is terribly complicated...
On Friday, 8 November 2013, Sean DALY wrote:
Not only doable, has been done for some time now [1,2] and is
multi-platform ( what I use to demo Sugar on a Mac)
The Oracle PUEL license [3] very interestingly permits free
redistribution for educational purposes, opening the possibility
of a single installer, ideal for our needs.
In the past I have suggested approaching Oracle for a marketing
partnership under a CSR (corporate social responsibility) banner.
Sean
1. http://wiki.sugarlabs.org/go/VirtualBox
2. https://wiki.sugarlabs.org/go/Sugar_Creation_Kit/VirtualBox
2. https://www.virtualbox.org/wiki/VirtualBox_PUEL
On Fri, Nov 8, 2013 at 1:25 PM, Gonzalo Odiard gonz...@laptop.org
javascript:_e({}, 'cvml', 'gonz...@laptop.org'); wrote:
At least the virtualbox looks doable and a good way to show
Sugar.
Gonzalo
On Thu, Nov 7, 2013 at 9:44 PM, Daniel Narvaez
dwnarv...@gmail.com javascript:_e({}, 'cvml',
'dwnarv...@gmail.com'); wrote:
On Thursday, 7 November 2013, Sean DALY wrote:
The larger problem is the absence of a marketing
strategy, we need to know where we are going to
communicate effectively. In particular, we need to
choose and implement how to offer Sugar tryout to
teachers and journalists.
I can think of a couple of approaches
* Get Sugar running well on the CuBox-i. Find budget to
buy a few of those to distribute to chosen journalist and
teachers. Try to partner with SolidRun to offer Sugar as
an out-of-the-box installation option.
* Make it easy to run Sugar inside VirtualBox on Windows
and OS X. Without having investigated too deeply it
seems that a two step process would be both realistically
implementable and easy enough for the user
1 Install virtualbox
2 Install a Sugar application (which would take care of
setting up the appliance).
Thoughts? Other ideas? If we can agree on one or two
concrete, realistic approaches, I think we can at least
attempt to get them done for 3.102.
--
Daniel Narvaez
___
Marketing mailing list
market...@lists.sugarlabs.org javascript:_e({}, 'cvml',
'market...@lists.sugarlabs.org');
http://lists.sugarlabs.org/listinfo/marketing
--
Daniel Narvaez
___
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] seeking help to enable nepali keyboard input for XO-4
On 8 Nov 2013, at 14:24, Chris Leonard cjlhomeaddr...@gmail.com wrote: What about a virtual touch keyboard layout? Just wondering? FWIW: I'm pretty sure (check [1] [2]) that Nepali layouts were not part of the Maliit set I was asked to work on for the XO-4 touch keyboard layouts. It's been over a year ago, and a lot of things were going on, so my memory is a little rusty. If the XO-4's in question do have the touch screen hardware support, creating a layout file is not too difficult (as long as the required fonts glyphs are already installed). That is a beauty of touch screen keyboards, they may not be as good as tactile keyboards, but you can have almost any language layout you want with no hardware changes. [1] http://wiki.sugarlabs.org/go/User:Garycmartin/Maliit_Layouts [2] http://wiki.sugarlabs.org/go/User_talk:Garycmartin/Maliit#Currently_available_language_layouts Regards, --Gary On Fri, Nov 8, 2013 at 8:46 AM, Basanta Shrestha basanta.shres...@olenepal.org wrote: Hi Walter We don't have plans to use stickers at the moment. The stickers won't last long in the hands of kids. But we need to have some mechanism to input Nepali characters. For now we can give them a printout of the keyboard layout. Regards, Basanta On Fri, Nov 8, 2013 at 5:58 PM, Walter Bender walter.ben...@gmail.com wrote: A bit tricky because we don't have that key anymore (but we could come up with some other key combination to enable it). Also, are you planning to use stickers or some other way to add the proper glyths to the keyboard? Happy to explore this with you further. regards. -walter On Fri, Nov 8, 2013 at 12:23 AM, Basanta Shrestha basanta.shres...@olenepal.org wrote: Hi, I am writing this mail seeking a clue on where to start looking to enable Nepali input in XO4. For XO-1 we had nepali keyboard and there was a button just below the enter button which would switch input between English and Nepali. And that was very convenient. But for XO-4 we will just be getting ones with English layout. I was wondering how we can enable nepali keyboard input on it. I can see that the key maping file for nepali is already there under /usr/share/X11/xkb/symbols/ Thank you . -- Basanta Shrestha OLE Nepal ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Basanta Shrestha Network Engineer Open Learning Exchange (OLE) Nepal Tel: +977.1.551, 5520075 Ext. 303 Cell: +977.9818 605110 http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel signature.asc Description: Message signed with OpenPGP using GPGMail ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Web activities + CoffeeScript
2013/11/8 Manuel Quiñones ma...@laptop.org Hi Rogelio, On Thu, Nov 7, 2013 at 5:13 PM, Rogelio Mita rogeliom...@activitycentral.com wrote: Hi all!, working with web activities urges me to use CoffeeScript. - Is there any decision taken on this? - Do you discussed this topic in some occasion? or is irrelevant? It appeared a few times. In January when sugar-web didn't exist: http://lists.sugarlabs.org/archive/sugar-devel/2013-January/041616.html Then in August I wrote, after doing Gears activity: http://lists.sugarlabs.org/archive/sugar-devel/2013-August/05.html (GearSketch) It is written in coffeescript, and after playing for a bit, I can see it as a possible choice for activity developers. Its syntax sugar makes the code look more like the gtk activities written in python. +1 One of the reasons we went for plain js for sugar-web was because of the View Source feature. Well, seems that since I researched a few months ago, Source Maps has improved a lot, and I can see coffee code in the web inspector. If the code breaks or if I add a breakpoint, for example. Nice! Also, GitHub does a nice job displaying only the coffee changes, and hidding the JS changes by default: Nice!, also, I was playing a bit: - With the --map flag in coffee compiler I can use debbug function in browser - With a lib source-map-support.browser.js I can use error backtrace function in browser These points work in my chrome, but when using enable sourcemap on osbuild did not work any of the above points. What browser are using to web activities? So yes, it is a potable option for web activity developers. +1, but really wanted to understand what the problem through which osbuild not work. Now, in some real projects it happened to me that I started using Coffe or TypeScript and ended falling back to straight JS. Think about A. the compilation step B. no way to try things in the inspector console C. need to translate code examples and known solutions from JS to Coffee -- .. manuq .. Thanks Manuel! -- Roger Activity Central http://activitycentral.com/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
On Thu, Nov 7, 2013 at 11:23 PM, Basanta Shrestha basanta.shres...@olenepal.org wrote: But for XO-4 we will just be getting ones with English layout. I was wondering how we can enable nepali keyboard input on it. Are these keyboards hard/clicky/high-school style, or soft/membrane? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Web activities + CoffeeScript
We use webkitgtk 2.0.4. It's a few months old, I wonder if it would work in
2.2.x.
On Friday, 8 November 2013, Rogelio Mita wrote:
2013/11/8 Manuel Quiñones ma...@laptop.org javascript:_e({}, 'cvml',
'ma...@laptop.org');
Hi Rogelio,
On Thu, Nov 7, 2013 at 5:13 PM, Rogelio Mita
rogeliom...@activitycentral.com javascript:_e({}, 'cvml',
'rogeliom...@activitycentral.com'); wrote:
Hi all!,
working with web activities urges me to use CoffeeScript.
- Is there any decision taken on this?
- Do you discussed this topic in some occasion? or is irrelevant?
It appeared a few times.
In January when sugar-web didn't exist:
http://lists.sugarlabs.org/archive/sugar-devel/2013-January/041616.html
Then in August I wrote, after doing Gears activity:
http://lists.sugarlabs.org/archive/sugar-devel/2013-August/05.html
(GearSketch) It is written in coffeescript, and after playing for a bit,
I
can see it as a possible choice for activity developers. Its syntax
sugar makes the code look more like the gtk activities written in
python.
+1
One of the reasons we went for plain js for sugar-web was because of
the View Source feature. Well, seems that since I researched a few
months ago, Source Maps has improved a lot, and I can see coffee code
in the web inspector. If the code breaks or if I add a breakpoint, for
example. Nice! Also, GitHub does a nice job displaying only the
coffee changes, and hidding the JS changes by default:
Nice!, also, I was playing a bit:
- With the --map flag in coffee compiler I can use debbug function in
browser
- With a lib source-map-support.browser.js I can use error backtrace
function in browser
These points work in my chrome, but when using enable sourcemap on
osbuild did not work any of the above points.
What browser are using to web activities?
So yes, it is a potable option for web activity developers.
+1, but really wanted to understand what the problem through which osbuild
not work.
Now, in some real projects it happened to me that I started using
Coffe or TypeScript and ended falling back to straight JS. Think
about A. the compilation step B. no way to try things in the inspector
console C. need to translate code examples and known solutions from JS
to Coffee
--
.. manuq ..
Thanks Manuel!
--
Roger
Activity Central http://activitycentral.com/
--
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar tryout (was Re: sugarlabs.org redesign)
Do we really need a single installer? I mean I see it would be ideal but it
feels like it might be tricky licensing, implementation and maintenance
wise.
From what I understand from Thomas, after installing VirtualBox, it's just
downloading and clicking on an icon (I should really try it but I'm on a
bad connection these days). It might not be perfect but it doesn't really
sound bad, what is stopping us marketing Sugar this way really?
On Friday, 8 November 2013, Sean DALY wrote:
Not only doable, has been done for some time now [1,2] and is
multi-platform ( what I use to demo Sugar on a Mac)
The Oracle PUEL license [3] very interestingly permits free redistribution
for educational purposes, opening the possibility of a single installer,
ideal for our needs.
In the past I have suggested approaching Oracle for a marketing
partnership under a CSR (corporate social responsibility) banner.
Sean
1. http://wiki.sugarlabs.org/go/VirtualBox
2. https://wiki.sugarlabs.org/go/Sugar_Creation_Kit/VirtualBox
2. https://www.virtualbox.org/wiki/VirtualBox_PUEL
On Fri, Nov 8, 2013 at 1:25 PM, Gonzalo Odiard
gonz...@laptop.orgjavascript:_e({}, 'cvml', 'gonz...@laptop.org');
wrote:
At least the virtualbox looks doable and a good way to show Sugar.
Gonzalo
On Thu, Nov 7, 2013 at 9:44 PM, Daniel Narvaez
dwnarv...@gmail.comjavascript:_e({}, 'cvml', 'dwnarv...@gmail.com');
wrote:
On Thursday, 7 November 2013, Sean DALY wrote:
The larger problem is the absence of a marketing strategy, we need to
know where we are going to communicate effectively. In particular, we need
to choose and implement how to offer Sugar tryout to teachers and
journalists.
I can think of a couple of approaches
* Get Sugar running well on the CuBox-i. Find budget to buy a few of
those to distribute to chosen journalist and teachers. Try to partner with
SolidRun to offer Sugar as an out-of-the-box installation option.
* Make it easy to run Sugar inside VirtualBox on Windows and OS X.
Without having investigated too deeply it seems that a two step process
would be both realistically implementable and easy enough for the user
1 Install virtualbox
2 Install a Sugar application (which would take care of setting up the
appliance).
Thoughts? Other ideas? If we can agree on one or two concrete,
realistic approaches, I think we can at least attempt to get them done for
3.102.
--
Daniel Narvaez
___
Marketing mailing list
market...@lists.sugarlabs.org javascript:_e({}, 'cvml',
'market...@lists.sugarlabs.org');
http://lists.sugarlabs.org/listinfo/marketing
--
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
I believe Basanta said that they were the hard click keyboards On Fri, Nov 8, 2013 at 11:39 AM, Daniel Drake d...@laptop.org wrote: On Thu, Nov 7, 2013 at 11:23 PM, Basanta Shrestha basanta.shres...@olenepal.org wrote: But for XO-4 we will just be getting ones with English layout. I was wondering how we can enable nepali keyboard input on it. Are these keyboards hard/clicky/high-school style, or soft/membrane? Daniel ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/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] [Marketing] Sugar tryout (was Re: sugarlabs.org redesign)
On 11/8/2013 8:49 AM, Daniel Narvaez wrote:
Do we really need a single installer? I mean I see it would be ideal
but it feels like it might be tricky licensing, implementation and
maintenance wise.
From what I understand from Thomas, after installing VirtualBox, it's
just downloading and clicking on an icon (I should really try it but
I'm on a bad connection these days). It might not be perfect but
it doesn't really sound bad, what is stopping us marketing Sugar this
way really?
On Friday, 8 November 2013, Sean DALY wrote:
Not only doable, has been done for some time now [1,2] and is
multi-platform ( what I use to demo Sugar on a Mac)
The Oracle PUEL license [3] very interestingly permits free
redistribution for educational purposes, opening the possibility
of a single installer, ideal for our needs.
In the past I have suggested approaching Oracle for a marketing
partnership under a CSR (corporate social responsibility) banner.
Sean
1. http://wiki.sugarlabs.org/go/VirtualBox
2. https://wiki.sugarlabs.org/go/Sugar_Creation_Kit/VirtualBox
2. https://www.virtualbox.org/wiki/VirtualBox_PUEL
Here are some wiki pages and some older links from collaboration on
sugar with cyberorg (india) on #opensuse-edu on freenode IRC:
http://wiki.sugarlabs.org/go/OpenSUSE#OpenSuse-Sugar
http://download.opensuse.org/repositories/home:/dramwang/images/
http://download.opensuse.org/repositories/home:/dramwang/images/iso/
To write a USB:
download.opensuse.org/repositories/home:/dramwang/images/sugar.i686-0.3.0-Build7.5.raw.xz
Hosted Here: (used to have a sugar vmx hosted here' since removed)
We should consider placing some of the VirtualBox exports on
sourceforge.net:
http://sourceforge.net/projects/opensuse-edu/
Recent e-mail:
Re: [opensuse-edu] Final spurt: openSUSE Education for 13.1
On Tue, 22 Oct 2013 00:10:25 -0700 satellitsatelli...@gmail.com
wrote:
I hope a new sugar-desktop will become available. I see that
latest in
build system was for : sugar 0.96.3:
http://wiki.sugarlabs.org/go/OpenSUSE#Sugar_12.1
ok: I hopefully brought most of the packages to the current/stable
version (not 0.99x, but, hey: 0.98).
But now I need to ask the maintainers about the final setup, the
publishing (some packages have explicitely set no publishing) and
some special packages.
For the first problem, I guess someone just needs to go throught the
packages and check their (publish/build) settings, so that we get a
final release once everything built as expected.
...but I'm unsure about SDL (upgrade) and the olpcsound package
(upgrate from 5.10 to 6.01). Any preferences? Any ideas?
With kind regards,
Lars (Vogdt)
Tom Gilliard
On Fri, Nov 8, 2013 at 1:25 PM, Gonzalo Odiard gonz...@laptop.org
javascript:_e({}, 'cvml', 'gonz...@laptop.org'); wrote:
At least the virtualbox looks doable and a good way to show
Sugar.
Gonzalo
On Thu, Nov 7, 2013 at 9:44 PM, Daniel Narvaez
dwnarv...@gmail.com javascript:_e({}, 'cvml',
'dwnarv...@gmail.com'); wrote:
On Thursday, 7 November 2013, Sean DALY wrote:
The larger problem is the absence of a marketing
strategy, we need to know where we are going to
communicate effectively. In particular, we need to
choose and implement how to offer Sugar tryout to
teachers and journalists.
I can think of a couple of approaches
* Get Sugar running well on the CuBox-i. Find budget to
buy a few of those to distribute to chosen journalist and
teachers. Try to partner with SolidRun to offer Sugar as
an out-of-the-box installation option.
* Make it easy to run Sugar inside VirtualBox on Windows
and OS X. Without having investigated too deeply it
seems that a two step process would be both realistically
implementable and easy enough for the user
1 Install virtualbox
2 Install a Sugar application (which would take care of
setting up the appliance).
Thoughts? Other ideas? If we can agree on one or two
concrete, realistic approaches, I think we can at least
attempt to get them done for 3.102.
--
Daniel Narvaez
___
Marketing mailing list
market...@lists.sugarlabs.org javascript:_e({}, 'cvml',
'market...@lists.sugarlabs.org');
http://lists.sugarlabs.org/listinfo/marketing
--
Daniel Narvaez
___
Marketing mailing list
market...@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/marketing
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
Re: [Sugar-devel] Web activities + CoffeeScript
2013/11/8 Daniel Narvaez dwnarv...@gmail.com We use webkitgtk 2.0.4. It's a few months old, I wonder if it would work in 2.2.x. Thanks Daniel, I'll do some research on those WebKitGTK versions about sourcemap. On Friday, 8 November 2013, Rogelio Mita wrote: 2013/11/8 Manuel Quiñones ma...@laptop.org Hi Rogelio, On Thu, Nov 7, 2013 at 5:13 PM, Rogelio Mita rogeliom...@activitycentral.com wrote: Hi all!, working with web activities urges me to use CoffeeScript. - Is there any decision taken on this? - Do you discussed this topic in some occasion? or is irrelevant? It appeared a few times. In January when sugar-web didn't exist: http://lists.sugarlabs.org/archive/sugar-devel/2013-January/041616.html Then in August I wrote, after doing Gears activity: http://lists.sugarlabs.org/archive/sugar-devel/2013-August/05.html (GearSketch) It is written in coffeescript, and after playing for a bit, I can see it as a possible choice for activity developers. Its syntax sugar makes the code look more like the gtk activities written in python. +1 One of the reasons we went for plain js for sugar-web was because of the View Source feature. Well, seems that since I researched a few months ago, Source Maps has improved a lot, and I can see coffee code in the web inspector. If the code breaks or if I add a breakpoint, for example. Nice! Also, GitHub does a nice job displaying only the coffee changes, and hidding the JS changes by default: Nice!, also, I was playing a bit: - With the --map flag in coffee compiler I can use debbug function in browser - With a lib source-map-support.browser.js I can use error backtrace function in browser These points work in my chrome, but when using enable sourcemap on osbuild did not work any of the above points. What browser are using to web activities? So yes, it is a potable option for web activity developers. +1, but really wanted to understand what the problem through which osbuild not work. Now, in some real projects it happened to me that I started using Coffe or TypeScript and ended falling back to straight JS. Think about A. the compilation step B. no way to try things in the inspector console C. need to translate code examples and known solutions from JS to Coffee -- .. manuq .. Thanks Manuel! -- Roger Activity Central http://activitycentral.com/ -- Daniel Narvaez It's good that we give importance to the use of Coffeescript as an alternative to a prototype-based language such as javascript, with all that implies, it will be very useful for who come to class-based languages such as Python. Thanks -- Roger Activity Central http://activitycentral.com/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar tryout (was Re: sugarlabs.org redesign)
Of course it doesn't stop us from marketing, but it adds two extra hurdles for teachers to deal with (the GPL VirtualBox installer + the PUEL extension pack necessary for passthrough USB support). So techies won't care, but I guarantee a percentage of teachers will. It's a well-documented axiom of internet marketing that you lose up to 50% of prospects with every additional click - this is precisely why Amazon deployed 1-click purchases. With three clicks instead of one, I hope we don't lose 20%, 30%, 50% of interested teachers. After all, there's already a barrier: the huge size of the downloads. It's obvious given our limited resources we need to evaluate our most resource-effective ways of publishing prepared VMs. This is what I had in mind about approaching Oracle. But we need to try to maximize our potential conversion rate without additional hoops. I'd be happy with anything over 10% (software/SaaS average rate is roughly 7% [1]), and we won't even be gating the download in a contact form. My proposal two years ago to make VMs the preferred method for teachers to try Sugar met with opposition from Peter and others who preferred SoaS. Sean [1] http://www.marketingsherpa.com/article/chart/average-website-conversion-rates-industry# On Fri, Nov 8, 2013 at 5:49 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Do we really need a single installer? I mean I see it would be ideal but it feels like it might be tricky licensing, implementation and maintenance wise. From what I understand from Thomas, after installing VirtualBox, it's just downloading and clicking on an icon (I should really try it but I'm on a bad connection these days). It might not be perfect but it doesn't really sound bad, what is stopping us marketing Sugar this way really? On Friday, 8 November 2013, Sean DALY wrote: Not only doable, has been done for some time now [1,2] and is multi-platform ( what I use to demo Sugar on a Mac) The Oracle PUEL license [3] very interestingly permits free redistribution for educational purposes, opening the possibility of a single installer, ideal for our needs. In the past I have suggested approaching Oracle for a marketing partnership under a CSR (corporate social responsibility) banner. Sean 1. http://wiki.sugarlabs.org/go/VirtualBox 2. https://wiki.sugarlabs.org/go/Sugar_Creation_Kit/VirtualBox 2. https://www.virtualbox.org/wiki/VirtualBox_PUEL On Fri, Nov 8, 2013 at 1:25 PM, Gonzalo Odiard gonz...@laptop.orgwrote: At least the virtualbox looks doable and a good way to show Sugar. Gonzalo On Thu, Nov 7, 2013 at 9:44 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On Thursday, 7 November 2013, Sean DALY wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). Thoughts? Other ideas? If we can agree on one or two concrete, realistic approaches, I think we can at least attempt to get them done for 3.102. -- Daniel Narvaez ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Performance: activities start up time
There are many issues in Sugar regarding performance,
but one of the more visible to the user is how much time the activities
take to start. This is not so evident in newer hardware,
but is important in XO-1. Is so important than by example, Peru will use
sugar 0.94
instead of a newer because o this.
I was doing some testing with the main activities:
https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=drive_web#gid=0
(These measures were done in a XO-1)
I first blamed to the port from gtk2 to gtk3 of the big regressions in
performance,
but after looking with a little of detail, some can be solved easily.
One of the arguments of the dynamic bindings was a better startup time due
to not need initialize all the libraries until is needed use them. Then the
import should
be lighter than before. Looks like that is not so true.
In the case of Write activity, I was able to reduce the start up in 7 or 8
seconds, just delaying the gstreamer initialization [1], and 1 or 2 seconds
more delaying two other imports.
In the case of Browse activity, just delaying the import of Evince
libraries to the moment when a pdf is opened, improve the start up time in
13 seconds (patch attached). The start up time is even better than the
version in 0.94
I think this work of identify big libraries used only in specific moments,
can be applied in other cases.
Gonzalo
[1]
http://git.sugarlabs.org/write/mainline/commit/5dd843cf415d0c65e2927540225b0098f2b71cd0
[2]
http://git.sugarlabs.org/write/mainline/commit/dba223f5749f510735692a06f246acee30ab50bf
From 0f71dc1c1aec9dd915612e052dc9577fe5b1d024 Mon Sep 17 00:00:00 2001
From: Gonzalo Odiard godi...@gmail.com
Date: Fri, 8 Nov 2013 11:35:36 -0300
Subject: [PATCH] Delay Evince import until is needed to improve activity
startup time
This change improve startup time in a XO-1 from 31 segs to 18 segs.
Signed-off-by: Gonzalo Odiard gonz...@laptop.org
---
activity/activity.info | 2 +-
pdfviewer.py | 15 +--
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/activity/activity.info b/activity/activity.info
index c3af6df..b570c45 100644
--- a/activity/activity.info
+++ b/activity/activity.info
@@ -1,6 +1,6 @@
[Activity]
name = Browse
-activity_version = 155
+activity_version = 155.1
bundle_id = org.laptop.WebActivity
icon = activity-web
exec = sugar-activity webactivity.WebActivity -s
diff --git a/pdfviewer.py b/pdfviewer.py
index ce0244c..7f2838f 100644
--- a/pdfviewer.py
+++ b/pdfviewer.py
@@ -17,14 +17,11 @@
import os
import logging
import tempfile
-import threading
from gettext import gettext as _
from gi.repository import GObject
from gi.repository import Gtk
from gi.repository import GLib
-from gi.repository import EvinceDocument
-from gi.repository import EvinceView
from gi.repository import WebKit
from sugar3.graphics.toolbarbox import ToolbarBox
@@ -56,6 +53,10 @@ class EvinceViewer(Gtk.Overlay):
self._uri = uri
+# delay Evince import until is needed to improve activity startup time
+from gi.repository import EvinceDocument
+from gi.repository import EvinceView
+
# Create Evince objects to handle the PDF in the URI:
EvinceDocument.init()
self._doc = EvinceDocument.Document.factory_get_document(uri)
@@ -64,6 +65,8 @@ class EvinceViewer(Gtk.Overlay):
self._model.set_document(self._doc)
self._view.set_model(self._model)
+self._EVINCE_MODE_FREE = EvinceView.SizingMode.FREE
+
self._view.connect('external-link', self.__handle_link_cb)
self._model.connect('page-changed', self.__page_changed_cb)
@@ -173,15 +176,15 @@ class EvinceViewer(Gtk.Overlay):
current_page self._doc.get_n_pages() - 1
def zoom_original(self):
-self._model.props.sizing_mode = EvinceView.SizingMode.FREE
+self._model.props.sizing_mode = self._EVINCE_MODE_FREE
self._model.props.scale = 1.0
def zoom_in(self):
-self._model.props.sizing_mode = EvinceView.SizingMode.FREE
+self._model.props.sizing_mode = self._EVINCE_MODE_FREE
self._view.zoom_in()
def zoom_out(self):
-self._model.props.sizing_mode = EvinceView.SizingMode.FREE
+self._model.props.sizing_mode = self._EVINCE_MODE_FREE
self._view.zoom_out()
def get_pdf_title(self):
--
1.8.1.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar tryout (was Re: sugarlabs.org redesign) [Sugar-devel Digest, Vol 61, Issue 55]
cc'ing Marketing as well. On Fri, Nov 8, 2013 at 2:50 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. Although the hardware specs are a good target for Sugar3, I believe that suggesting a really small box with 5 cables connected to it to showcase a K-9 educational platform, may retract from the feasibility and thoroughness of the project. A decent rooted tablet (ie Nexus 7) running Sugar on top of Linux, even if the performance is not the best, would be much more catchy and maybe suggestive of a Sugar-on-Android to come. I agree that to showcase Sugar, a tablet would be a better platform than Raspberry Pi, or Cubox-1, etc. Ruben Rodriguez showed us a Nexus 7 tablet running sugar at the OLPC SF summit. This build was running on top of Ubuntu desktop for ARM. We also had a Nexus 7 that was running the Ubuntu Touch (for phone and tablets) and Ruben thought it would perhaps be a better platform for running Sugar on a ARM tablet instead of his approach. I haven't followed up with him, but I'm cc'ing him as well. cheers, Sameer You can still do the CuBox thing but not for journalists and teachers. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). This is certainly a good idea but it must work as advertised ie in 1 click after the VM software is installed. I would only add Parallels-VM/VMware appliances since may already be present in these closed OSs and can really provide a single click to Sugar. ___ 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] Sugar tryout (was Re: sugarlabs.org redesign) [Sugar-devel Digest, Vol 61, Issue 55]
On Fri, Nov 8, 2013 at 10:55 AM, Sameer Verma sve...@sfsu.edu wrote: cc'ing Marketing as well. On Fri, Nov 8, 2013 at 2:50 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. Although the hardware specs are a good target for Sugar3, I believe that suggesting a really small box with 5 cables connected to it to showcase a K-9 educational platform, may retract from the feasibility and thoroughness of the project. A decent rooted tablet (ie Nexus 7) running Sugar on top of Linux, even if the performance is not the best, would be much more catchy and maybe suggestive of a Sugar-on-Android to come. I agree that to showcase Sugar, a tablet would be a better platform than Raspberry Pi, or Cubox-1, etc. Ruben Rodriguez showed us a Nexus 7 tablet running sugar at the OLPC SF summit. This build was running on top of Ubuntu desktop for ARM. We also had a Nexus 7 that was running the Ubuntu Touch (for phone and tablets) and Ruben thought it would perhaps be a better platform for running Sugar on a ARM tablet instead of his approach. I haven't followed up with him, but I'm cc'ing him as well. Found a thread that might be helpful. http://lists.sugarlabs.org/archive/sugar-devel/2013-September/044819.html cheers, Sameer cheers, Sameer You can still do the CuBox thing but not for journalists and teachers. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). This is certainly a good idea but it must work as advertised ie in 1 click after the VM software is installed. I would only add Parallels-VM/VMware appliances since may already be present in these closed OSs and can really provide a single click to Sugar. ___ 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] Sugar tryout (was Re: sugarlabs.org redesign)
Of course I agree with you that less barriers the better but I think we
need to pick our battles. With current state of the downloads page I'd
expect the conversion rate to near the 0%. It takes a *lot* of extra clicks
to achieve the same.
I propose that we
* Rewrite the downloads page offering *simple* instruction only
for Soas and Virtualbox.
* Keep the current page somewhere on the wiki, prominently linked, it's
fine for techies.
* Start measuring conversion rate. I suspect we don't have a way to count
the number of users that managed to reach the Sugar home. But measuring
completed downloads would be a start.
* Gradually get rid of as many barriers as possible and see how the rate is
affected.
On Friday, 8 November 2013, Sean DALY wrote:
Of course it doesn't stop us from marketing, but it adds two extra hurdles
for teachers to deal with (the GPL VirtualBox installer + the PUEL
extension pack necessary for passthrough USB support). So techies won't
care, but I guarantee a percentage of teachers will. It's a well-documented
axiom of internet marketing that you lose up to 50% of prospects with every
additional click - this is precisely why Amazon deployed 1-click purchases.
With three clicks instead of one, I hope we don't lose 20%, 30%, 50% of
interested teachers. After all, there's already a barrier: the huge size of
the downloads.
It's obvious given our limited resources we need to evaluate our most
resource-effective ways of publishing prepared VMs. This is what I had in
mind about approaching Oracle. But we need to try to maximize our potential
conversion rate without additional hoops. I'd be happy with anything over
10% (software/SaaS average rate is roughly 7% [1]), and we won't even be
gating the download in a contact form.
My proposal two years ago to make VMs the preferred method for teachers to
try Sugar met with opposition from Peter and others who preferred SoaS.
Sean
[1]
http://www.marketingsherpa.com/article/chart/average-website-conversion-rates-industry#
On Fri, Nov 8, 2013 at 5:49 PM, Daniel Narvaez
dwnarv...@gmail.comjavascript:_e({}, 'cvml', 'dwnarv...@gmail.com');
wrote:
Do we really need a single installer? I mean I see it would be ideal but
it feels like it might be tricky licensing, implementation and maintenance
wise.
From what I understand from Thomas, after installing VirtualBox, it's
just downloading and clicking on an icon (I should really try it but I'm on
a bad connection these days). It might not be perfect but it doesn't really
sound bad, what is stopping us marketing Sugar this way really?
On Friday, 8 November 2013, Sean DALY wrote:
Not only doable, has been done for some time now [1,2] and is
multi-platform ( what I use to demo Sugar on a Mac)
The Oracle PUEL license [3] very interestingly permits free
redistribution for educational purposes, opening the possibility of a
single installer, ideal for our needs.
In the past I have suggested approaching Oracle for a marketing
partnership under a CSR (corporate social responsibility) banner.
Sean
1. http://wiki.sugarlabs.org/go/VirtualBox
2. https://wiki.sugarlabs.org/go/Sugar_Creation_Kit/VirtualBox
2. https://www.virtualbox.org/wiki/VirtualBox_PUEL
On Fri, Nov 8, 2013 at 1:25 PM, Gonzalo Odiard gonz...@laptop.orgwrote:
At least the virtualbox looks doable and a good way to show Sugar.
Gonzalo
On Thu, Nov 7, 2013 at 9:44 PM, Daniel Narvaez dwnarv...@gmail.comwrote:
On Thursday, 7 November 2013, Sean DALY wrote:
The larger problem is the absence of a marketing strategy, we need to
know where we are going to communicate effectively. In particular, we
need
to choose and implement how to offer Sugar tryout to teachers and
journalists.
I can think of a couple of approaches
* Get Sugar running well on the CuBox-i. Find budget to buy a few of
those to distribute to chosen journalist and teachers. Try to partner with
SolidRun to offer Sugar as an out-of-the-box installation option.
* Make it easy to run Sugar inside VirtualBox on Windows and OS X.
Without having investigated too deeply it seems that a two step process
would be both realistically implementable and easy enough for the user
1 Install virtualbox
2 Install a Sugar application (which would take care of setting up the
appliance).
Thoughts? Other ideas? If we can agree on one or two concrete,
realistic approaches, I think we can at least attempt to get them done for
3.102.
--
Daniel Narvaez
___
Marketing mailing list
market...@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/marketing
--
Daniel Narvaez
--
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar tryout (was Re: sugarlabs.org redesign) [Sugar-devel Digest, Vol 61, Issue 55]
Getting Sugar to run on a Nexus 7 is relatively simple, making it usable enough would likely be a lot of work but it should be possible. But, as far as I know, we have no idea of how get around the rooting, making it a viable solution for deployments. Until we figure that out IMO it doesn't make sense to market Sugar on a tablet. On Friday, 8 November 2013, Sameer Verma wrote: On Fri, Nov 8, 2013 at 10:55 AM, Sameer Verma sve...@sfsu.edujavascript:; wrote: cc'ing Marketing as well. On Fri, Nov 8, 2013 at 2:50 AM, Yioryos Asprobounitis mavrot...@yahoo.com javascript:; wrote: The larger problem is the absence of a marketing strategy, we need to know where we are going to communicate effectively. In particular, we need to choose and implement how to offer Sugar tryout to teachers and journalists. I can think of a couple of approaches * Get Sugar running well on the CuBox-i. Find budget to buy a few of those to distribute to chosen journalist and teachers. Try to partner with SolidRun to offer Sugar as an out-of-the-box installation option. Although the hardware specs are a good target for Sugar3, I believe that suggesting a really small box with 5 cables connected to it to showcase a K-9 educational platform, may retract from the feasibility and thoroughness of the project. A decent rooted tablet (ie Nexus 7) running Sugar on top of Linux, even if the performance is not the best, would be much more catchy and maybe suggestive of a Sugar-on-Android to come. I agree that to showcase Sugar, a tablet would be a better platform than Raspberry Pi, or Cubox-1, etc. Ruben Rodriguez showed us a Nexus 7 tablet running sugar at the OLPC SF summit. This build was running on top of Ubuntu desktop for ARM. We also had a Nexus 7 that was running the Ubuntu Touch (for phone and tablets) and Ruben thought it would perhaps be a better platform for running Sugar on a ARM tablet instead of his approach. I haven't followed up with him, but I'm cc'ing him as well. Found a thread that might be helpful. http://lists.sugarlabs.org/archive/sugar-devel/2013-September/044819.html cheers, Sameer cheers, Sameer You can still do the CuBox thing but not for journalists and teachers. * Make it easy to run Sugar inside VirtualBox on Windows and OS X. Without having investigated too deeply it seems that a two step process would be both realistically implementable and easy enough for the user 1 Install virtualbox 2 Install a Sugar application (which would take care of setting up the appliance). This is certainly a good idea but it must work as advertised ie in 1 click after the VM software is installed. I would only add Parallels-VM/VMware appliances since may already be present in these closed OSs and can really provide a single click to Sugar. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel ___ Marketing mailing list market...@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/marketing -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Performance: activities start up time
We need to figure out why this is happening. It doesn't make any sense to me that avoiding the evince lib import would save 13 seconds. You could write a minimal test case, importing Gtk first, then time the Evince import. If it takes a long time in the testcase too you could strace it to see wtf is going on. Local imports are a really bad idea for code maintenance. On Friday, 8 November 2013, Gonzalo Odiard wrote: There are many issues in Sugar regarding performance, but one of the more visible to the user is how much time the activities take to start. This is not so evident in newer hardware, but is important in XO-1. Is so important than by example, Peru will use sugar 0.94 instead of a newer because o this. I was doing some testing with the main activities: https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=drive_web#gid=0 (These measures were done in a XO-1) I first blamed to the port from gtk2 to gtk3 of the big regressions in performance, but after looking with a little of detail, some can be solved easily. One of the arguments of the dynamic bindings was a better startup time due to not need initialize all the libraries until is needed use them. Then the import should be lighter than before. Looks like that is not so true. In the case of Write activity, I was able to reduce the start up in 7 or 8 seconds, just delaying the gstreamer initialization [1], and 1 or 2 seconds more delaying two other imports. In the case of Browse activity, just delaying the import of Evince libraries to the moment when a pdf is opened, improve the start up time in 13 seconds (patch attached). The start up time is even better than the version in 0.94 I think this work of identify big libraries used only in specific moments, can be applied in other cases. Gonzalo [1] http://git.sugarlabs.org/write/mainline/commit/5dd843cf415d0c65e2927540225b0098f2b71cd0 [2] http://git.sugarlabs.org/write/mainline/commit/dba223f5749f510735692a06f246acee30ab50bf -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Performance: activities start up time
What do you mean with gstreamer initialisation btw? Just the import? That would be even more surprising because the shell is importing it too and hence the shared library should be in memory already. On Friday, 8 November 2013, Gonzalo Odiard wrote: There are many issues in Sugar regarding performance, but one of the more visible to the user is how much time the activities take to start. This is not so evident in newer hardware, but is important in XO-1. Is so important than by example, Peru will use sugar 0.94 instead of a newer because o this. I was doing some testing with the main activities: https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=drive_web#gid=0 (These measures were done in a XO-1) I first blamed to the port from gtk2 to gtk3 of the big regressions in performance, but after looking with a little of detail, some can be solved easily. One of the arguments of the dynamic bindings was a better startup time due to not need initialize all the libraries until is needed use them. Then the import should be lighter than before. Looks like that is not so true. In the case of Write activity, I was able to reduce the start up in 7 or 8 seconds, just delaying the gstreamer initialization [1], and 1 or 2 seconds more delaying two other imports. In the case of Browse activity, just delaying the import of Evince libraries to the moment when a pdf is opened, improve the start up time in 13 seconds (patch attached). The start up time is even better than the version in 0.94 I think this work of identify big libraries used only in specific moments, can be applied in other cases. Gonzalo [1] http://git.sugarlabs.org/write/mainline/commit/5dd843cf415d0c65e2927540225b0098f2b71cd0 [2] http://git.sugarlabs.org/write/mainline/commit/dba223f5749f510735692a06f246acee30ab50bf -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Performance: activities start up time
Another interesting test would be to import the same library using static bindings and gi, comparing the time. Btw for reliable timing you want to drop the kernel memory cache before each start http://www.linuxinsight.com/proc_sys_vm_drop_caches.html On Friday, 8 November 2013, Gonzalo Odiard wrote: There are many issues in Sugar regarding performance, but one of the more visible to the user is how much time the activities take to start. This is not so evident in newer hardware, but is important in XO-1. Is so important than by example, Peru will use sugar 0.94 instead of a newer because o this. I was doing some testing with the main activities: https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=drive_web#gid=0 (These measures were done in a XO-1) I first blamed to the port from gtk2 to gtk3 of the big regressions in performance, but after looking with a little of detail, some can be solved easily. One of the arguments of the dynamic bindings was a better startup time due to not need initialize all the libraries until is needed use them. Then the import should be lighter than before. Looks like that is not so true. In the case of Write activity, I was able to reduce the start up in 7 or 8 seconds, just delaying the gstreamer initialization [1], and 1 or 2 seconds more delaying two other imports. In the case of Browse activity, just delaying the import of Evince libraries to the moment when a pdf is opened, improve the start up time in 13 seconds (patch attached). The start up time is even better than the version in 0.94 I think this work of identify big libraries used only in specific moments, can be applied in other cases. Gonzalo [1] http://git.sugarlabs.org/write/mainline/commit/5dd843cf415d0c65e2927540225b0098f2b71cd0 [2] http://git.sugarlabs.org/write/mainline/commit/dba223f5749f510735692a06f246acee30ab50bf -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Performance: activities start up time
To clarify, despite my disliking of inline imports, if it's the only way to get this kind of performance enanchements we should obviously do it... I feel we should understand what is going on though, if it's something we can fix more generally it will help also with all the other gi imports and it will avoid having to explain to activity developers that they need to be careful about what they import and where (especially because the issue might be unnoticeable on the hardware they are using). On Friday, 8 November 2013, Daniel Narvaez wrote: We need to figure out why this is happening. It doesn't make any sense to me that avoiding the evince lib import would save 13 seconds. You could write a minimal test case, importing Gtk first, then time the Evince import. If it takes a long time in the testcase too you could strace it to see wtf is going on. Local imports are a really bad idea for code maintenance. On Friday, 8 November 2013, Gonzalo Odiard wrote: There are many issues in Sugar regarding performance, but one of the more visible to the user is how much time the activities take to start. This is not so evident in newer hardware, but is important in XO-1. Is so important than by example, Peru will use sugar 0.94 instead of a newer because o this. I was doing some testing with the main activities: https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=drive_web#gid=0 (These measures were done in a XO-1) I first blamed to the port from gtk2 to gtk3 of the big regressions in performance, but after looking with a little of detail, some can be solved easily. One of the arguments of the dynamic bindings was a better startup time due to not need initialize all the libraries until is needed use them. Then the import should be lighter than before. Looks like that is not so true. In the case of Write activity, I was able to reduce the start up in 7 or 8 seconds, just delaying the gstreamer initialization [1], and 1 or 2 seconds more delaying two other imports. In the case of Browse activity, just delaying the import of Evince libraries to the moment when a pdf is opened, improve the start up time in 13 seconds (patch attached). The start up time is even better than the version in 0.94 I think this work of identify big libraries used only in specific moments, can be applied in other cases. Gonzalo [1] http://git.sugarlabs.org/write/mainline/commit/5dd843cf415d0c65e2927540225b0098f2b71cd0 [2] http://git.sugarlabs.org/write/mainline/commit/dba223f5749f510735692a06f246acee30ab50bf -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sur] My proposals to improve sugar:
Well, I followed the steps in: http://developer.sugarlabs.org/dev-environment.md.html And I could never go to the following: flavio @ flavio-Aspire-5735: ~ / Documents / Sugar $. / osbuild pull = Setup the host build system = * Create the python virtualenv * Install python packages * Pull latest sugar-build * Setup the build root $ Sudo setup Broot Join the root password as requested, but then is there not expecting that without returning any information. El 7 de noviembre de 2013 09:59, Gonzalo Odiard gonz...@laptop.orgescribió: Hi Flavio, Happy to see you exposing your points here. Every one of your proposals deserve a discussion, but “The best way to eat an elephant is one bite at a time.” Should be good define the proposal in ways we can put in motion them, that is the reason we use the Features pages to propose changes (see http://wiki.sugarlabs.org/go/0.102/Feature_List) About other comments, like better performance or activities without flaws all agree on that, is just a matter of put it more work. More hands and eyes can help. -- Me alegra verte exponiendo tus puntos aqui. Cada uno merece una discusion, pero La mejor forma de comerse un elefante es un mordisco por vez Sería bueno que definas las propuestas en forma en que podamos ponerlas en práctica, esa es la razon por la que usamos las paginas de Características (Features) para proponer cambios (ver http://wiki.sugarlabs.org/go/0.102/Feature_List ) Acerca de tus otros comentarios, como mejorar la performance o tener actividades sin fallas, todos estamos de acuerdo, es solo ponerse a trabajar más. Más manos y ojos pueden ayudar. Gonzalo 2013/11/6 Flavio Danesse fdane...@gmail.com *My proposals to improve sugar: * Change the face, giving more importance to aesthetics, leave the black and white, give colorful, add animations, sounds, etc.. . . What is pleasing to the user's view and fun to use. Change the geometry of buttons and other widgets of sugar to have a delicate design and tasteful. Remove all the features that make the system seem slow, such as the deployment of the menus in the GUI. Since I do not want to eliminate journal, give it a nicer interface (I like the idea I had Gonzalo, that explain it if you want). Adding a view of standard directories (could be a target for google code-in, see it mentors). That does not keep unnecessary things for the journal is truly usable. What sugar is distributed with the Linux man so users can use it like any linux user. Developers simplify activities, all network interface to develop shared activities (As commented, Augustine was doing something about this, maybe I can be another target for google code-in). What someone explain a simple way to contribute code to sugar, I'm 5 years ago and I have been able to do so (the timers need help). Order very personal: Remember that some do not speak English (particularly those whose native language is Spanish) Ensure first, support for popular applications, then the other. Rebuilding the link between development and deployment, taking into account that when I talk about deployments I mean users of the system, so that what matters is the opinion of teachers and students or users. Sugar should focus primarily on the opinions of teachers and students, ie actual use is given, is the only way to improve it. We must devise a way of communicating with them, perhaps this could materialize in an application that is distributed along with sugar (this proposal and did several times). From my point of view: You can not miss a student? Internet (social networks) Games (funny) You can not miss a teacher? Rapid applications without flaws that allow you to work in class and evaluate the tasks performed by their students. Obviously, the interests of both groups are different, we must find ways to meet the expectations of both groups, it is not enough that only one group using the system. On the other hand, those responsible for the deployments what the results will be evaluated in the education system, but you need to have to conform to users who use the system. Well, more or less, as I see it. *Mis propuestas para mejorar sugar:* Cambiarle la cara, darle más importancia a la estética, abandonar el blanco y negro, darle colorido, agregar animaciones, sonidos, etc . . . Qué sea agradable a la vista del usuario y divertido de utilizar. Cambiar la geometría de botones y demás widgets de sugar para que tengan un diseño delicado y de buen gusto. Quitar todas las funcionalidades que hacen parecer lento al sistema, como por ejemplo el despliegue de los menús en la interfaz gráfica. Ya que no desean eliminar journal, darle una interfaz más agradable (me gusta la idea que tenía Gonzalo, que el la explique si desea). Agregarle una vista de directorios estandard (podría ser un objetivo para google code-in, veanlo los mentores). Que no se guarden
Re: [Sugar-devel] [Sur] My proposals to improve sugar:
Hi, it's doing a 280M download there, so it can take a while depending on your connection. You can watch progress in another terminal by doing tail -f build/logs/broot.log (A patch to documentation to explain this is being reviewed). On 8 November 2013 21:40, Flavio Danesse fdane...@gmail.com wrote: Well, I followed the steps in: http://developer.sugarlabs.org/dev-environment.md.html And I could never go to the following: flavio @ flavio-Aspire-5735: ~ / Documents / Sugar $. / osbuild pull = Setup the host build system = * Create the python virtualenv * Install python packages * Pull latest sugar-build * Setup the build root $ Sudo setup Broot Join the root password as requested, but then is there not expecting that without returning any information. El 7 de noviembre de 2013 09:59, Gonzalo Odiard gonz...@laptop.orgescribió: Hi Flavio, Happy to see you exposing your points here. Every one of your proposals deserve a discussion, but “The best way to eat an elephant is one bite at a time.” Should be good define the proposal in ways we can put in motion them, that is the reason we use the Features pages to propose changes (see http://wiki.sugarlabs.org/go/0.102/Feature_List) About other comments, like better performance or activities without flaws all agree on that, is just a matter of put it more work. More hands and eyes can help. -- Me alegra verte exponiendo tus puntos aqui. Cada uno merece una discusion, pero La mejor forma de comerse un elefante es un mordisco por vez Sería bueno que definas las propuestas en forma en que podamos ponerlas en práctica, esa es la razon por la que usamos las paginas de Características (Features) para proponer cambios (ver http://wiki.sugarlabs.org/go/0.102/Feature_List) Acerca de tus otros comentarios, como mejorar la performance o tener actividades sin fallas, todos estamos de acuerdo, es solo ponerse a trabajar más. Más manos y ojos pueden ayudar. Gonzalo 2013/11/6 Flavio Danesse fdane...@gmail.com *My proposals to improve sugar: * Change the face, giving more importance to aesthetics, leave the black and white, give colorful, add animations, sounds, etc.. . . What is pleasing to the user's view and fun to use. Change the geometry of buttons and other widgets of sugar to have a delicate design and tasteful. Remove all the features that make the system seem slow, such as the deployment of the menus in the GUI. Since I do not want to eliminate journal, give it a nicer interface (I like the idea I had Gonzalo, that explain it if you want). Adding a view of standard directories (could be a target for google code-in, see it mentors). That does not keep unnecessary things for the journal is truly usable. What sugar is distributed with the Linux man so users can use it like any linux user. Developers simplify activities, all network interface to develop shared activities (As commented, Augustine was doing something about this, maybe I can be another target for google code-in). What someone explain a simple way to contribute code to sugar, I'm 5 years ago and I have been able to do so (the timers need help). Order very personal: Remember that some do not speak English (particularly those whose native language is Spanish) Ensure first, support for popular applications, then the other. Rebuilding the link between development and deployment, taking into account that when I talk about deployments I mean users of the system, so that what matters is the opinion of teachers and students or users. Sugar should focus primarily on the opinions of teachers and students, ie actual use is given, is the only way to improve it. We must devise a way of communicating with them, perhaps this could materialize in an application that is distributed along with sugar (this proposal and did several times). From my point of view: You can not miss a student? Internet (social networks) Games (funny) You can not miss a teacher? Rapid applications without flaws that allow you to work in class and evaluate the tasks performed by their students. Obviously, the interests of both groups are different, we must find ways to meet the expectations of both groups, it is not enough that only one group using the system. On the other hand, those responsible for the deployments what the results will be evaluated in the education system, but you need to have to conform to users who use the system. Well, more or less, as I see it. *Mis propuestas para mejorar sugar:* Cambiarle la cara, darle más importancia a la estética, abandonar el blanco y negro, darle colorido, agregar animaciones, sonidos, etc . . . Qué sea agradable a la vista del usuario y divertido de utilizar. Cambiar la geometría de botones y demás widgets de sugar para que tengan un diseño delicado y de buen gusto. Quitar todas las funcionalidades que hacen parecer lento al sistema, como por ejemplo
Re: [Sugar-devel] Performance: activities start up time
Even more confused now... The two evince imports you are moving doesn't even cause the dynamic library to be loaded, so they should have absolutely no performance impact. That's the normal case in gobject-introspection, libraries are loaded lazily, when you try to use one of the functions. Gtk is an exception because gtk_init is called automatically on import and there are probably other libraries that do something similar. Though I verified that's not the case for Evince by looking at the smaps. On 8 November 2013 19:44, Gonzalo Odiard gonz...@laptop.org wrote: There are many issues in Sugar regarding performance, but one of the more visible to the user is how much time the activities take to start. This is not so evident in newer hardware, but is important in XO-1. Is so important than by example, Peru will use sugar 0.94 instead of a newer because o this. I was doing some testing with the main activities: https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=drive_web#gid=0 (These measures were done in a XO-1) I first blamed to the port from gtk2 to gtk3 of the big regressions in performance, but after looking with a little of detail, some can be solved easily. One of the arguments of the dynamic bindings was a better startup time due to not need initialize all the libraries until is needed use them. Then the import should be lighter than before. Looks like that is not so true. In the case of Write activity, I was able to reduce the start up in 7 or 8 seconds, just delaying the gstreamer initialization [1], and 1 or 2 seconds more delaying two other imports. In the case of Browse activity, just delaying the import of Evince libraries to the moment when a pdf is opened, improve the start up time in 13 seconds (patch attached). The start up time is even better than the version in 0.94 I think this work of identify big libraries used only in specific moments, can be applied in other cases. Gonzalo [1] http://git.sugarlabs.org/write/mainline/commit/5dd843cf415d0c65e2927540225b0098f2b71cd0 [2] http://git.sugarlabs.org/write/mainline/commit/dba223f5749f510735692a06f246acee30ab50bf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sur] [IAEP] Sugar oversight board meeting
On Fri, Nov 8, 2013 at 8:29 AM, Sean DALY sdaly...@gmail.com wrote: David - what I meant was, no strategic partnership between the distros. Ubuntu wouldn't pose so many difficulties if M. Shuttleworth/Canonical got behind Sugar for example. In my conversations with Shuttleworth and Redhat they were both pretty upset that they were forced to bid against each other to be part of the OLPC project. Whoever donated more got to be part of the project the other was ignored. That, on top of Ubuntu's screw ups in the education sector ( Canoncial, tried to assume too much control over the community lead Edubuntu project) have left education, and sugar in particular, struggling at Ubuntu. Sean On Thu, Nov 7, 2013 at 10:46 AM, David Farning dfarn...@activitycentral.com wrote: On Thu, Nov 7, 2013 at 3:07 AM, Sean DALY sdaly...@gmail.com wrote: I'm sorry Sebastian, yes I should have been more clear about which Sebastian :-) At the time, Sugar was perceived as being only available on OLPC XOs, so our effort was designed to show that it was available for other platforms. Indeed, our claim has always been that it was hardware-agnostic (on Mac using virtualization), cf. our press releases (sl.o/press). And, SoaS as a marketing concept was meant to be distro-agnostic too (SuSE...), a position fought tooth and nail by the Fedorans by the way. Pre-tablets, when small netbooks sales were exploding, Windows was dominant on PCs but ran poorly or not at all on netbooks and moreover there was an installation barrier for Windows on GNU/Linux netbooks. We were interested in reaching the 92% or so of teachers using Windows and widening Sugar availability on machines with pre-installed GNU/Linux (all 2% or so of them). Microsoft and Intel worked quickly to block GNU/Linux netbooks by pressuring OEMs to build faster machines, then tablets arrived and killed off netbooks. It's unfortunate that Sugar was not fully embraced by the GNU/Linux distros who missed a great opportunity in the education market where Microsoft had and has weaknesses, but that has been a symptom of free software projects struggling with strategic initiatives while concentrating on technical aspects. How does Sugar on Ubuntu (DXU) and Sugar on Tablets (DX experimental) affect this equation for Sugar Labs? Dismal marketing has contributed to dismal desktop market share (Microsoft's well-documented maneuvers played a role too of course). Installation: As Peter has mentioned, SoaS can be used for installation on a target PC, this is documented in the wiki. Concerning translations, language selection was available in at least several versions of SoaS, I remember switching French and US locale and keyboard demoing SoaS at an Educatec-Educatice convention in Paris. I have no doubt that solutions are possible, but do remember that Peter has been continuing SoaS work singlehandedly for some time now. Looking forward, I see a dual challenge for Sugar Labs: supporting the XO installed base (including hopefully keeping XO-4 availability alive), and transitioning to the wild new world of handheld devices. Sean On Thu, Nov 7, 2013 at 12:21 AM, Sebastian Silva sebast...@fuentelibre.org wrote: El 06/11/13 17:35, Sean DALY escribió: On Mon, Nov 4, 2013 at 11:05 PM, Peter Robinson pbrobin...@gmail.com wrote: But you have for a long time refused to actually even market SoaS! That's right, at the time SoaS became an official Fedora spin, Mel and Sebastian decided to take over marketing, which included coming up with unmarketable names, linking with Fedora announcements, and opening a Fedora hosted minisite (the home of SoaS), none of which was done with any consultation of the SL marketing team. Please try to include last names, you mean Sebastian Dzallas, original developer of Sugar On A Stick. Now that we're on the topic... the concept Sugar On A Stick has several problems. 1.- It suggests it's the only possible Sugar OS on a USB. 2.- It suggests it's not a serious OS to be installed on a computer. 3.- It's impossible to translate. 4.- It suggests it's not regular GNU/Linux, with availability of the Myriad other GNU/Linux educational tools. Regards, Sebastian Silva R+D SomosAzúcar Sugar Labs Perú @icarito ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- David Farning Activity Central: http://www.activitycentral.com -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] new feature proposal for 102: sharing favorites
On Wed, Nov 6, 2013 at 8:03 AM, Daniel Narvaez dwnarv...@gmail.com wrote: I'm not quit convinced about the implementation, this really feels like something that should be stored in gconf/gsettings rather than using a dbus method. Might be a good idea to use gsettings directly here because it's basically a list of lists and the details of how you store those might differ between the two systems, making migration complicated. I'll look into it. Right now we use client.notify for changes to the view background and the number of views, but not as far as I know to the favorites. -walter On 5 November 2013 19:51, Walter Bender walter.ben...@gmail.com wrote: I've written up a new feature description to enable updating favorires through a dbus service [1]. Summary Since multiple homeviews landed in Sugar 100, it would be nice to enable user-space updates to the homeviews. This requires a new dbus service. The idea is that Sugar activities, e.g. ShareFavorites [2], could share favorites without requiring a reboot. So, for example, a teacher could share a desktop specific to a lesson plan. thank you for your consideration. -walter [1] http://wiki.sugarlabs.org/go/Features/UpdateFavorites [2] http://wiki.sugarlabs.org/go/Activities/ShareFavorites -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- 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] Sugar tryout (was Re: sugarlabs.org redesign)
Daniel - you mean the main download page [1], right? Not the VirtualBox page [2]? These and other wiki pages are indeed long and complex. We could break those out into a dozen subpages to keep each one manageable. This problem was meant to be solved by the new website template designed to replace the static main site. I believe Bernie has a stat tool for pages including the static main site, i remember seeing a report where traffic was like a thousand times more than usual after one of our press releases in the past. Conversion rate will both improve and remain very marginal as we streamline the existing structure since we haven't had press coverage for some time. I'm all for measuring, the number can only go up. However, without even measuring anything, there can be no doubt that every extra click will cost us downloads when we get press coverage rolling again. The best way to do it is to propose a default pair of pancake buttons (SoaS/VM) based on the visitor's OS and language, and hide the complex lists under an other systems and languages link. Adobe (Flash, Reader) and OOo do it like this. VirtualBox: I believe the installer autoconfigures itself for language (around 20 langs) after first screen in English, but we need to know if our VMs could autoconfigure for lang/keyb and if so, how much work that is, I imagine the alternative being a matrix of prebuilt machines by language (for sure that will be work). The learning curve and resources required is why I want to reach out to Oracle. For SoaS, I believe it has always been default US-en lang/keyb, we'd have to ask Peter if a reasonably simple solution for multiple languages is available - ideally, a language setup screen when first run. Sean 1. http://wiki.sugarlabs.org/go/DocumentationTeam/Try_Sugar 2. http://wiki.sugarlabs.org/go/VirtualBox On Fri, Nov 8, 2013 at 8:11 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Of course I agree with you that less barriers the better but I think we need to pick our battles. With current state of the downloads page I'd expect the conversion rate to near the 0%. It takes a *lot* of extra clicks to achieve the same. I propose that we * Rewrite the downloads page offering *simple* instruction only for Soas and Virtualbox. * Keep the current page somewhere on the wiki, prominently linked, it's fine for techies. * Start measuring conversion rate. I suspect we don't have a way to count the number of users that managed to reach the Sugar home. But measuring completed downloads would be a start. * Gradually get rid of as many barriers as possible and see how the rate is affected. On Friday, 8 November 2013, Sean DALY wrote: Of course it doesn't stop us from marketing, but it adds two extra hurdles for teachers to deal with (the GPL VirtualBox installer + the PUEL extension pack necessary for passthrough USB support). So techies won't care, but I guarantee a percentage of teachers will. It's a well-documented axiom of internet marketing that you lose up to 50% of prospects with every additional click - this is precisely why Amazon deployed 1-click purchases. With three clicks instead of one, I hope we don't lose 20%, 30%, 50% of interested teachers. After all, there's already a barrier: the huge size of the downloads. It's obvious given our limited resources we need to evaluate our most resource-effective ways of publishing prepared VMs. This is what I had in mind about approaching Oracle. But we need to try to maximize our potential conversion rate without additional hoops. I'd be happy with anything over 10% (software/SaaS average rate is roughly 7% [1]), and we won't even be gating the download in a contact form. My proposal two years ago to make VMs the preferred method for teachers to try Sugar met with opposition from Peter and others who preferred SoaS. Sean [1] http://www.marketingsherpa.com/article/chart/average-website-conversion-rates-industry# On Fri, Nov 8, 2013 at 5:49 PM, Daniel Narvaez dwnarv...@gmail.comwrote: Do we really need a single installer? I mean I see it would be ideal but it feels like it might be tricky licensing, implementation and maintenance wise. From what I understand from Thomas, after installing VirtualBox, it's just downloading and clicking on an icon (I should really try it but I'm on a bad connection these days). It might not be perfect but it doesn't really sound bad, what is stopping us marketing Sugar this way really? On Friday, 8 November 2013, Sean DALY wrote: Not only doable, has been done for some time now [1,2] and is multi-platform ( what I use to demo Sugar on a Mac) The Oracle PUEL license [3] very interestingly permits free redistribution for educational purposes, opening the possibility of a single installer, ideal for our needs. In the past I have suggested approaching Oracle for a marketing partnership under a CSR (corporate social responsibility) banner. Sean 1.
[Sugar-devel] sugar-emulator 0.98
Hi, I just see the sugar-emulator-0.98 package on my Ubuntu 14.04 and try to install.First, I want to say that it needs python-sugar3 as a dependency..This is the error that I get when try to launch it. Any ideas? alan@alan-pc:~/.sugar$ sugar-emulator Initializing built-in extension Generic Event ExtensionInitializing built-in extension SHAPEInitializing built-in extension MIT-SHMInitializing built-in extension XInputExtensionInitializing built-in extension XTESTInitializing built-in extension BIG-REQUESTSInitializing built-in extension SYNCInitializing built-in extension XKEYBOARDInitializing built-in extension XC-MISCInitializing built-in extension SECURITYInitializing built-in extension XINERAMAInitializing built-in extension XFIXESInitializing built-in extension RENDERInitializing built-in extension RANDRInitializing built-in extension COMPOSITEInitializing built-in extension DAMAGEInitializing built-in extension MIT-SCREEN-SAVERInitializing built-in extension DOUBLE-BUFFERInitializing built-in extension RECORDInitializing built-in extension DPMSInitializing built-in extension X-ResourceInitializing built-in extension XVideoInitializing built-in extension XVideo-MotionCompensationInitializing built-in extension SELinuxInitializing built-in extension GLX[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list![dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list![dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!1383949427.832693 STARTUP: Starting the shellERROR:root:Could not find any typelib for Xklg_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Regards! Alan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-emulator 0.98
libxklavier gir is either missing or too old. sugar should depend on it. On 8 November 2013 23:27, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Hi, I just see the sugar-emulator-0.98 package on my Ubuntu 14.04 and try to install. First, I want to say that it needs python-sugar3 as a dependency.. This is the error that I get when try to launch it. Any ideas? alan@alan-pc:~/.sugar$ sugar-emulator Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! 1383949427.832693 STARTUP: Starting the shell ERROR:root:Could not find any typelib for Xkl g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Regards! Alan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar tryout (was Re: sugarlabs.org redesign)
An observation, from the outside, about marketing discussions. Several times over the last couple of days a number of marketing related posts have started, I think we should Another, possibly more productive approach, might be to engage Sean, the marketing expert, in a discussion about why he thinks the way he does:) The premise is to build on each other's strengths which minimize the effects of individuals weakness. On Fri, Nov 8, 2013 at 4:20 PM, Sean DALY sdaly...@gmail.com wrote: Daniel - you mean the main download page [1], right? Not the VirtualBox page [2]? These and other wiki pages are indeed long and complex. We could break those out into a dozen subpages to keep each one manageable. This problem was meant to be solved by the new website template designed to replace the static main site. I believe Bernie has a stat tool for pages including the static main site, i remember seeing a report where traffic was like a thousand times more than usual after one of our press releases in the past. Conversion rate will both improve and remain very marginal as we streamline the existing structure since we haven't had press coverage for some time. I'm all for measuring, the number can only go up. However, without even measuring anything, there can be no doubt that every extra click will cost us downloads when we get press coverage rolling again. The best way to do it is to propose a default pair of pancake buttons (SoaS/VM) based on the visitor's OS and language, and hide the complex lists under an other systems and languages link. Adobe (Flash, Reader) and OOo do it like this. VirtualBox: I believe the installer autoconfigures itself for language (around 20 langs) after first screen in English, but we need to know if our VMs could autoconfigure for lang/keyb and if so, how much work that is, I imagine the alternative being a matrix of prebuilt machines by language (for sure that will be work). The learning curve and resources required is why I want to reach out to Oracle. For SoaS, I believe it has always been default US-en lang/keyb, we'd have to ask Peter if a reasonably simple solution for multiple languages is available - ideally, a language setup screen when first run. Sean 1. http://wiki.sugarlabs.org/go/DocumentationTeam/Try_Sugar 2. http://wiki.sugarlabs.org/go/VirtualBox On Fri, Nov 8, 2013 at 8:11 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Of course I agree with you that less barriers the better but I think we need to pick our battles. With current state of the downloads page I'd expect the conversion rate to near the 0%. It takes a *lot* of extra clicks to achieve the same. I propose that we * Rewrite the downloads page offering *simple* instruction only for Soas and Virtualbox. * Keep the current page somewhere on the wiki, prominently linked, it's fine for techies. * Start measuring conversion rate. I suspect we don't have a way to count the number of users that managed to reach the Sugar home. But measuring completed downloads would be a start. * Gradually get rid of as many barriers as possible and see how the rate is affected. On Friday, 8 November 2013, Sean DALY wrote: Of course it doesn't stop us from marketing, but it adds two extra hurdles for teachers to deal with (the GPL VirtualBox installer + the PUEL extension pack necessary for passthrough USB support). So techies won't care, but I guarantee a percentage of teachers will. It's a well-documented axiom of internet marketing that you lose up to 50% of prospects with every additional click - this is precisely why Amazon deployed 1-click purchases. With three clicks instead of one, I hope we don't lose 20%, 30%, 50% of interested teachers. After all, there's already a barrier: the huge size of the downloads. It's obvious given our limited resources we need to evaluate our most resource-effective ways of publishing prepared VMs. This is what I had in mind about approaching Oracle. But we need to try to maximize our potential conversion rate without additional hoops. I'd be happy with anything over 10% (software/SaaS average rate is roughly 7% [1]), and we won't even be gating the download in a contact form. My proposal two years ago to make VMs the preferred method for teachers to try Sugar met with opposition from Peter and others who preferred SoaS. Sean [1] http://www.marketingsherpa.com/article/chart/average-website-conversion-rates-industry# On Fri, Nov 8, 2013 at 5:49 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Do we really need a single installer? I mean I see it would be ideal but it feels like it might be tricky licensing, implementation and maintenance wise. From what I understand from Thomas, after installing VirtualBox, it's just downloading and clicking on an icon (I should really try it but I'm on a bad connection these days). It might not be perfect but it doesn't really sound bad, what is stopping us marketing
Re: [Sugar-devel] sugar-emulator 0.98
That error is not relevant, it's basically just exiting. What is before that? On 8 November 2013 23:37, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Ok. I have: libxklavier16 - 5.2.1-1ubuntu2 And I install: gir1.2-xkl-1.0 Now, I not receive the error of Xkl but Continue with: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. -- Date: Fri, 8 Nov 2013 23:31:24 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org libxklavier gir is either missing or too old. sugar should depend on it. On 8 November 2013 23:27, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Hi, I just see the sugar-emulator-0.98 package on my Ubuntu 14.04 and try to install. First, I want to say that it needs python-sugar3 as a dependency.. This is the error that I get when try to launch it. Any ideas? alan@alan-pc:~/.sugar$ sugar-emulator Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! 1383949427.832693 STARTUP: Starting the shell ERROR:root:Could not find any typelib for Xkl g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Regards! Alan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] different perspectives
On Fri, Nov 8, 2013 at 8:23 AM, Sean DALY sdaly...@gmail.com wrote: On Fri, Nov 8, 2013 at 1:56 AM, David Farning dfarn...@activitycentral.com wrote: The highest rate of progress happens when the parties focus on getting ahead of the other guys rather then when they focus on holding others back. Progress tends to stop when one party gets so far ahead that it is not worth it for others to compete. I don't disagree, but I would qualify that: The highest rate of progress happens when the parties focus on getting ahead of the other guys by changing the game. This is why I maintain that GNU/Linux distros considering each other as competitors is pointless at the end of the day when 92% or so of the desktop/laptop market is running MS Windows. Agreed. That is one of the reasons Google is maintaining such a tight hold on Android. They are trying to maintain the critical mass for the OS by preventing fragmentation. The downside becomes the somewhat extreme, by free software standards, they are using to maintain control of the project. Sean -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Performance: activities start up time
Well, should be good know what is happening, but these are real timings. I know the theory, and that probably was one of the reasons this was not done before, but this was what I found. Gonzalo On Fri, Nov 8, 2013 at 6:08 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Even more confused now... The two evince imports you are moving doesn't even cause the dynamic library to be loaded, so they should have absolutely no performance impact. That's the normal case in gobject-introspection, libraries are loaded lazily, when you try to use one of the functions. Gtk is an exception because gtk_init is called automatically on import and there are probably other libraries that do something similar. Though I verified that's not the case for Evince by looking at the smaps. On 8 November 2013 19:44, Gonzalo Odiard gonz...@laptop.org wrote: There are many issues in Sugar regarding performance, but one of the more visible to the user is how much time the activities take to start. This is not so evident in newer hardware, but is important in XO-1. Is so important than by example, Peru will use sugar 0.94 instead of a newer because o this. I was doing some testing with the main activities: https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=drive_web#gid=0 (These measures were done in a XO-1) I first blamed to the port from gtk2 to gtk3 of the big regressions in performance, but after looking with a little of detail, some can be solved easily. One of the arguments of the dynamic bindings was a better startup time due to not need initialize all the libraries until is needed use them. Then the import should be lighter than before. Looks like that is not so true. In the case of Write activity, I was able to reduce the start up in 7 or 8 seconds, just delaying the gstreamer initialization [1], and 1 or 2 seconds more delaying two other imports. In the case of Browse activity, just delaying the import of Evince libraries to the moment when a pdf is opened, improve the start up time in 13 seconds (patch attached). The start up time is even better than the version in 0.94 I think this work of identify big libraries used only in specific moments, can be applied in other cases. Gonzalo [1] http://git.sugarlabs.org/write/mainline/commit/5dd843cf415d0c65e2927540225b0098f2b71cd0 [2] http://git.sugarlabs.org/write/mainline/commit/dba223f5749f510735692a06f246acee30ab50bf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-emulator 0.98
After launch, appears the window (black background) and appears the sugar mouse pointer. After, the window closes.The error of dbus no appears ever.. only sometimes..The tail of the log: alan@alan-pc:~$ sugar-emulator Initializing built-in extension Generic Event ExtensionInitializing built-in extension SHAPE..Initializing built-in extension XVideo-MotionCompensationInitializing built-in extension SELinuxInitializing built-in extension GLX[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list![dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list![dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!1383951505.354225 STARTUP: Starting the shellAdvertencia del gestor de ventanas: Error fatal de E/S 11 (Recurso no disponible temporalmente) en la pantalla «:30». Date: Fri, 8 Nov 2013 23:45:14 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org That error is not relevant, it's basically just exiting. What is before that? On 8 November 2013 23:37, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Ok. I have: libxklavier16 - 5.2.1-1ubuntu2 And I install: gir1.2-xkl-1.0 Now, I not receive the error of Xkl but Continue with: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Date: Fri, 8 Nov 2013 23:31:24 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org libxklavier gir is either missing or too old. sugar should depend on it. On 8 November 2013 23:27, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Hi, I just see the sugar-emulator-0.98 package on my Ubuntu 14.04 and try to install.First, I want to say that it needs python-sugar3 as a dependency.. This is the error that I get when try to launch it. Any ideas? alan@alan-pc:~/.sugar$ sugar-emulator Initializing built-in extension Generic Event ExtensionInitializing built-in extension SHAPE Initializing built-in extension MIT-SHMInitializing built-in extension XInputExtensionInitializing built-in extension XTESTInitializing built-in extension BIG-REQUESTSInitializing built-in extension SYNC Initializing built-in extension XKEYBOARDInitializing built-in extension XC-MISCInitializing built-in extension SECURITYInitializing built-in extension XINERAMAInitializing built-in extension XFIXES Initializing built-in extension RENDERInitializing built-in extension RANDRInitializing built-in extension COMPOSITEInitializing built-in extension DAMAGEInitializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFERInitializing built-in extension RECORDInitializing built-in extension DPMSInitializing built-in extension X-ResourceInitializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensationInitializing built-in extension SELinuxInitializing built-in extension GLX[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!1383949427.832693 STARTUP: Starting the shellERROR:root:Could not find any typelib for Xklg_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Regards! Alan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar tryout (was Re: sugarlabs.org redesign)
Not sure what you are referring to. Personally I feel like Sean has already justified his positions in a convincing way. I'm simply trying to come up with a set of concrete development goals which are realistically achievable. There has been an years long disconnect between marketing and development. Closing that gap requires both parties to listen to each other, something which I feel has been happening in the last few days threads. On 8 November 2013 23:35, David Farning dfarn...@activitycentral.comwrote: An observation, from the outside, about marketing discussions. Several times over the last couple of days a number of marketing related posts have started, I think we should Another, possibly more productive approach, might be to engage Sean, the marketing expert, in a discussion about why he thinks the way he does:) The premise is to build on each other's strengths which minimize the effects of individuals weakness. On Fri, Nov 8, 2013 at 4:20 PM, Sean DALY sdaly...@gmail.com wrote: Daniel - you mean the main download page [1], right? Not the VirtualBox page [2]? These and other wiki pages are indeed long and complex. We could break those out into a dozen subpages to keep each one manageable. This problem was meant to be solved by the new website template designed to replace the static main site. I believe Bernie has a stat tool for pages including the static main site, i remember seeing a report where traffic was like a thousand times more than usual after one of our press releases in the past. Conversion rate will both improve and remain very marginal as we streamline the existing structure since we haven't had press coverage for some time. I'm all for measuring, the number can only go up. However, without even measuring anything, there can be no doubt that every extra click will cost us downloads when we get press coverage rolling again. The best way to do it is to propose a default pair of pancake buttons (SoaS/VM) based on the visitor's OS and language, and hide the complex lists under an other systems and languages link. Adobe (Flash, Reader) and OOo do it like this. VirtualBox: I believe the installer autoconfigures itself for language (around 20 langs) after first screen in English, but we need to know if our VMs could autoconfigure for lang/keyb and if so, how much work that is, I imagine the alternative being a matrix of prebuilt machines by language (for sure that will be work). The learning curve and resources required is why I want to reach out to Oracle. For SoaS, I believe it has always been default US-en lang/keyb, we'd have to ask Peter if a reasonably simple solution for multiple languages is available - ideally, a language setup screen when first run. Sean 1. http://wiki.sugarlabs.org/go/DocumentationTeam/Try_Sugar 2. http://wiki.sugarlabs.org/go/VirtualBox On Fri, Nov 8, 2013 at 8:11 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Of course I agree with you that less barriers the better but I think we need to pick our battles. With current state of the downloads page I'd expect the conversion rate to near the 0%. It takes a *lot* of extra clicks to achieve the same. I propose that we * Rewrite the downloads page offering *simple* instruction only for Soas and Virtualbox. * Keep the current page somewhere on the wiki, prominently linked, it's fine for techies. * Start measuring conversion rate. I suspect we don't have a way to count the number of users that managed to reach the Sugar home. But measuring completed downloads would be a start. * Gradually get rid of as many barriers as possible and see how the rate is affected. On Friday, 8 November 2013, Sean DALY wrote: Of course it doesn't stop us from marketing, but it adds two extra hurdles for teachers to deal with (the GPL VirtualBox installer + the PUEL extension pack necessary for passthrough USB support). So techies won't care, but I guarantee a percentage of teachers will. It's a well-documented axiom of internet marketing that you lose up to 50% of prospects with every additional click - this is precisely why Amazon deployed 1-click purchases. With three clicks instead of one, I hope we don't lose 20%, 30%, 50% of interested teachers. After all, there's already a barrier: the huge size of the downloads. It's obvious given our limited resources we need to evaluate our most resource-effective ways of publishing prepared VMs. This is what I had in mind about approaching Oracle. But we need to try to maximize our potential conversion rate without additional hoops. I'd be happy with anything over 10% (software/SaaS average rate is roughly 7% [1]), and we won't even be gating the download in a contact form. My proposal two years ago to make VMs the preferred method for teachers to try Sugar met with opposition from Peter and
Re: [Sugar-devel] sugar-emulator 0.98
The last message looks like it might be relevant but I can't quite parse that spanish. On 9 November 2013 00:00, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: After launch, appears the window (black background) and appears the sugar mouse pointer. After, the window closes. The error of dbus no appears ever.. only sometimes.. The tail of the log: alan@alan-pc:~$ sugar-emulator Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE ... ... Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! 1383951505.354225 STARTUP: Starting the shell Advertencia del gestor de ventanas: Error fatal de E/S 11 (Recurso no disponible temporalmente) en la pantalla «:30». -- Date: Fri, 8 Nov 2013 23:45:14 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org That error is not relevant, it's basically just exiting. What is before that? On 8 November 2013 23:37, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Ok. I have: libxklavier16 - 5.2.1-1ubuntu2 And I install: gir1.2-xkl-1.0 Now, I not receive the error of Xkl but Continue with: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. -- Date: Fri, 8 Nov 2013 23:31:24 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org libxklavier gir is either missing or too old. sugar should depend on it. On 8 November 2013 23:27, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Hi, I just see the sugar-emulator-0.98 package on my Ubuntu 14.04 and try to install. First, I want to say that it needs python-sugar3 as a dependency.. This is the error that I get when try to launch it. Any ideas? alan@alan-pc:~/.sugar$ sugar-emulator Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! 1383949427.832693 STARTUP: Starting the shell ERROR:root:Could not find any typelib for Xkl g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Regards! Alan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Performance: activities start up time
It's not just theory, I verified importing evince doesn't even cause the library to be loaded. I don't have a XO 1 to check what is going on myself, unfortunately. My suggestion is to *not* checkin this kind of workaround without any clue about why the change helps, and especially to *not* suggest people should do the same kind of change in other activities. That said, I don't maintain any of the activities so feel free to go ahead if you think it's a sensible approach (sigh). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-emulator 0.98
Oh I see, the 11 is not spanish :) It's a segfault. Does Xephyr run standalone? If it does, I suppose it's sugar crashing, you would need to run inside gdb to get more info. On 9 November 2013 00:05, Daniel Narvaez dwnarv...@gmail.com wrote: The last message looks like it might be relevant but I can't quite parse that spanish. On 9 November 2013 00:00, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: After launch, appears the window (black background) and appears the sugar mouse pointer. After, the window closes. The error of dbus no appears ever.. only sometimes.. The tail of the log: alan@alan-pc:~$ sugar-emulator Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE ... ... Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! 1383951505.354225 STARTUP: Starting the shell Advertencia del gestor de ventanas: Error fatal de E/S 11 (Recurso no disponible temporalmente) en la pantalla «:30». -- Date: Fri, 8 Nov 2013 23:45:14 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org That error is not relevant, it's basically just exiting. What is before that? On 8 November 2013 23:37, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Ok. I have: libxklavier16 - 5.2.1-1ubuntu2 And I install: gir1.2-xkl-1.0 Now, I not receive the error of Xkl but Continue with: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. -- Date: Fri, 8 Nov 2013 23:31:24 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org libxklavier gir is either missing or too old. sugar should depend on it. On 8 November 2013 23:27, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Hi, I just see the sugar-emulator-0.98 package on my Ubuntu 14.04 and try to install. First, I want to say that it needs python-sugar3 as a dependency.. This is the error that I get when try to launch it. Any ideas? alan@alan-pc:~/.sugar$ sugar-emulator Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! 1383949427.832693 STARTUP: Starting the shell ERROR:root:Could not find any typelib for Xkl g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Regards! Alan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org
Re: [Sugar-devel] sugar-emulator 0.98
Yes, I can run: Xephyr :30 without problems.. Date: Sat, 9 Nov 2013 00:40:31 +0100 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org Subject: Re: [Sugar-devel] sugar-emulator 0.98 Oh I see, the 11 is not spanish :) It's a segfault. Does Xephyr run standalone? If it does, I suppose it's sugar crashing, you would need to run inside gdb to get more info. On 9 November 2013 00:05, Daniel Narvaez dwnarv...@gmail.com wrote: The last message looks like it might be relevant but I can't quite parse that spanish. On 9 November 2013 00:00, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: After launch, appears the window (black background) and appears the sugar mouse pointer. After, the window closes.The error of dbus no appears ever.. only sometimes..The tail of the log: alan@alan-pc:~$ sugar-emulator Initializing built-in extension Generic Event ExtensionInitializing built-in extension SHAPE... ...Initializing built-in extension XVideo-MotionCompensationInitializing built-in extension SELinuxInitializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list![dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!1383951505.354225 STARTUP: Starting the shell Advertencia del gestor de ventanas: Error fatal de E/S 11 (Recurso no disponible temporalmente) en la pantalla «:30». Date: Fri, 8 Nov 2013 23:45:14 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org That error is not relevant, it's basically just exiting. What is before that? On 8 November 2013 23:37, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Ok. I have: libxklavier16 - 5.2.1-1ubuntu2 And I install: gir1.2-xkl-1.0 Now, I not receive the error of Xkl but Continue with: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Date: Fri, 8 Nov 2013 23:31:24 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org libxklavier gir is either missing or too old. sugar should depend on it. On 8 November 2013 23:27, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Hi, I just see the sugar-emulator-0.98 package on my Ubuntu 14.04 and try to install.First, I want to say that it needs python-sugar3 as a dependency.. This is the error that I get when try to launch it. Any ideas? alan@alan-pc:~/.sugar$ sugar-emulator Initializing built-in extension Generic Event ExtensionInitializing built-in extension SHAPE Initializing built-in extension MIT-SHMInitializing built-in extension XInputExtensionInitializing built-in extension XTESTInitializing built-in extension BIG-REQUESTSInitializing built-in extension SYNC Initializing built-in extension XKEYBOARDInitializing built-in extension XC-MISCInitializing built-in extension SECURITYInitializing built-in extension XINERAMAInitializing built-in extension XFIXES Initializing built-in extension RENDERInitializing built-in extension RANDRInitializing built-in extension COMPOSITEInitializing built-in extension DAMAGEInitializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFERInitializing built-in extension RECORDInitializing built-in extension DPMSInitializing built-in extension X-ResourceInitializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensationInitializing built-in extension SELinuxInitializing built-in extension GLX[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!1383949427.832693 STARTUP: Starting the shellERROR:root:Could not find any typelib for Xklg_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Regards! Alan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel
[Sugar-devel] Role of Sugar Labs in the ecosystem.
In conjunction the with Sugar Roadmap thread I would like to bring up another rather strategic issue. Namely, what role does Sugar Labs want to play in the ecosystem. The question become important because at this point Sugar Labs is the closest thing the ecosystem has to a gravitational center. These hand-wavy strategy questions are real questions which users and deployers are going to ask before they commit to Sugar. Is Sugar Labs 'just a free software project' or is it the center and leaders of a global educational project? or somewhere in between? Either is fine as long as the behavior is predictable and consistent. -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-emulator 0.98
I don't know how you could run sugar inside gdb exactly. Last time I had a segfault at startup I resorted to a bunch of prints to figure out which line was crashing (sigh). Maybe try something like this Xephyr :100 export DISPLAY=:100 gdb dbus-launch run sugar On 9 November 2013 00:43, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Yes, I can run: Xephyr :30 without problems.. -- Date: Sat, 9 Nov 2013 00:40:31 +0100 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org Subject: Re: [Sugar-devel] sugar-emulator 0.98 Oh I see, the 11 is not spanish :) It's a segfault. Does Xephyr run standalone? If it does, I suppose it's sugar crashing, you would need to run inside gdb to get more info. On 9 November 2013 00:05, Daniel Narvaez dwnarv...@gmail.com wrote: The last message looks like it might be relevant but I can't quite parse that spanish. On 9 November 2013 00:00, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: After launch, appears the window (black background) and appears the sugar mouse pointer. After, the window closes. The error of dbus no appears ever.. only sometimes.. The tail of the log: alan@alan-pc:~$ sugar-emulator Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE ... ... Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! 1383951505.354225 STARTUP: Starting the shell Advertencia del gestor de ventanas: Error fatal de E/S 11 (Recurso no disponible temporalmente) en la pantalla «:30». -- Date: Fri, 8 Nov 2013 23:45:14 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org That error is not relevant, it's basically just exiting. What is before that? On 8 November 2013 23:37, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Ok. I have: libxklavier16 - 5.2.1-1ubuntu2 And I install: gir1.2-xkl-1.0 Now, I not receive the error of Xkl but Continue with: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. -- Date: Fri, 8 Nov 2013 23:31:24 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org libxklavier gir is either missing or too old. sugar should depend on it. On 8 November 2013 23:27, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Hi, I just see the sugar-emulator-0.98 package on my Ubuntu 14.04 and try to install. First, I want to say that it needs python-sugar3 as a dependency.. This is the error that I get when try to launch it. Any ideas? alan@alan-pc:~/.sugar$ sugar-emulator Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! 1383949427.832693 STARTUP: Starting
Re: [Sugar-devel] Role of Sugar Labs in the ecosystem.
IAEP! :) On 9 November 2013 00:45, David Farning dfarn...@activitycentral.comwrote: In conjunction the with Sugar Roadmap thread I would like to bring up another rather strategic issue. Namely, what role does Sugar Labs want to play in the ecosystem. The question become important because at this point Sugar Labs is the closest thing the ecosystem has to a gravitational center. These hand-wavy strategy questions are real questions which users and deployers are going to ask before they commit to Sugar. Is Sugar Labs 'just a free software project' or is it the center and leaders of a global educational project? or somewhere in between? Either is fine as long as the behavior is predictable and consistent. -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Role of Sugar Labs in the ecosystem.
Sorry, I forgot about that list. On Fri, Nov 8, 2013 at 5:55 PM, Daniel Narvaez dwnarv...@gmail.com wrote: IAEP! :) On 9 November 2013 00:45, David Farning dfarn...@activitycentral.com wrote: In conjunction the with Sugar Roadmap thread I would like to bring up another rather strategic issue. Namely, what role does Sugar Labs want to play in the ecosystem. The question become important because at this point Sugar Labs is the closest thing the ecosystem has to a gravitational center. These hand-wavy strategy questions are real questions which users and deployers are going to ask before they commit to Sugar. Is Sugar Labs 'just a free software project' or is it the center and leaders of a global educational project? or somewhere in between? Either is fine as long as the behavior is predictable and consistent. -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
If these are the SKU 311 units the Manufacturing Data on the wiki implies they have membrane keyboards. If so I don't see any reason using the keyboard manufacturing tags used for previous Nepali manufacturing runs (or used testing out the settings in /etc/sysconfig/keyboard manually) shouldn't work. The %/X key will just become the language key again. But if no virtual keyboard exists for Nepali you will not have touchscreen/virtual keyboard access to that language. On Fri, Nov 8, 2013 at 11:41 AM, Walter Bender walter.ben...@gmail.comwrote: I believe Basanta said that they were the hard click keyboards On Fri, Nov 8, 2013 at 11:39 AM, Daniel Drake d...@laptop.org wrote: On Thu, Nov 7, 2013 at 11:23 PM, Basanta Shrestha basanta.shres...@olenepal.org wrote: But for XO-4 we will just be getting ones with English layout. I was wondering how we can enable nepali keyboard input on it. Are these keyboards hard/clicky/high-school style, or soft/membrane? Daniel ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap.
On 8 November 2013 13:10, Walter Bender walter.ben...@gmail.com wrote: Classmate and Classmate variants are already quick wide spread in some deployments, e.g., Argentina I wonder if we should try to get some classmates in the hands of Sugar Labs community members. It seems like the most solid hardware option we have for deployments at the moment. * Chromebook At least one deployment is looking at this option. Looking forward to know how this goes :) Another couple more for community evaluation (evaluation, testing, marketing) * Linux compatible ARM boards * Virtualbox SoaS is our current offering for Virtualbox (As you pointed out in a previous thread, it is a two-step process to install. In my experience, that is 1 too many for our audience. Something we may be able to address by approaching some of the VM suppliers.) We are crossing threads here but... I think it would be great to have a single installer but (without having tried it!) the current installation process doesn't seem terribly bad. I feel that documenting it better and turning it into the first thing you see when you click downloads could go a long way. - RD resources I feel balance with addressing existing deployments needs is not a question Sugar Labs can or should answer. We should encourage and support both, it's up to companies and volunteers involved to see how much of either they could or should be doing. +1 That said, the discipline you have imparted on us regarding unit tests is a step that the community can take. Maybe one of our priorities should be to dust off some basic automatic testing for activities as well. OLPC used to have such a system in place. Of course I'm all for more unit tests :) The buildbot is already trying to start and close activities on every build but it would be great if people wrote more comprehensive unit and UI tests, similarly to what we are doing in the shell. Get them to run into sugar-build/buildbot would be trivial... We are not a company, we have no resources to allocate. But there are lots of concrete things we can do to encourage people to allocate them. I'm really glad to see that Activity Central figured out how to devote resources to RD. I hope you will be able to keep it up and more people will follow that example. We can leverage initiatives like Google Code. We can try crowd funding. We can apply for grants, as we have been doing sometimes successfully. We can keep lowering the barriers for volunteers, we have been making great progress on that. We can finally solve the un-marketability issue, attracting attention and energies and hence hopefully contributions. Google Code In starts on Nov. 18. But we can keep adding tasks over the course of the contest. Please don't be shy about suggesting tasks. And we could also use a few more mentors. I don't think I'm able to commit to be an official mentor but, as usual, I'll be answering as many questions as possible in irc/mailing lists when I am around. Sort of thinking to puth GConf - GSettings on the list... And Wayland support but that's probably too complex for GCI. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-emulator 0.98
FYI: sugar build works fine.. I try remove the ~/.sugar folder and I can select the sugar icon color!But after.. it mantain the black background without any progress. I check the shell.log and I get: 1383955588.869857 ERROR root: Could not find any typelib for GtkSourceTraceback (most recent call last): File /usr/bin/sugar-session, line 352, in module main() File /usr/bin/sugar-session, line 333, in mainstart_home() File /usr/bin/sugar-session, line 257, in start_homefrom jarabe.desktop import homewindow File /usr/lib/python2.7/dist-packages/jarabe/desktop/homewindow.py, line 29, in modulefrom jarabe.desktop.homebox import HomeBox File /usr/lib/python2.7/dist-packages/jarabe/desktop/homebox.py, line 28, in modulefrom jarabe.desktop import favoritesview File /usr/lib/python2.7/dist-packages/jarabe/desktop/favoritesview.py, line 41, in modulefrom jarabe.view.palettes import JournalPalette File /usr/lib/python2.7/dist-packages/jarabe/view/palettes.py, line 39, in modulefrom jarabe.view.viewsource import setup_view_source File /usr/lib/python2.7/dist-packages/jarabe/view/viewsource.py, line 30, in modulefrom gi.repository import GtkSourceImportError: cannot import name GtkSource Another missing package? Date: Sat, 9 Nov 2013 00:51:49 +0100 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org Subject: Re: [Sugar-devel] sugar-emulator 0.98 I don't know how you could run sugar inside gdb exactly. Last time I had a segfault at startup I resorted to a bunch of prints to figure out which line was crashing (sigh). Maybe try something like this Xephyr :100 export DISPLAY=:100 gdb dbus-launch run sugar On 9 November 2013 00:43, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Yes, I can run: Xephyr :30 without problems.. Date: Sat, 9 Nov 2013 00:40:31 +0100 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org Subject: Re: [Sugar-devel] sugar-emulator 0.98 Oh I see, the 11 is not spanish :) It's a segfault. Does Xephyr run standalone? If it does, I suppose it's sugar crashing, you would need to run inside gdb to get more info. On 9 November 2013 00:05, Daniel Narvaez dwnarv...@gmail.com wrote: The last message looks like it might be relevant but I can't quite parse that spanish. On 9 November 2013 00:00, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: After launch, appears the window (black background) and appears the sugar mouse pointer. After, the window closes.The error of dbus no appears ever.. only sometimes..The tail of the log: alan@alan-pc:~$ sugar-emulator Initializing built-in extension Generic Event ExtensionInitializing built-in extension SHAPE... ...Initializing built-in extension XVideo-MotionCompensationInitializing built-in extension SELinuxInitializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list![dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!1383951505.354225 STARTUP: Starting the shell Advertencia del gestor de ventanas: Error fatal de E/S 11 (Recurso no disponible temporalmente) en la pantalla «:30». Date: Fri, 8 Nov 2013 23:45:14 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org That error is not relevant, it's basically just exiting. What is before that? On 8 November 2013 23:37, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Ok. I have: libxklavier16 - 5.2.1-1ubuntu2 And I install: gir1.2-xkl-1.0 Now, I not receive the error of Xkl but Continue with: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Date: Fri, 8 Nov 2013 23:31:24 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org libxklavier gir is either missing or too old. sugar should depend on it. On 8 November 2013 23:27, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Hi, I just see the sugar-emulator-0.98 package on my Ubuntu 14.04 and try to install.First, I want to say that it needs python-sugar3 as a dependency.. This is the error that I get when try to launch it. Any ideas? alan@alan-pc:~/.sugar$ sugar-emulator Initializing built-in extension Generic Event ExtensionInitializing built-in extension SHAPE Initializing built-in extension MIT-SHMInitializing built-in extension XInputExtensionInitializing built-in extension XTESTInitializing built-in
Re: [Sugar-devel] Role of Sugar Labs in the ecosystem.
Haha, no, it was meant to be an answer to your question... It's an education project. On 9 November 2013 01:03, David Farning dfarn...@activitycentral.comwrote: Sorry, I forgot about that list. On Fri, Nov 8, 2013 at 5:55 PM, Daniel Narvaez dwnarv...@gmail.com wrote: IAEP! :) On 9 November 2013 00:45, David Farning dfarn...@activitycentral.com wrote: In conjunction the with Sugar Roadmap thread I would like to bring up another rather strategic issue. Namely, what role does Sugar Labs want to play in the ecosystem. The question become important because at this point Sugar Labs is the closest thing the ecosystem has to a gravitational center. These hand-wavy strategy questions are real questions which users and deployers are going to ask before they commit to Sugar. Is Sugar Labs 'just a free software project' or is it the center and leaders of a global educational project? or somewhere in between? Either is fine as long as the behavior is predictable and consistent. -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- David Farning Activity Central: http://www.activitycentral.com -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-emulator 0.98
It's sort of worrying that using an old profile causes a crash. Yes, that's a missing dependency (please report all of those to launchpad). http://packages.ubuntu.com/trusty/gir1.2-gtksource-3.0 On 9 November 2013 01:20, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: FYI: sugar build works fine.. I try remove the ~/.sugar folder and I can select the sugar icon color! But after.. it mantain the black background without any progress. I check the shell.log and I get: 1383955588.869857 ERROR root: Could not find any typelib for GtkSource Traceback (most recent call last): File /usr/bin/sugar-session, line 352, in module main() File /usr/bin/sugar-session, line 333, in main start_home() File /usr/bin/sugar-session, line 257, in start_home from jarabe.desktop import homewindow File /usr/lib/python2.7/dist-packages/jarabe/desktop/homewindow.py, line 29, in module from jarabe.desktop.homebox import HomeBox File /usr/lib/python2.7/dist-packages/jarabe/desktop/homebox.py, line 28, in module from jarabe.desktop import favoritesview File /usr/lib/python2.7/dist-packages/jarabe/desktop/favoritesview.py, line 41, in module from jarabe.view.palettes import JournalPalette File /usr/lib/python2.7/dist-packages/jarabe/view/palettes.py, line 39, in module from jarabe.view.viewsource import setup_view_source File /usr/lib/python2.7/dist-packages/jarabe/view/viewsource.py, line 30, in module from gi.repository import GtkSource ImportError: cannot import name GtkSource Another missing package? -- Date: Sat, 9 Nov 2013 00:51:49 +0100 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org Subject: Re: [Sugar-devel] sugar-emulator 0.98 I don't know how you could run sugar inside gdb exactly. Last time I had a segfault at startup I resorted to a bunch of prints to figure out which line was crashing (sigh). Maybe try something like this Xephyr :100 export DISPLAY=:100 gdb dbus-launch run sugar On 9 November 2013 00:43, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Yes, I can run: Xephyr :30 without problems.. -- Date: Sat, 9 Nov 2013 00:40:31 +0100 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org Subject: Re: [Sugar-devel] sugar-emulator 0.98 Oh I see, the 11 is not spanish :) It's a segfault. Does Xephyr run standalone? If it does, I suppose it's sugar crashing, you would need to run inside gdb to get more info. On 9 November 2013 00:05, Daniel Narvaez dwnarv...@gmail.com wrote: The last message looks like it might be relevant but I can't quite parse that spanish. On 9 November 2013 00:00, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: After launch, appears the window (black background) and appears the sugar mouse pointer. After, the window closes. The error of dbus no appears ever.. only sometimes.. The tail of the log: alan@alan-pc:~$ sugar-emulator Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE ... ... Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! 1383951505.354225 STARTUP: Starting the shell Advertencia del gestor de ventanas: Error fatal de E/S 11 (Recurso no disponible temporalmente) en la pantalla «:30». -- Date: Fri, 8 Nov 2013 23:45:14 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org That error is not relevant, it's basically just exiting. What is before that? On 8 November 2013 23:37, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Ok. I have: libxklavier16 - 5.2.1-1ubuntu2 And I install: gir1.2-xkl-1.0 Now, I not receive the error of Xkl but Continue with: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. -- Date: Fri, 8 Nov 2013 23:31:24 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org libxklavier gir is either missing or too old. sugar should depend on it. On 8 November 2013 23:27, Alan Jhonn Aguiar Schwyn alan...@hotmail.comwrote: Hi, I just see the
Re: [Sugar-devel] sugar-emulator 0.98
I install that and now it works perfectly! Lot of thanks!!! Date: Sat, 9 Nov 2013 01:25:37 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org It's sort of worrying that using an old profile causes a crash. Yes, that's a missing dependency (please report all of those to launchpad). http://packages.ubuntu.com/trusty/gir1.2-gtksource-3.0 On 9 November 2013 01:20, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: FYI: sugar build works fine.. I try remove the ~/.sugar folder and I can select the sugar icon color!But after.. it mantain the black background without any progress. I check the shell.log and I get: 1383955588.869857 ERROR root: Could not find any typelib for GtkSourceTraceback (most recent call last): File /usr/bin/sugar-session, line 352, in module main() File /usr/bin/sugar-session, line 333, in mainstart_home() File /usr/bin/sugar-session, line 257, in start_homefrom jarabe.desktop import homewindow File /usr/lib/python2.7/dist-packages/jarabe/desktop/homewindow.py, line 29, in modulefrom jarabe.desktop.homebox import HomeBox File /usr/lib/python2.7/dist-packages/jarabe/desktop/homebox.py, line 28, in module from jarabe.desktop import favoritesview File /usr/lib/python2.7/dist-packages/jarabe/desktop/favoritesview.py, line 41, in modulefrom jarabe.view.palettes import JournalPalette File /usr/lib/python2.7/dist-packages/jarabe/view/palettes.py, line 39, in modulefrom jarabe.view.viewsource import setup_view_source File /usr/lib/python2.7/dist-packages/jarabe/view/viewsource.py, line 30, in module from gi.repository import GtkSourceImportError: cannot import name GtkSource Another missing package? Date: Sat, 9 Nov 2013 00:51:49 +0100 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org Subject: Re: [Sugar-devel] sugar-emulator 0.98 I don't know how you could run sugar inside gdb exactly. Last time I had a segfault at startup I resorted to a bunch of prints to figure out which line was crashing (sigh). Maybe try something like this Xephyr :100 export DISPLAY=:100 gdb dbus-launch run sugar On 9 November 2013 00:43, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Yes, I can run: Xephyr :30 without problems.. Date: Sat, 9 Nov 2013 00:40:31 +0100 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org Subject: Re: [Sugar-devel] sugar-emulator 0.98 Oh I see, the 11 is not spanish :) It's a segfault. Does Xephyr run standalone? If it does, I suppose it's sugar crashing, you would need to run inside gdb to get more info. On 9 November 2013 00:05, Daniel Narvaez dwnarv...@gmail.com wrote: The last message looks like it might be relevant but I can't quite parse that spanish. On 9 November 2013 00:00, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: After launch, appears the window (black background) and appears the sugar mouse pointer. After, the window closes.The error of dbus no appears ever.. only sometimes..The tail of the log: alan@alan-pc:~$ sugar-emulator Initializing built-in extension Generic Event ExtensionInitializing built-in extension SHAPE... ...Initializing built-in extension XVideo-MotionCompensationInitializing built-in extension SELinuxInitializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list![dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list![dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!1383951505.354225 STARTUP: Starting the shell Advertencia del gestor de ventanas: Error fatal de E/S 11 (Recurso no disponible temporalmente) en la pantalla «:30». Date: Fri, 8 Nov 2013 23:45:14 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org That error is not relevant, it's basically just exiting. What is before that? On 8 November 2013 23:37, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote: Ok. I have: libxklavier16 - 5.2.1-1ubuntu2 And I install: gir1.2-xkl-1.0 Now, I not receive the error of Xkl but Continue with: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Date: Fri, 8 Nov 2013 23:31:24 +0100 Subject: Re: [Sugar-devel] sugar-emulator 0.98 From: dwnarv...@gmail.com To: alan...@hotmail.com CC: sugar-devel@lists.sugarlabs.org libxklavier gir is either missing or too old. sugar should depend on it. On 8 November 2013 23:27, Alan Jhonn Aguiar Schwyn
Re: [Sugar-devel] Sugar Labs Roadmap.
On Fri, Nov 8, 2013 at 7:19 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 8 November 2013 13:10, Walter Bender walter.ben...@gmail.com wrote: Classmate and Classmate variants are already quick wide spread in some deployments, e.g., Argentina I wonder if we should try to get some classmates in the hands of Sugar Labs community members. It seems like the most solid hardware option we have for deployments at the moment. I'll look into it. * Chromebook At least one deployment is looking at this option. Looking forward to know how this goes :) Another couple more for community evaluation (evaluation, testing, marketing) * Linux compatible ARM boards * Virtualbox SoaS is our current offering for Virtualbox (As you pointed out in a previous thread, it is a two-step process to install. In my experience, that is 1 too many for our audience. Something we may be able to address by approaching some of the VM suppliers.) We are crossing threads here but... I think it would be great to have a single installer but (without having tried it!) the current installation process doesn't seem terribly bad. I feel that documenting it better and turning it into the first thing you see when you click downloads could go a long way. - RD resources I feel balance with addressing existing deployments needs is not a question Sugar Labs can or should answer. We should encourage and support both, it's up to companies and volunteers involved to see how much of either they could or should be doing. +1 That said, the discipline you have imparted on us regarding unit tests is a step that the community can take. Maybe one of our priorities should be to dust off some basic automatic testing for activities as well. OLPC used to have such a system in place. Of course I'm all for more unit tests :) The buildbot is already trying to start and close activities on every build but it would be great if people wrote more comprehensive unit and UI tests, similarly to what we are doing in the shell. Get them to run into sugar-build/buildbot would be trivial... Maybe we can work on an example for an activity and then propagate (via GCI). We are not a company, we have no resources to allocate. But there are lots of concrete things we can do to encourage people to allocate them. I'm really glad to see that Activity Central figured out how to devote resources to RD. I hope you will be able to keep it up and more people will follow that example. We can leverage initiatives like Google Code. We can try crowd funding. We can apply for grants, as we have been doing sometimes successfully. We can keep lowering the barriers for volunteers, we have been making great progress on that. We can finally solve the un-marketability issue, attracting attention and energies and hence hopefully contributions. Google Code In starts on Nov. 18. But we can keep adding tasks over the course of the contest. Please don't be shy about suggesting tasks. And we could also use a few more mentors. I don't think I'm able to commit to be an official mentor but, as usual, I'll be answering as many questions as possible in irc/mailing lists when I am around. Sort of thinking to puth GConf - GSettings on the list... And Wayland support but that's probably too complex for GCI. GConf to GSettings is definitely GCI caliber introductory task worthy. -- 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] My proposals to improve sugar:
2013/11/6 Flavio Danesse fdane...@gmail.com Thanks Daniel , I'll try again. I tried on several occasions to contribute in this way, but I see two problems : Generally not work in ubuntu and has the disadvantage that you can not prove what you do on the xo . The other problem is the time of applying patches , that is, if you get excited to make big changes with several days , in the code , you run the risk that none of the patches are applied. In my case , I think it would be better to work with someone who has the ability to fast track the contributions of code so you can go as you apply them or you can send instantly to object to keep moving forward in development. Walter : Thanks for the Spanish :) On the topic of mentoring in the contest , like last year, I prefer not to participate due to my limited English, if you like the ideas , feel free to post them for me, I 'd appreciate it. Gracias Daniel, intentaré nuevamente. Probé en varias oportunidades aportar de esta forma, pero le veo dos problemas: Generalmente no funcionaba en ubuntu y tiene el inconveniente de que no puedes probar lo que haces en la xo. El otro problema es el tiempo de aplicación de los parches, o sea, si te entusiasmas a hacer grandes modificaciones que lleven varios dias, en el código, corres el riesgo de que ninguno de los parches se apliquen. Una buena forma de solucionar esto, es hacer un parche grande, pero con commits muy atomicos, es decir, commits muy chicos para que sea mas fácil la revisión, y mejor el detalle de cada fragmento. Ademas de ser buena practica para no perderse uno mismo. Es una practica aveces muy dificil, pero hay buenas herramientas para uno exigirse a si mismo de hacerlo, como por ejemplo un reloj o alguna aplicación web que haga la tecnica de pomodoro. A good way to fix this is to make a large patch, but with very atomic commits, ie commits too small to make it easier to review, and better detail of each fragment. Apart from being good practice to not lose oneself. It is a practice sometimes difficult, but there are good tools to require yourself, such as a clock or any web application with pomodoro technique. En mi caso, creo que sería mejor trabajar en conjunto con alguien que tenga la capacidad de hacer un seguimiento rápido de los aportes de código de forma que pueda ir aplicándolos a medida que se envian o que pueda poner objeciones al instante para que no siga avanzando en el desarrollo. Veo que el código esta en en github, entonces esta la buena practica/herramienta de pull-request, para tener feedback rápido y poder hacer modificaciones que uno no ve y otros si. I see that the code is on github, then this good practice/tool pull-request method, to have quick feedback and to make changes that yourself not see but other colleagues can see. Walter: Gracias por el español :) Con respecto al tema de ser mentor en el concurso, al igual que el año pasado, prefiero no participar debido a mi limitado inglés, si te gustan las ideas propuestas, sientete en libertad de publicarlas por mi, yo te lo agradecería. 2013/11/6 Daniel Narvaez dwnarv...@gmail.com 2013/11/7 Flavio Danesse fdane...@gmail.com What someone explain a simple way to contribute code to sugar, I'm 5 years ago and I have been able to do so (the timers need help). Did you see these docs http://developer.sugarlabs.org/dev-environment.md.html http://developer.sugarlabs.org/contributing.md.html Happy to help out, here or in irc, if you run into any issues. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Están muy buenas las ideas que propusiste, quizás podemos levantar algún ticket! Very good ideas you proposed, perhaps we can raise a ticket! -- Roger Activity Central http://activitycentral.com/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
They are hard/clicky ones. On Fri, Nov 8, 2013 at 10:24 PM, Daniel Drake d...@laptop.org wrote: On Thu, Nov 7, 2013 at 11:23 PM, Basanta Shrestha basanta.shres...@olenepal.org wrote: But for XO-4 we will just be getting ones with English layout. I was wondering how we can enable nepali keyboard input on it. Are these keyboards hard/clicky/high-school style, or soft/membrane? Daniel -- Basanta Shrestha Network Engineer Open Learning Exchange (OLE) Nepal Tel: +977.1.551, 5520075 Ext. 303 Cell: +977.9818 605110 http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Performance: activities start up time
Can you explain me how you verified the library was not loaded? Gonzalo On Fri, Nov 8, 2013 at 8:16 PM, Daniel Narvaez dwnarv...@gmail.com wrote: It's not just theory, I verified importing evince doesn't even cause the library to be loaded. I don't have a XO 1 to check what is going on myself, unfortunately. My suggestion is to *not* checkin this kind of workaround without any clue about why the change helps, and especially to *not* suggest people should do the same kind of change in other activities. That said, I don't maintain any of the activities so feel free to go ahead if you think it's a sensible approach (sigh). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Performance: activities start up time
In my system, using strace -e trace=open,close,read,write,connect,accept -p pid in another terminal, when I do: from gi.repository import EvinceDocument I see: open(gi.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(gimodule.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(gi.py, O_RDONLY) = -1 ENOENT (No such file or directory) open(gi.pyc, O_RDONLY)= -1 ENOENT (No such file or directory) open(/usr/bin/gi.so, O_RDONLY)= -1 ENOENT (No such file or directory) open(/usr/bin/gimodule.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/bin/gi.py, O_RDONLY)= -1 ENOENT (No such file or directory) open(/usr/bin/gi.pyc, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/gi.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/gimodule.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/gi.py, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/gi.pyc, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/plat-linux2/gi.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/plat-linux2/gimodule.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/plat-linux2/gi.py, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/plat-linux2/gi.pyc, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/lib-tk/gi.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/lib-tk/gimodule.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/lib-tk/gi.py, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/lib-tk/gi.pyc, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/lib-dynload/gi.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/lib-dynload/gimodule.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/lib-dynload/gi.py, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/lib-dynload/gi.pyc, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/site-packages/gi/__init__.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/site-packages/gi/__init__module.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/site-packages/gi/__init__.py, O_RDONLY) = 5 open(/usr/lib64/python2.7/site-packages/gi/__init__.pyc, O_RDONLY) = 6 read(6, \3\363\r\nn;\324Pc\0\0\0\0\0\0\0\0\3\0\0\0@@\0\0s\311\0\0\0d\0..., 4096) = 2118 read(6, , 4096) = 0 close(6)= 0 open(/usr/lib64/python2.7/site-packages/gi/_gi.so, O_RDONLY) = 7 open(/usr/lib64/python2.7/site-packages/gi/_gi.so, O_RDONLY|O_CLOEXEC) = 8 read(8, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\220\216\0\0\0\0\0\0..., 832) = 832 close(8)= 0 open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 8 close(8)= 0 open(/lib64/libgirepository-1.0.so.1, O_RDONLY|O_CLOEXEC) = 8 read(8, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\\177\0\2167\0\0\0..., 832) = 832 close(8)= 0 open(/lib64/libgobject-2.0.so.0, O_RDONLY|O_CLOEXEC) = 8 read(8, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\240\253\340j7\0\0\0..., 832) = 832 close(8)= 0 open(/lib64/libglib-2.0.so.0, O_RDONLY|O_CLOEXEC) = 8 read(8, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0P\240\341i7\0\0\0..., 832) = 832 close(8)= 0 open(/lib64/libpyglib-gi-2.0-python.so.0, O_RDONLY|O_CLOEXEC) = 8 read(8, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0p\32\0\0\0\0\0\0..., 832) = 832 close(8)= 0 open(/lib64/libgmodule-2.0.so.0, O_RDONLY|O_CLOEXEC) = 8 read(8, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\\21 k7\0\0\0..., 832) = 832 close(8)= 0 open(/lib64/librt.so.1, O_RDONLY|O_CLOEXEC) = 8 read(8, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\240\`h7\0\0\0..., 832) = 832 close(8)= 0 open(/lib64/libgio-2.0.so.0, O_RDONLY|O_CLOEXEC) = 8 read(8, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\0\1ck7\0\0\0..., 832) = 832 close(8)= 0 open(/lib64/libgthread-2.0.so.0, O_RDONLY|O_CLOEXEC) = 8 read(8, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\260\6\240j7\0\0\0..., 832) = 832 close(8)= 0 open(/usr/lib64/python2.7/site-packages/gi/_gobject/__init__.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/site-packages/gi/_gobject/__init__module.so, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.7/site-packages/gi/_gobject/__init__.py, O_RDONLY) = 8
Re: [Sugar-devel] Sugar Labs Roadmap.
Does anyone else want to add their thoughts on: 1. What is the future availability of XO hardware? What are the alternatives? What hardware choices are deployments going to make for their next and future rounds of purchasing. 2. How effectively does Sugar run on the available hardware options? What will it take to bring Sugar up to a deployment level quality on this hardware? 3. What resources are required to make this happen? Again, this might seem hand-wavy. An shared understanding of where the project going is important for creating a sense of shared value. It also helps us as individuals chose our work so that it has the most impact on the ecosystem and the project. On Fri, Nov 8, 2013 at 6:34 PM, Walter Bender walter.ben...@gmail.com wrote: On Fri, Nov 8, 2013 at 7:19 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 8 November 2013 13:10, Walter Bender walter.ben...@gmail.com wrote: Classmate and Classmate variants are already quick wide spread in some deployments, e.g., Argentina I wonder if we should try to get some classmates in the hands of Sugar Labs community members. It seems like the most solid hardware option we have for deployments at the moment. I'll look into it. * Chromebook At least one deployment is looking at this option. Looking forward to know how this goes :) Another couple more for community evaluation (evaluation, testing, marketing) * Linux compatible ARM boards * Virtualbox SoaS is our current offering for Virtualbox (As you pointed out in a previous thread, it is a two-step process to install. In my experience, that is 1 too many for our audience. Something we may be able to address by approaching some of the VM suppliers.) We are crossing threads here but... I think it would be great to have a single installer but (without having tried it!) the current installation process doesn't seem terribly bad. I feel that documenting it better and turning it into the first thing you see when you click downloads could go a long way. - RD resources I feel balance with addressing existing deployments needs is not a question Sugar Labs can or should answer. We should encourage and support both, it's up to companies and volunteers involved to see how much of either they could or should be doing. +1 That said, the discipline you have imparted on us regarding unit tests is a step that the community can take. Maybe one of our priorities should be to dust off some basic automatic testing for activities as well. OLPC used to have such a system in place. Of course I'm all for more unit tests :) The buildbot is already trying to start and close activities on every build but it would be great if people wrote more comprehensive unit and UI tests, similarly to what we are doing in the shell. Get them to run into sugar-build/buildbot would be trivial... Maybe we can work on an example for an activity and then propagate (via GCI). We are not a company, we have no resources to allocate. But there are lots of concrete things we can do to encourage people to allocate them. I'm really glad to see that Activity Central figured out how to devote resources to RD. I hope you will be able to keep it up and more people will follow that example. We can leverage initiatives like Google Code. We can try crowd funding. We can apply for grants, as we have been doing sometimes successfully. We can keep lowering the barriers for volunteers, we have been making great progress on that. We can finally solve the un-marketability issue, attracting attention and energies and hence hopefully contributions. Google Code In starts on Nov. 18. But we can keep adding tasks over the course of the contest. Please don't be shy about suggesting tasks. And we could also use a few more mentors. I don't think I'm able to commit to be an official mentor but, as usual, I'll be answering as many questions as possible in irc/mailing lists when I am around. Sort of thinking to puth GConf - GSettings on the list... And Wayland support but that's probably too complex for GCI. GConf to GSettings is definitely GCI caliber introductory task worthy. -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
