Re: [Sugar-devel] [GSoC 2013] Interested in Implement help mechanism for activities using Mallard
On Thu, Apr 11, 2013 at 11:39 PM, Kalpa Welivitigoda callka...@gmail.comwrote: On Fri, Apr 12, 2013 at 1:53 AM, Gonzalo Odiard gonz...@laptop.orgwrote: +10 Many thanks to Bastein for focusing us all on the topic again. We need use the easier possible way to write (and translate) the docs. I don't know if there are wysiwyg tools to write the XML files for Mallard, if not, is a big step backward. There is FoieGras [1] which wa also a GSoC project from GNOME in 2008. I have mailed Buddhika [2] who was the GSoC student for that project and he is also from the same university as mine, University of Moratuwa. I'll update with the status of FoieGras once Buddhika replies. If I may summaries up to now, Although the project idea says to implement a help system using Mallard, we can extend it, write help files in plain text and convert them to desired forms (Mallard, html etc) so that we can present them in several possible ways. Should we output only in Mallard format? I don't see any advantage right now, since we have the capability to expand. Since it is plain text, I think it's better to use MarkDown as the markup language. Anyway once I hear from Buddhika, I'll drop a mail to sugar-devel asking developers for their preference in markup language to be used. [1] https://live.gnome.org/ProjectMallard/FoieGras [2] http://mytechgossips.com/2007/08/24/end-of-a-great-three-months/ Gonzalo On Thu, Apr 11, 2013 at 5:19 PM, Bastien b...@laptop.org wrote: Hi all, translation comes after the docs have been written. The main barrier is not dependancies for translation tools, it's about *writing* documentation. Hence the idea of using a plain text light markup language. Maybe we could run an informal poll about this in the Sugar community to get a sense of what current devs are comfortable with? If they are comfortable with using MarkDown, I'd favor using this. Such feedback would be interesting anyway. -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Best Regards, Kalpa Welivitigoda Junior Treasurer | Electrical Engineering Society Undergraduate | Department of Electrical Engineering University of Moratuwa Sri Lanka http://about.me/callkalpa ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel There is perhaps more documentation already written than is generally known about. For example, there are many activities with pages in the wiki [1] and efforts such as [2] done by OLPC deployments. Spanish-language versions abound as well. Coming up with a decent framework which we can populate from these sources would take us a long ways. [1] http://wiki.sugarlabs.org/go/Activities#Sugar_Activities [2] http://academy.one-education.org/mod/book/view.php?id=130 regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC 2013] Interested in Implement help mechanism for activities using Mallard
Kalpa Welivitigoda callka...@gmail.com writes: Although the project idea says to implement a help system using Mallard, we can extend it, write help files in plain text and convert them to desired forms (Mallard, html etc) so that we can present them in several possible ways. Yep, that makes sense. -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC 2013] Interested in Implement help mechanism for activities using Mallard
Walter Bender walter.ben...@gmail.com writes: Coming up with a decent framework which we can populate from these sources would take us a long ways. Indeed. I created this repo: https://github.com/bzg/aslodocs I will try to populate with docs when I find time for this. I welcome merge requests of course, if others find it useful. -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities)
On 12 April 2013 00:17, fors...@ozonline.com.au wrote: Hi When the XO was first designed it was an open choice for operating system, desktop and file manager. Some innovative choices were made to optimise the experience of new young users. Some I think were good, some bad. I think Android is the likely educational future. It is not an open choice like the XO. We do not control the OS and are unlikely to be able to control the desktop, file manager or Activity installation. I ask, what are the really important features of Sugar in this situation? Is it just the suite of Activities? Collaboration? What role do we see for Sugarlabs looking forward? IMO taken alone the Sugar features are not worth much. A suite of activities using a well designed, consistent UI paradigm, have some more value. If they all use a powerful collaboration framework, even more. Etc. I don't think Android is necessarily the future. It's really hard to make such predictions. Though, realistically, I don't see how we could get in a situation where we can control hardware and OS again in the foreseeable future. Perhaps the challenge is to figure out how to make the most important Sugar features possible in this new context. And while at it reevaluating some of the original choices. The HTML activities effort is going in that direction. I don't know if it's the best possible approach, but it's a try to address the problem you are pointing out. I wish I'd see the community * Acknowledge that we have a major issue * Analyze it and try to figure out solutions * Work on them together I'm not seeing any of those, if not in a few individuals, and that worries me. Maybe people don't care or maybe there is a lack of leadership... I don't know. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities)
I'm not seeing any of those, if not in a few individuals, and that worries me. Maybe people don't care or maybe there is a lack of leadership... I don't know. The community working in the platform it's just a few individuals right now... And the community work in a lot of different problems, local needs, continue development, bug fixing, maintaining infrastructure, then there are not too much hands (sadly) to work on this. It's really important the research you are doing, please, don't stop. Gonzalo ___ 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] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
I like the general idea. Question: This means a Chromium process should be working all time? Gonzalo On Thu, Apr 11, 2013 at 4:52 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I spent some time today thinking and experimenting with Chromium integration and I have a more detailed plan to propose now. There is an important premise to be made. In both Chromium and Firefox OS, application's installation is very much in the hands of the web browser. It happens as the result of a user clicking on a button, inside a web store. Chromium is a bit more flexible but the other possibilities are basically just developer tools. I think this limits our possibilities a lot. We need to use the browser applications management, rather then installing applications ourselves and then launching them with some command line option. Of course Chromium is open source and we could develop the stuff which is missing. But, in my opinion it's just too much work and it's going to be a pain to maintain in the future, core developers are not going to care about it, given it's not important for their products. That said, I think I mostly figured out a plan to integrate with Chromium web apps management, without having to write a lot of code. * Chromium is started up with the sugar session, using the --no-startup-window, to make it invisible. The sugar extension has a background permission, which will keep it running even with no windows. * The extension runs a python script, using chrome.runtime.connectNative. Communication uses json-rpc wrapped in the message protocol supported by the extension. The python script fetches the list of installed activities (as exposed by chrome.management.getAll) and listen to changes. * The python script exposes a dbus service, allowing the sugar shell to get the list of installed applications and to display icons for them in the home. We use GIOChannel to read stdin, so that we don't block and integrate with the glib mainloop. * When the user click on an icon, a LaunchApplication is called on the dbus service, which proxies it to the extension, which launches the application. We will probably need a trivial patch to chromium to start it without UI. There is already a define for chromeos, but it's a compile time thing (in extension_prefs.cc, GetLaunchContainer). * The shell notices that a new window has been opened and associates it with the application information. This allows to activate and close the activity as necessary. * Uninstalling an activity works in the same way as launching. Shell - python script - extension. * Implementation of collaboration and datastore libraries could also be based on the python script messaging. I implemented (badly) a good part of this and I didn't find fundamental problems with it. Except for one, which is not specific to this plan. Sugar supports multiple instances of the same activity, web application frameworks doesn't. How are we going to deal with that? I haven't thought much about it yet, but it seems something we want to be very clear about. ___ 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 future (was Re: Re: [DESIGN] Single instance activities)
On Fri, Apr 12, 2013 at 07:06:22AM -0500, David Farning wrote: It is the lack of transparency that causes people to become disillusioned and leave the project. Sounds more like there aren't enough people writing code convincingly enough for the other people writing code. (Says the peanut gallery, I know) Dave Martin pgpv5l8Dh3SUN.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC 2013] Interested in Implement help mechanism for activities using Mallard
On Fri, Apr 12, 2013 at 2:00 PM, Bastien b...@laptop.org wrote: Walter Bender walter.ben...@gmail.com writes: Coming up with a decent framework which we can populate from these sources would take us a long ways. Indeed. I created this repo: https://github.com/bzg/aslodocs I will try to populate with docs when I find time for this. I welcome merge requests of course, if others find it useful. Great ! So the idea is collect current help sources and mean time develop a decent frame as the project through which we can present the collected sources of help files and new help files. The new framework should be easy to use with the developers so that over the time the help document writing process and presenting them becomes uniform with the help of the framework. -- Bastien -- Best Regards, Kalpa Welivitigoda Junior Treasurer | Electrical Engineering Society Undergraduate | Department of Electrical Engineering University of Moratuwa Sri Lanka http://about.me/callkalpa ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
On 12 April 2013 12:48, Gonzalo Odiard gonz...@laptop.org wrote: I like the general idea. Question: This means a Chromium process should be working all time? That's the case in the implementation I described. Though I think it could be optimized to avoid that. If the shell caches the apps info either in memory or on disk, chromium can be shut down until a web activity is launched. That's a bit more complicated, but it's probably worth it until we have a lot web activities. Not sure how much memory a chromium without any window is taking though, we should check. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] GSoC: Keyboard Activities Project
Hi, I'm Anuj. I'm a 2nd year Computer Science undergrad student and I'm applyig for GSoC this year. I went through the org list and am really interested in working with Sugar Labs for the Music Keyboard activities project. Can anyone please guide me on how to get started and make progress on this? Any suggestions would be really appreciated. -- Anuj Pahuja 2nd year Undergraduate B.E.(Hons.) Computer Science ▄ *Birla Institute of Technology Science,* *Pilani* ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] GSoC 2013
Hello, I would like to participate in GSoc 2013 and I'm particulary interested in two of your projects : Display notes in a score in Music Keyboard activity and Portfolio video. I have knowledges in Python. Would it be possible to have some more details about them in order to choose one? Thank you in advance, Regards, Mathilde André ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Tuxmath on 0.96+ mystery
would be good: -create a GIT repo in git.sugarlabs.. to put the versions of the activity and improve the patch/fixes.. -update the style of bars in the activity launcher (at the begin) -upload a new version to aslo with this fixes and others fixes Hmmm, yes its what we should do but it need to explore the way of working of the activity more that Ive done. Plus, I think that the next big thing to do on Tuxmath activity is first to rebuilt it on ARM else it will never work on XO 1.75/XO 4. Lionel. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
Hi Daniel, Impressive idea with a cool architecture. BTW, to be honest I think its too complex. Why not just create a standard Python activity template that call the WebKit WebView? Like we do today. But maybe I miss something or maybe we dont speak of the same thing? When I wrote the GSoC proposal, I think to a two steps process. What I call the first step is just to create an activity template with a full screen WebView control and a Sugar to JavaScript. So its like my work on Enyo today but: - With a better way than console-message to communicate between JavaScript Sugar, - With a JavaScript/CSS framework to reproduce in HTML5 the Sugar LookFeel and sugar.graphics stuff, - With a JavaScript framework that allow calling all Sugar features (telepathy, data store, l10n, dragdrop, ). We could probably do all these things without lot of change on current Sugar implementation and current Sugar activity way of working. In my mind, this could work even on Sugar 0.96-0.98 without any change! Except if Im wrong, what youre currently describe is the second step: upgrading Sugar to support directly HTML5 activities. In this second step we could imagine that Sugar will be very different than today (may be an Android layer or a Chromium layer) and that no current Python activities will work on it. BTW HTML5 activities built with the first step framework should be very easy to adapt: just need to change the JavaScript framework implementation to use natives features instead of Sugar Python features (for example: call HTML5 storage instead of Datastore storage) and remove the XO Manifest/Package. I do like your architecture proposal for this second step but its difficult to me to think to this second step without weve got a more precise view of the first step. Lionel. De : Daniel Narvaez [mailto:dwnarv...@gmail.com] Envoyé : jeudi 11 avril 2013 21:52 À : sugar-devel@lists.sugarlabs.org Cc : Lionel Laské Objet : Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work) Hello, I spent some time today thinking and experimenting with Chromium integration and I have a more detailed plan to propose now. There is an important premise to be made. In both Chromium and Firefox OS, application's installation is very much in the hands of the web browser. It happens as the result of a user clicking on a button, inside a web store. Chromium is a bit more flexible but the other possibilities are basically just developer tools. I think this limits our possibilities a lot. We need to use the browser applications management, rather then installing applications ourselves and then launching them with some command line option. Of course Chromium is open source and we could develop the stuff which is missing. But, in my opinion it's just too much work and it's going to be a pain to maintain in the future, core developers are not going to care about it, given it's not important for their products. That said, I think I mostly figured out a plan to integrate with Chromium web apps management, without having to write a lot of code. * Chromium is started up with the sugar session, using the --no-startup-window, to make it invisible. The sugar extension has a background permission, which will keep it running even with no windows. * The extension runs a python script, using chrome.runtime.connectNative. Communication uses json-rpc wrapped in the message protocol supported by the extension. The python script fetches the list of installed activities (as exposed by chrome.management.getAll) and listen to changes. * The python script exposes a dbus service, allowing the sugar shell to get the list of installed applications and to display icons for them in the home. We use GIOChannel to read stdin, so that we don't block and integrate with the glib mainloop. * When the user click on an icon, a LaunchApplication is called on the dbus service, which proxies it to the extension, which launches the application. We will probably need a trivial patch to chromium to start it without UI. There is already a define for chromeos, but it's a compile time thing (in extension_prefs.cc, GetLaunchContainer). * The shell notices that a new window has been opened and associates it with the application information. This allows to activate and close the activity as necessary. * Uninstalling an activity works in the same way as launching. Shell - python script - extension. * Implementation of collaboration and datastore libraries could also be based on the python script messaging. I implemented (badly) a good part of this and I didn't find fundamental problems with it. Except for one, which is not specific to this plan. Sugar supports multiple instances of the same activity, web application frameworks doesn't. How are we going to deal with that? I haven't thought much about it yet, but it seems something we want to be very clear
Re: [Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities)
Daniel - thanks for that cc'ing the IAEP list, since the topic of the future of Sugar is I believe of general interest to developer and non-developer contributors alike. Porting Sugar to Android was identified at the beginning of the year by the Oversight Board as a strategic goal for Sugar Labs. There are several good reasons for this. One is that sales of the classic PC platform - a computer with a keyboard and mouse, 98% of which run a version of Microsoft Windows, and most of which are theoretically capable of running a GNU/Linux distribution - are in freefall (IDC reported last week -14% PC shipments, the single worst quarterly decline since PC industry tracking began). Another reason is that sales of handheld touch devices, the majority of which run a version of Android, are booming. These situations are of course related. The education market is a reflection of the wider market. As for emerging markets, recent estimates from IDC predict emerging market tablet sales will rise +60% in 2013, smartphones +35%, laptops +4% and desktops off -4%. The ITU currently estimates 934 million active mobile-broadband subscriptions for 2013 in developing countries; in Africa, there are 10 for every 100 inhabitants. The overwhelming majority of these are running Android (Apple iOS is marginal in emerging markets). It's not unreasonable to suppose that educational software for Android could easily be made available to 25 million children in developing countries. The initial work seems very encouraging, yet it seems Sugar Labs doesn't currently have the resources to make an Android offer available anytime soon. But: now is the time. I believe fundraising is vital to achieve this goal, at the very least to facilitate face to face Sugar Camps for the community. I have ideas how to go about this, but I agree the community needs to be clear about where we are going. An Android offer would of course be of great interest to OLPC. There are also initiatives we could take to multiply the size of the community. In particular, support for the Raspberry Pi (which has topped 1 million units in sales - half of these since September -, is shipped without an OS, and is arriving in junior high and high school computer science classes) could be an ideal OEM platform for Sugar. Sean Sugar Labs Marketing Coordinator On Fri, Apr 12, 2013 at 10:58 AM, Daniel Narvaez dwnarv...@gmail.comwrote: On 12 April 2013 00:17, fors...@ozonline.com.au wrote: Hi When the XO was first designed it was an open choice for operating system, desktop and file manager. Some innovative choices were made to optimise the experience of new young users. Some I think were good, some bad. I think Android is the likely educational future. It is not an open choice like the XO. We do not control the OS and are unlikely to be able to control the desktop, file manager or Activity installation. I ask, what are the really important features of Sugar in this situation? Is it just the suite of Activities? Collaboration? What role do we see for Sugarlabs looking forward? IMO taken alone the Sugar features are not worth much. A suite of activities using a well designed, consistent UI paradigm, have some more value. If they all use a powerful collaboration framework, even more. Etc. I don't think Android is necessarily the future. It's really hard to make such predictions. Though, realistically, I don't see how we could get in a situation where we can control hardware and OS again in the foreseeable future. Perhaps the challenge is to figure out how to make the most important Sugar features possible in this new context. And while at it reevaluating some of the original choices. The HTML activities effort is going in that direction. I don't know if it's the best possible approach, but it's a try to address the problem you are pointing out. I wish I'd see the community * Acknowledge that we have a major issue * Analyze it and try to figure out solutions * Work on them together I'm not seeing any of those, if not in a few individuals, and that worries me. Maybe people don't care or maybe there is a lack of leadership... I don't know. ___ 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] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
Hi Lionel, we are more or less understanding each other :) I think there are really three possible steps 1 A WebView with an html5/javascript based sugar-toolkit 2 Support for web activities along with native ones, inside a native shell 3 Fully html5 sugar My feeling is that we should target step 2 directly, because 1 - 2 will waste too much work. The datastore and collaboration implementation is going to be pretty different, depending if we use Chromium or Webkit embedding. Consider also that a better way to communicate then console-message is not going to come for free. I also think doing 2 directly doesn't add much bootstrapping work. It's going to be a *lot* more complicated to implement the html UI stuff than to implement the bits of bridging I described. The only real advantage I see with doing step 1 first is that it would give us more time to migrate Browse to the same backend. Admittedly having to ship both Chromium and Webkit would be pretty bad. I don't want to be stuck in our own html based framework. I explained in my first email why I think we should jump on one of the existing webapp frameworks train. Anyway I'm satisfied that we know what are the alternatives now. And we have a pretty decent idea of what they involve. I think when Simon is back we should meet and decide which direction to take. It also somewhat depends on who is interested to help out with this and what they would like to work on. In the meantime people can start hacking on the UI stuff :) On 12 April 2013 22:36, lio...@olpc-france.org wrote: ** ** Hi Daniel, ** ** Impressive idea with a cool architecture. BTW, to be honest I think it’s… too complex. Why not just create a standard Python activity template that call the WebKit WebView? Like we do today. ** ** But maybe I miss something or maybe we don’t speak of the same thing? When I wrote the GSoC proposal, I think to a two steps process. ** ** What I call the “first step” is just to create an activity template with a full screen WebView control and a Sugar to JavaScript. So it’s like my work on Enyo today but: **- **With a better way than “console-message” to communicate between JavaScript Sugar, **- **With a JavaScript/CSS framework to reproduce in HTML5 the Sugar LookFeel and sugar.graphics stuff, **- **With a JavaScript framework that allow calling all Sugar features (telepathy, data store, l10n, dragdrop, …). We could probably do all these things without lot of change on current Sugar implementation and current Sugar activity way of working. In my mind, this could work even on Sugar 0.96-0.98 without any change! ** ** Except if I’m wrong, what you’re currently describe is the “second step”: upgrading Sugar to support directly HTML5 activities. In this second step we could imagine that Sugar will be very different than today (may be an Android layer or a Chromium layer) and that no current Python activities will work on it. BTW HTML5 activities built with the “first step framework” should be very easy to adapt: just need to change the JavaScript framework implementation to use natives features instead of Sugar Python features (for example: call HTML5 storage instead of Datastore storage) and remove the XO Manifest/Package. I do like your architecture proposal for this second step but it’s difficult to me to think to this second step without we’ve got a more precise view of the first step. ** ** Lionel. ** ** ** ** ** ** *De :* Daniel Narvaez [mailto:dwnarv...@gmail.com] *Envoyé :* jeudi 11 avril 2013 21:52 *À :* sugar-devel@lists.sugarlabs.org *Cc :* Lionel Laské *Objet :* Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work) ** ** Hello, I spent some time today thinking and experimenting with Chromium integration and I have a more detailed plan to propose now. There is an important premise to be made. In both Chromium and Firefox OS, application's installation is very much in the hands of the web browser. It happens as the result of a user clicking on a button, inside a web store. Chromium is a bit more flexible but the other possibilities are basically just developer tools. I think this limits our possibilities a lot. We need to use the browser applications management, rather then installing applications ourselves and then launching them with some command line option. Of course Chromium is open source and we could develop the stuff which is missing. But, in my opinion it's just too much work and it's going to be a pain to maintain in the future, core developers are not going to care about it, given it's not important for their products. That said, I think I mostly figured out a plan to integrate with Chromium web apps management, without having to write a lot of code. * Chromium is started up with the sugar session, using the
[Sugar-devel] [RELEASE] sugar-0.98.7
This is Sugar bugfixing release 0.98.7. Thanks a lot to Daniel Narvaez, Martin Abente and Gonzalo Odiard for reviewing and testing. == Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.98.7.tar.bz2 == News == * Release 0.98.7 (Manuel Quiñones) * Update Sucrose version for 0.98.7 (Manuel Quiñones) * More frame drag and drop fixes - SL #3819 (Manuel Quiñones) * Journal: fix the API for drag and drop - SL #3999 (Manuel Quiñones) * Bring back dragging of elements from the clipboard to the activities - SL #4485 (Manuel Quiñones) * Bring back dragging of elements from the activities to the frame clipboard - SL #3819 (Manuel Quiñones) * Commit from Sugar Labs: Translation System by user cjl.: 390 of 390 messages translated (0 fuzzy). (Pootle daemon) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [support-gang] Fwd: Re: Sugar future (was Re: Re: [DESIGN] Single instance activities)
Hi Folks... Notes from Sunny SoCal... Another reason to Androidize Sugar... whenever someone asks me (as recently as last evening) about the XO Learning Tablet, they assume Sugar will run on it. I have to tell them, no, it's an Android platform, but we hope to get Sugar running on Android devices soon (as per the Sugar Labs goals from the start of the year). They are all pleased with that idea. What is good/important about Sugar? Ability to collaborate. Integration of Activities so several can be combined creatively in PBL (Project Based Learning). The Activities I think are particularly good examples of this are Labyrinth and FotoToon where students can bring together all sorts of resources to create a wonderful project about any topic and level needed. They are great for history, language arts, science, etc. Some of us saw several excellent examples of Labyrinth used in this fashion when we visited schools in Uruguay. Another Activity that fits in the same useful category as Labyrinth and FotoToon is Memorize. For that, adding a simple users guide would make it possible for anyone, children, teachers, or parents to create memorize games on any topic they liked. To go with these, students need Activities to create the content they will need... for example, Record, Paint, Write, and Wikis where they can look up the content they can't get on their own. Would it be possible to, instead of trying to port all of Sugar to Android, start with a few key Activities? If someone who is a whiz at this sort of thing could write something similar to James Simmons, Make Your Own Sugar Activities, about how to convert a Sugar Activity to run on Android, then other programmers could get involved in working on them... both individually and in groups. I'll bet we could interest LUG (Linux Users Groups) members from all over the country and maybe the world to take on projects as a club endeavor where they would Adopt an Activity and Adapt it to Andorid. Call it the 4A Project or the A/AA4A (Adopting/Adapting Activities For Android). I personally have contacts with 2 such groups I think would enjoy participating. Just some thoughts... FWIW Caryl Date: Fri, 12 Apr 2013 16:56:05 -0400 From: h...@laptop.org To: support-g...@laptop.org Subject: [support-gang] Fwd: Re: [Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities) Stark choice facing us? All worth considering- Subject: Re: [Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities) Date: Fri, 12 Apr 2013 22:52:39 +0200 From: Sean DALY sdaly...@gmail.com To: Daniel Narvaez dwnarv...@gmail.com CC: iaep i...@lists.sugarlabs.org, Tony Forster fors...@ozonline.com.au, sugar-devel@lists.sugarlabs.org sugar-devel@lists.sugarlabs.org, Manuel Qui�ones ma...@laptop.org Daniel - thanks for that cc'ing the IAEP list, since the topic of the future of Sugar is I believe of general interest to developer and non-developer contributors alike. Porting Sugar to Android was identified at the beginning of the year by the Oversight Board as a strategic goal for Sugar Labs. There are several good reasons for this. One is that sales of the classic PC platform - a computer with a keyboard and mouse, 98% of which run a version of Microsoft Windows, and most of which are theoretically capable of running a GNU/Linux distribution - are in freefall (IDC reported last week -14% PC shipments, the single worst quarterly decline since PC industry tracking began). Another reason is that sales of handheld touch devices, the majority of which run a version of Android, are booming. These situations are of course related. The education market is a reflection of the wider market. As for emerging markets, recent estimates from IDC predict emerging market tablet sales will rise +60% in 2013, smartphones +35%, laptops +4% and desktops off -4%. The ITU currently estimates 934 million active mobile-broadband subscriptions for 2013 in developing countries; in Africa, there are 10 for every 100 inhabitants. The overwhelming majority of these are running Android (Apple iOS is marginal in emerging markets). It's not unreasonable to suppose that educational software for Android could easily be made available to 25 million children in developing countries.
Re: [Sugar-devel] [support-gang] Fwd: Re: Sugar future (was Re: Re: [DESIGN] Single instance activities)
On 12 April 2013 23:40, Caryl Bigenho cbige...@hotmail.com wrote: Would it be possible to, instead of trying to port all of Sugar to Android, start with a few key Activities? I think that's the idea. Porting the whole Sugar to Android would involve porting a lot of system components and then likely having to maintain the ports. Too big and difficult of a task for our community, in my opinion. If someone who is a whiz at this sort of thing could write something similar to James Simmons, Make Your Own Sugar Activities, about how to convert a Sugar Activity to run on Android, then other programmers could get involved in working on them... both individually and in groups. Unfortunately porting an activity to Android means rewriting it from scratch. Depending on the activity there might be pieces of code which are general enough to require just a python - javascript translation. Btw the idea is to port to html5 and javascript, not to the Android native API. The advantage is to be able to run the same code on other OSes but of course integration with the Android platform might suffer. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release FotoToon-14
Activity Homepage: http://activities.sugarlabs.org/addon/4253 Sugar Platform: 0.98 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28542/fototoon-14.xo Release notes: Code cleanup, many fixes, Save the story as a PDF (Agustin Zubiaga) Using textview for edit texts (with Agustin Zubiaga) Add slideview mode (Agustin Zubiaga) Port to Gtk3 (with Ignacio Rodriguez) 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] Sugar future (was Re: Re: [DESIGN] Single instance activities)
On 12 April 2013 22:52, Sean DALY sdaly...@gmail.com wrote: The initial work seems very encouraging, yet it seems Sugar Labs doesn't currently have the resources to make an Android offer available anytime soon. But: now is the time. I believe fundraising is vital to achieve this goal, at the very least to facilitate face to face Sugar Camps for the community. I have ideas how to go about this, but I agree the community needs to be clear about where we are going. An Android offer would of course be of great interest to OLPC. To be completely honest, I think a migration to HTML/Android is never going to happen unless someone invests in it *and* the community rallies around that effort. Even a small team of experienced, full time developers could lay the framework foundations. And then writing enough activities for the framework to be of any interest would take a *lot* of work from the community. But are there the conditions for that to happen? There are also initiatives we could take to multiply the size of the community. In particular, support for the Raspberry Pi (which has topped 1 million units in sales - half of these since September -, is shipped without an OS, and is arriving in junior high and high school computer science classes) could be an ideal OEM platform for Sugar. I also see Raspberry PI as a tempting opportunity. Though I think there is some conflict between trying to extend the reach of the current platform and bootstrapping a new one. I think it's important for people to understand that porting to Android is not really porting but a full rewrite. We can reuse designs, artwork, ideas and some of the experience we made so far, but no code at all. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar future (was Re: Re: [DESIGN] Single instance activities)
Hi Daniel, et. al., Do you think Ubuntu could be an (easier) option for sugar to piggyback upon... This is not a because-i-think-ubuntu-is-cool opinion, but testament to the fact that canonical have been working to get ubuntu running on tablets and smartphones. https://wiki.ubuntu.com/Nexus7/Installation Even I'm not sold on the idea, but I guess it should be part a discussion and research efforts concerning sugar's future. Best, Anish On Fri, Apr 12, 2013 at 6:09 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 12 April 2013 22:52, Sean DALY sdaly...@gmail.com wrote: The initial work seems very encouraging, yet it seems Sugar Labs doesn't currently have the resources to make an Android offer available anytime soon. But: now is the time. I believe fundraising is vital to achieve this goal, at the very least to facilitate face to face Sugar Camps for the community. I have ideas how to go about this, but I agree the community needs to be clear about where we are going. An Android offer would of course be of great interest to OLPC. To be completely honest, I think a migration to HTML/Android is never going to happen unless someone invests in it *and* the community rallies around that effort. Even a small team of experienced, full time developers could lay the framework foundations. And then writing enough activities for the framework to be of any interest would take a *lot* of work from the community. But are there the conditions for that to happen? There are also initiatives we could take to multiply the size of the community. In particular, support for the Raspberry Pi (which has topped 1 million units in sales - half of these since September -, is shipped without an OS, and is arriving in junior high and high school computer science classes) could be an ideal OEM platform for Sugar. I also see Raspberry PI as a tempting opportunity. Though I think there is some conflict between trying to extend the reach of the current platform and bootstrapping a new one. I think it's important for people to understand that porting to Android is not really porting but a full rewrite. We can reuse designs, artwork, ideas and some of the experience we made so far, but no code at all. ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Anish | an...@sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar future (was Re: Re: [DESIGN] Single instance activities)
O.K. So... now it is time to divide and conquer! That is... divide the work up into doable little projects and conquer the huge task of getting Sugar Activities onto Android and possibly other platforms. Someone (at Sugar Labs, logically) just needs to be in charge and coordinate the efforts to minimize duplication and maximize efficiency. The rest of us? We are the cheerleaders, recruiters, evangelizers who need to look into every little nook and cranny to find enthusiastic groups and individuals to take on the work. As I've said before, my programming stopped years ago with Pascal so I can't be of much use as a developer, but I can recruit others who can help. 2013 is moving along. This project needs to move along too! Caryl Date: Sat, 13 Apr 2013 00:09:55 +0200 From: dwnarv...@gmail.com To: sdaly...@gmail.com CC: i...@lists.sugarlabs.org; fors...@ozonline.com.au; sugar-devel@lists.sugarlabs.org; ma...@laptop.org Subject: Re: [IAEP] [Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities) On 12 April 2013 22:52, Sean DALY sdaly...@gmail.com wrote: The initial work seems very encouraging, yet it seems Sugar Labs doesn't currently have the resources to make an Android offer available anytime soon. But: now is the time. I believe fundraising is vital to achieve this goal, at the very least to facilitate face to face Sugar Camps for the community. I have ideas how to go about this, but I agree the community needs to be clear about where we are going. An Android offer would of course be of great interest to OLPC. To be completely honest, I think a migration to HTML/Android is never going to happen unless someone invests in it *and* the community rallies around that effort. Even a small team of experienced, full time developers could lay the framework foundations. And then writing enough activities for the framework to be of any interest would take a *lot* of work from the community. But are there the conditions for that to happen? There are also initiatives we could take to multiply the size of the community. In particular, support for the Raspberry Pi (which has topped 1 million units in sales - half of these since September -, is shipped without an OS, and is arriving in junior high and high school computer science classes) could be an ideal OEM platform for Sugar. I also see Raspberry PI as a tempting opportunity. Though I think there is some conflict between trying to extend the reach of the current platform and bootstrapping a new one. I think it's important for people to understand that porting to Android is not really porting but a full rewrite. We can reuse designs, artwork, ideas and some of the experience we made so far, but no code at all. ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar future (was Re: Re: [DESIGN] Single instance activities)
O.K. So... now it is time to divide and conquer! That is... divide the work up into doable little projects and conquer the huge task of getting Sugar Activities onto Android and possibly other platforms. Someone (at Sugar Labs, logically) just needs to be in charge and coordinate the efforts to minimize duplication and maximize efficiency. The rest of us? We are the cheerleaders, recruiters, evangelizers who need to look into every little nook and cranny to find enthusiastic groups and individuals to take on the work. As I've said before, my programming stopped years ago with Pascal so I can't be of much use as a developer, but I (and others) can recruit people who can help. 2013 is moving along. This project needs to move along too! Caryl Date: Sat, 13 Apr 2013 00:09:55 +0200 From: dwnarv...@gmail.com To: sdaly...@gmail.com CC: i...@lists.sugarlabs.org; fors...@ozonline.com.au; sugar-devel@lists.sugarlabs.org; ma...@laptop.org Subject: Re: [IAEP] [Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities) On 12 April 2013 22:52, Sean DALY sdaly...@gmail.com wrote: The initial work seems very encouraging, yet it seems Sugar Labs doesn't currently have the resources to make an Android offer available anytime soon. But: now is the time. I believe fundraising is vital to achieve this goal, at the very least to facilitate face to face Sugar Camps for the community. I have ideas how to go about this, but I agree the community needs to be clear about where we are going. An Android offer would of course be of great interest to OLPC. To be completely honest, I think a migration to HTML/Android is never going to happen unless someone invests in it *and* the community rallies around that effort. Even a small team of experienced, full time developers could lay the framework foundations. And then writing enough activities for the framework to be of any interest would take a *lot* of work from the community. But are there the conditions for that to happen? There are also initiatives we could take to multiply the size of the community. In particular, support for the Raspberry Pi (which has topped 1 million units in sales - half of these since September -, is shipped without an OS, and is arriving in junior high and high school computer science classes) could be an ideal OEM platform for Sugar. I also see Raspberry PI as a tempting opportunity. Though I think there is some conflict between trying to extend the reach of the current platform and bootstrapping a new one. I think it's important for people to understand that porting to Android is not really porting but a full rewrite. We can reuse designs, artwork, ideas and some of the experience we made so far, but no code at all. ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar future
On 12.04.2013, at 15:39, Caryl Bigenho cbige...@hotmail.com wrote: O.K. So... now it is time to divide and conquer! Is it? That is... divide the work up into doable little projects and conquer the huge task of getting Sugar Activities onto Android and possibly other platforms. IMHO the individual activities are *not* what makes Sugar such a compelling proposition. Sure, having some of them as apps on other platforms would be nice. But isn't collaborating and sharing at the heart of Sugar? The Journal as central UI? The effortless discovery of your peers in the neighborhood view? Etc? *That* experience would have to be ported to another platform first, and then the activities can follow. Otherwise, it's just a bunch of random apps, of which there are plenty already in the various app stores. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC 2013
Hi, I have created a page with pointers to the MusicKeyboard tasks. http://wiki.sugarlabs.org/go/Activities/MusicKeyboard Gonzalo On Fri, Apr 12, 2013 at 1:46 PM, Mathilde André mathilde.and...@orange.frwrote: Hello, I would like to participate in GSoc 2013 and I'm particulary interested in two of your projects : Display notes in a score in Music Keyboard activity and Portfolio video. I have knowledges in Python. Would it be possible to have some more details about them in order to choose one? Thank you in advance, Regards, Mathilde André ___ 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] GSoC: Keyboard Activities Project
Hi Anuj, I wrote a page with information about how start: http://wiki.sugarlabs.org/go/Activities/MusicKeyboard Gonzalo On Fri, Apr 12, 2013 at 12:22 PM, Anuj Pahuja apnoob...@gmail.com wrote: Hi, I'm Anuj. I'm a 2nd year Computer Science undergrad student and I'm applyig for GSoC this year. I went through the org list and am really interested in working with Sugar Labs for the Music Keyboard activities project. Can anyone please guide me on how to get started and make progress on this? Any suggestions would be really appreciated. -- Anuj Pahuja 2nd year Undergraduate B.E.(Hons.) Computer Science ▄ *Birla Institute of Technology Science,* *Pilani* ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar future (was Re: Re: [DESIGN] Single instance activities)
Hi Anish, that's interesting. First impressions from a quick look. There isn't really much documentation so I won't promise this is fully accurate :) Ubuntu is running in a chroot on the top of a modified android kernel. That's a bit of an hack and I wouldn't recommend it if we had to maintain the thing. Though having a company, and another community, deal with the mess makes it more viable. They don't have X11 but apparently they ported gtk3 to mir. So at least gtk activities should be fine. It's not possible to run Android applications along linux ones but an OLPC like dual desktop thing might be possible in the future. I think this should be investigated. It might be possible to run Sugar on it without major modifications. On 13 April 2013 00:28, Anish Mangal an...@sugarlabs.org wrote: Hi Daniel, et. al., Do you think Ubuntu could be an (easier) option for sugar to piggyback upon... This is not a because-i-think-ubuntu-is-cool opinion, but testament to the fact that canonical have been working to get ubuntu running on tablets and smartphones. https://wiki.ubuntu.com/Nexus7/Installation Even I'm not sold on the idea, but I guess it should be part a discussion and research efforts concerning sugar's future. Best, Anish On Fri, Apr 12, 2013 at 6:09 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On 12 April 2013 22:52, Sean DALY sdaly...@gmail.com wrote: The initial work seems very encouraging, yet it seems Sugar Labs doesn't currently have the resources to make an Android offer available anytime soon. But: now is the time. I believe fundraising is vital to achieve this goal, at the very least to facilitate face to face Sugar Camps for the community. I have ideas how to go about this, but I agree the community needs to be clear about where we are going. An Android offer would of course be of great interest to OLPC. To be completely honest, I think a migration to HTML/Android is never going to happen unless someone invests in it *and* the community rallies around that effort. Even a small team of experienced, full time developers could lay the framework foundations. And then writing enough activities for the framework to be of any interest would take a *lot* of work from the community. But are there the conditions for that to happen? There are also initiatives we could take to multiply the size of the community. In particular, support for the Raspberry Pi (which has topped 1 million units in sales - half of these since September -, is shipped without an OS, and is arriving in junior high and high school computer science classes) could be an ideal OEM platform for Sugar. I also see Raspberry PI as a tempting opportunity. Though I think there is some conflict between trying to extend the reach of the current platform and bootstrapping a new one. I think it's important for people to understand that porting to Android is not really porting but a full rewrite. We can reuse designs, artwork, ideas and some of the experience we made so far, but no code at all. ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Anish | an...@sugarlabs.org -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar future
Bert Freudenberg b...@freudenbergs.de writes: That is... divide the work up into doable little projects and conquer the huge task of getting Sugar Activities onto Android and possibly other platforms. IMHO the individual activities are *not* what makes Sugar such a compelling proposition. Sure, having some of them as apps on other platforms would be nice. But isn't collaborating and sharing at the heart of Sugar? The Journal as central UI? The effortless discovery of your peers in the neighborhood view? Etc? *That* experience would have to be ported to another platform first, and then the activities can follow. Otherwise, it's just a bunch of random apps, of which there are plenty already in the various app stores. Bit +1. Android seems a distraction so far. Let's built on what Sugar differs: great UI ideas. -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar future (was Re: Re: [DESIGN] Single instance activities)
Hi Sean, I've not closely followed all these discussions, so obviously I'm not in the best position to provide good arguments, but here is my gut feeling about this. I see three challenges: put Sugar in the hands of many kids, build a healthy FLOSS community, raise funds. The latter is just a means to other ends, so let's only consider the first two ones. I strongly believe Sugar should focus on building a great FLOSS community first, before trying to reach as many kids as possible. This is not to say that getting more users is orthogonal to better working as a community---it isn't. But the way you get the users is by being a great community with a distinct product, not by landing on the hardware people have. I may sound idealistic (if not romantic) about this, but I strongly believe it. I know (and I read) everyone's effort about this, and I've seen some great step in this direction. Let's build on this! Sugar can be the greatest FLOSS community in education. The day it is recognized as such, people will come and contribute with new activities, just like Gcompris joined. Maybe you know the AbulÉdu* suite (http://www.abuledu.org/) ... there are many FLOSS educational resources there. But I can't get them switching to Sugar because... they use Ubuntu and want apt-get install sugar which is only half working. That's sad. Also think of this in terms of marketing: it's easier to market the greatest FLOSS community for education, than to market a software suite on Android. In this later case, we are just marketing Android. I'm done with the rant. And of course, I would not feel so strongly about this if I was not aware about everyone's effort about Sugar. Thanks! -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar future (was Re: Re: [DESIGN] Single instance activities)
On 13 April 2013 01:36, Daniel Narvaez dwnarv...@gmail.com wrote: Hi Anish, that's interesting. First impressions from a quick look. There isn't really much documentation so I won't promise this is fully accurate :) Ubuntu is running in a chroot on the top of a modified android kernel. That's a bit of an hack and I wouldn't recommend it if we had to maintain the thing. Though having a company, and another community, deal with the mess makes it more viable. They don't have X11 but apparently they ported gtk3 to mir. So at least gtk activities should be fine. It's not possible to run Android applications along linux ones but an OLPC like dual desktop thing might be possible in the future. Bah, it looks like gtk3 support is planned for 13.09 but not there yet. https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged So nothing to see for at least a few months. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
On 12 April 2013 23:18, Daniel Narvaez dwnarv...@gmail.com wrote: Hi Lionel, we are more or less understanding each other :) I think there are really three possible steps 1 A WebView with an html5/javascript based sugar-toolkit 2 Support for web activities along with native ones, inside a native shell I might not have yet made explicit what a web application provides on the top of an html page loaded in a browser, which is what we get with 1. Taking a look to the Chromium documentation is a good way to get an idea of it. http://developer.chrome.com/trunk/apps/api_index.html I'd expect those API to keep growing. The permission system is particularly important because it allows to do stuff which would be a security risk if done by a normal html page. (Hopefully they will some day converge between browsers!). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar future (was Re: Re: [DESIGN] Single instance activities)
+1 (in spirit to fixing challenges with Sugar as a FLOSS community) On Fri, Apr 12, 2013 at 8:04 PM, Bastien b...@laptop.org wrote: Hi Sean, I've not closely followed all these discussions, so obviously I'm not in the best position to provide good arguments, but here is my gut feeling about this. I see three challenges: put Sugar in the hands of many kids, build a healthy FLOSS community, raise funds. The latter is just a means to other ends, so let's only consider the first two ones. I strongly believe Sugar should focus on building a great FLOSS community first, before trying to reach as many kids as possible. This is not to say that getting more users is orthogonal to better working as a community---it isn't. But the way you get the users is by being a great community with a distinct product, not by landing on the hardware people have. I may sound idealistic (if not romantic) about this, but I strongly believe it. I know (and I read) everyone's effort about this, and I've seen some great step in this direction. Let's build on this! Sugar can be the greatest FLOSS community in education. The day it is recognized as such, people will come and contribute with new activities, just like Gcompris joined. Maybe you know the AbulÉdu* suite (http://www.abuledu.org/) ... there are many FLOSS educational resources there. But I can't get them switching to Sugar because... they use Ubuntu and want apt-get install sugar which is only half working. That's sad. Also think of this in terms of marketing: it's easier to market the greatest FLOSS community for education, than to market a software suite on Android. In this later case, we are just marketing Android. I'm done with the rant. And of course, I would not feel so strongly about this if I was not aware about everyone's effort about Sugar. Thanks! -- Bastien ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Anish | an...@sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [GSoC] Mentor association
Hi I want to contribute to sugar as a mentor, I could do some co-mentorship or something similar. My Google-Melange linkdID is jza Anyone needing a backup, can drop me an email, and give me some pointers to get on board with the project at hand. -- Alexandro Colorado Apache OpenOffice Contributor http://es.openoffice.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] Mentor association
Oh btw I am JZA on #sugar if you want to chat about the project and need more interactivity. On 4/12/13, Alexandro Colorado j...@oooes.org wrote: Hi I want to contribute to sugar as a mentor, I could do some co-mentorship or something similar. My Google-Melange linkdID is jza Anyone needing a backup, can drop me an email, and give me some pointers to get on board with the project at hand. -- Alexandro Colorado Apache OpenOffice Contributor http://es.openoffice.org -- Alexandro Colorado Apache OpenOffice Contributor http://es.openoffice.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar future
Thanks to everybody who has contributed to the discussion so far, particularly to Sean for his well researched post on Android developments. The choices as I understand: 0) Do not have an Android transition plan 1) A suite of Activities with a common look and feel but leave things like file management to Android 2) A suite of Activities which share a common Journal and Neighbourhood 3) Sugar on Ubuntu on Android (or similar) What prompted me to hijack a thread on multiple instances in html5 is that the discussion is continuing on a technical level: html5, webapps, Chrome but is relatively inaccessable to people like me with minimal coding skills. What would the user experience be like under these options? Take the minimalist option, a suite of stand alone activities using the Android desktop. Previously a Sugar Activity (1)Runs on Sugar (2)Is open source (3)Preferably but not necessarily conforms to the Sugar look and feel. Would the Sugar name be licenced to any educational app that conforms to (2)? Would you download it from the Google Store or ASLO? Should Sugar Activities conform to the existing Android look and feel: a long press for copy and paste, a menu button, power+home = screenshot? Take the more comprehensive solution incorporating the Journal. Would the Journal run and install as a stand alone app? Would the Journal be built into every Activity? Would the Journal be included with every installer file and install as a separate app the first time you install a Sugar Activity? Would the Journal communicate with the Android file system the same way it does now with Gnome through 'Documents'? What about things like inserting images from file, would the journal object selector also give an Android file selector option? The issue of the considerable resources required to transition to Android has been raised. Is there any possibility of getting financial support from Google or Samsung etc for the project? I would like to see all these questions discussed further. I would like the technical implementation discussions to be more contextualised in terms of user experience. Thanks again for all the contributions to this discussion. Tony PS. I wrote some html5 code but was disappointed that my Samsung Galaxy S3 browser does not support html5 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar future
On Fri, Apr 12, 2013 at 03:48:00PM -0700, Bert Freudenberg wrote: [...] the individual activities are *not* what makes Sugar such a compelling proposition. Sure, having some of them as apps on other platforms would be nice. But isn't collaborating and sharing at the heart of Sugar? The Journal as central UI? The effortless discovery of your peers in the neighborhood view? Etc? *That* experience would have to be ported to another platform first, and then the activities can follow. Otherwise, it's just a bunch of random apps, of which there are plenty already in the various app stores. This. Bert has nailed the fact that Sugar is more than the sum of its parts, because the parts are coherent. We can still port individual activities. But having the sugar shell running on android is a major step up in what a collection of coherently-designed activities provide. Noone's doing that work, AFAIK. I bet someone (cscott?) has already investigated its feasibility, though... - Bert - Martin pgpfYk6fgBllG.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar future
On Sat, Apr 13, 2013 at 11:21:26AM +1000, fors...@ozonline.com.au wrote: Thanks to everybody who has contributed to the discussion so far, particularly to Sean for his well researched post on Android developments. The choices as I understand: 0) Do not have an Android transition plan I read the SLOBS minutes of 2013-01-14 [1] as not agreeing to a transition plan but a compatibility plan. This is a huge distinction. If I have misunderstood, it'd be interesting to know where the transition or similar language is minuted. The minutes indicate that no detailed plan has been agreed; there is no information about what technically is planned, just what technical directions are possible[2] Tony Martin 1. http://meeting.sugarlabs.org/sugar-meeting/meetings/2013-01-14 2. http://www.google-melange.com/gci/work/download/google/gci2012/7972209?id=17001 pgp_pDSh3j7eG.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
I'm pretty new to the mailing list and the project, but I'm pretty sure that starting a new Chrome instance for every launched activity is far too taxing for the XOs. I think that Lionel's idea of using a Python activity that uses the WebKit WebView is a much, much better solution. lio...@olpc-france.org April 12, 2013 4:36 PM Hi Daniel,Impressive idea with a cool architecture. BTW, to be honest I think its too complex.Why not just create a standard Python activity template that call the WebKit WebView? Like we do today.But maybe I miss something or maybe we dont speak of the same thing?When I wrote the GSoC proposal, I think to a two steps process.What I call the first step is just to create an activity template with a full screen WebView control and a Sugar to _javascript_.So its like my work on Enyo today but:- With a better way than console-message to communicate between _javascript_ Sugar,- With a _javascript_/CSS framework to reproduce in HTML5 the Sugar LookFeel and sugar.graphics stuff,- With a _javascript_ framework that allow calling all Sugar features (telepathy, data store, l10n, dragdrop, ).We could probably do all these things without lot of change on current Sugar implementation and current Sugar activity way of working. In my mind, this could work even on Sugar 0.96-0.98 without any change!Except if Im wrong, what youre currently describe is the second step: upgrading Sugar to support directly HTML5 activities.In this second step we could imagine that Sugar will be very different than today (may be an Android layer or a Chromium layer) and that no current Python activities will work on it. BTW HTML5 activities built with the first step framework should be very easy to adapt: just need to change the _javascript_ framework implementation to use natives features instead of Sugar Python features (for example: call HTML5 storage instead of Datastore storage) and remove the XO Manifest/Package. I do like your architecture proposal for this second step but its difficult to me to think to this second step without weve got a more precise view of the first step. Lionel.De: Daniel Narvaez [mailto:dwnarv...@gmail.com] Envoy: jeudi 11 avril 2013 21:52: sugar-devel@lists.sugarlabs.orgCc: Lionel LaskObjet: Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)Hello,I spent some time today thinking and experimenting with Chromium integration and I have a more detailed plan to propose now.There is an important premise to be made. In both Chromium and Firefox OS, application's installation is very much in the hands of the web browser. It happens as the result of a user clicking on a button, inside a web store. Chromium is a bit more flexible but the other possibilities are basically just developer tools.I think this limits our possibilities a lot. We need to use the browser applications management, rather then installing applications ourselves and then launching them with some command line option. Of course Chromium is open source and we could develop the stuff which is missing. But, in my opinion it's just too much work and it's going to be a pain to maintain in the future, core developers are not going to care about it, given it's not important for their products.That said, I think I mostly figured out a plan to integrate with Chromium web apps management, without having to write a lot of code.* Chromium is started up with the sugar session, using the --no-startup-window, to make it invisible. The sugar extension has a "background" permission, which will keep it running even with no windows.* The extension runs a python script, using chrome.runtime.connectNative. Communication uses json-rpc wrapped in the message protocol supported by the extension. The python script fetches the list of installed activities (as exposed by chrome.management.getAll) and listen to changes.* The python script exposes a dbus service, allowing the sugar shell to get the list of installed applications and to display icons for them in the home. We use GIOChannel to read stdin, so that we don't block and integrate with the glib mainloop.* When the user click on an icon, a LaunchApplication is called on the dbus service, which proxies it to the extension, which launches the application. We will probably need a trivial patch to chromium to start it without UI. There is already a define for chromeos, but it's a compile time thing (in extension_prefs.cc, GetLaunchContainer).* The shell notices that a new window has been opened and associates it with the application information. This allows to activate and close the activity as necessary.* Uninstalling an activity works in the same way as launching. Shell - python script - extension.* Implementation of collaboration and datastore libraries could also be based on the python script messaging.I implemented (badly) a good part of this and I didn't find fundamental
