[IAEP] Tech roadmap
Hello, I think Sugar Labs needs to express a clear, realistic technology roadmap. For example, we have been talking a lot about Sugar on Android, mixing a lot of different things under that name. We need to clarify what that really is. Here are my thoughts, inspired by the oversight board meeting thread. * Wait and see what happens with the XO. Support existing deployments by producing images with the most recent Sugar release. Stick to a Fedora 18 base system, the work to upgrade is highly non trivial. Provide custom rpms for the sugar modules and a few dependencies, most importantly Webkit, which is required by web activities. * Ensure web activities run well in web browsers. This will cover Android and other non-Linux systems. * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one or two ARM boards (Beagle board black and Cubox-i seems to be the best we could pick at the moment). Talk to the manufacturers to get publicity on the images we produce and devices for the developers. * Work with deployments to see if there are complete hardware solutions (Chromebooks for example) they could use. In the case of locked devices they might have the where-with-all to load custom software. * Migrate from X to Wayland or support it in parallel (depending on the performance of non accellerated Wayland). GNOME is doing most of the work, but we will need the rework the window management bits. This will allow us to run on Android drivers with libhybris, which should help with hardware support. As you might have noticed there is no Sugar on Android, other than for drivers support and web activities running in a web browser. I don't think going beyhond those gives us any real advantage. Just my $0.02 -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
On Wed, Nov 6, 2013 at 11:49 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I think Sugar Labs needs to express a clear, realistic technology roadmap. For example, we have been talking a lot about Sugar on Android, mixing a lot of different things under that name. We need to clarify what that really is. Here are my thoughts, inspired by the oversight board meeting thread. * Wait and see what happens with the XO. Support existing deployments by producing images with the most recent Sugar release. Stick to a Fedora 18 base system, the work to upgrade is highly non trivial. Provide custom rpms for the sugar modules and a few dependencies, most importantly Webkit, which is required by web activities. In the short term, we don't need backport Webkit2 to F18. In the long term, we need find a solution to move to a newer Fedora in the XOs, maybe 20 or 21. * Ensure web activities run well in web browsers. This will cover Android and other non-Linux systems. * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one or two ARM boards (Beagle board black and Cubox-i seems to be the best we could pick at the moment). Talk to the manufacturers to get publicity on the images we produce and devices for the developers. Maybe not only ARM hardware. At least in South America, many places are using Classmates in educative projects. I know talks between OLPC and Intel were difficult in the past, but is a different world now. * Work with deployments to see if there are complete hardware solutions (Chromebooks for example) they could use. In the case of locked devices they might have the where-with-all to load custom software. * Migrate from X to Wayland or support it in parallel (depending on the performance of non accellerated Wayland). GNOME is doing most of the work, but we will need the rework the window management bits. This will allow us to run on Android drivers with libhybris, which should help with hardware support. As you might have noticed there is no Sugar on Android, other than for drivers support and web activities running in a web browser. I don't think going beyhond those gives us any real advantage. Just my $0.02 -- Daniel Narvaez Gonzalo ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Tech roadmap
2013/11/6 Peter Robinson pbrobin...@gmail.com: On Wed, Nov 6, 2013 at 3:12 PM, Gonzalo Odiard gonz...@laptop.org wrote: On Wed, Nov 6, 2013 at 11:49 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I think Sugar Labs needs to express a clear, realistic technology roadmap. For example, we have been talking a lot about Sugar on Android, mixing a lot of different things under that name. We need to clarify what that really is. Here are my thoughts, inspired by the oversight board meeting thread. * Wait and see what happens with the XO. Support existing deployments by producing images with the most recent Sugar release. Stick to a Fedora 18 base system, the work to upgrade is highly non trivial. Provide custom rpms for the sugar modules and a few dependencies, most importantly Webkit, which is required by web activities. In the short term, we don't need backport Webkit2 to F18. In the long term, we need find a solution to move to a newer Fedora in the XOs, maybe 20 or 21. * Ensure web activities run well in web browsers. This will cover Android and other non-Linux systems. * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one or two ARM boards (Beagle board black and Cubox-i seems to be the best we could pick at the moment). Talk to the manufacturers to get publicity on the images we produce and devices for the developers. Maybe not only ARM hardware. At least in South America, many places are using Classmates in educative projects. I know talks between OLPC and Intel were difficult in the past, but is a different world now. Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Yep. Sugar is running in classmates out of the box. In Uruguay for example. -- .. manuq .. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
On Wed, Nov 6, 2013 at 3:12 PM, Gonzalo Odiard gonz...@laptop.org wrote: On Wed, Nov 6, 2013 at 11:49 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I think Sugar Labs needs to express a clear, realistic technology roadmap. For example, we have been talking a lot about Sugar on Android, mixing a lot of different things under that name. We need to clarify what that really is. Here are my thoughts, inspired by the oversight board meeting thread. * Wait and see what happens with the XO. Support existing deployments by producing images with the most recent Sugar release. Stick to a Fedora 18 base system, the work to upgrade is highly non trivial. Provide custom rpms for the sugar modules and a few dependencies, most importantly Webkit, which is required by web activities. In the short term, we don't need backport Webkit2 to F18. In the long term, we need find a solution to move to a newer Fedora in the XOs, maybe 20 or 21. * Ensure web activities run well in web browsers. This will cover Android and other non-Linux systems. * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one or two ARM boards (Beagle board black and Cubox-i seems to be the best we could pick at the moment). Talk to the manufacturers to get publicity on the images we produce and devices for the developers. Maybe not only ARM hardware. At least in South America, many places are using Classmates in educative projects. I know talks between OLPC and Intel were difficult in the past, but is a different world now. Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Tech roadmap
Yes, but we never provided a easy way to install in classmates, or tried to approach hardware manufactures to propose them to invest on that. Gonzalo On Wed, Nov 6, 2013 at 12:20 PM, Manuel Quiñones ma...@laptop.org wrote: 2013/11/6 Peter Robinson pbrobin...@gmail.com: On Wed, Nov 6, 2013 at 3:12 PM, Gonzalo Odiard gonz...@laptop.org wrote: On Wed, Nov 6, 2013 at 11:49 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I think Sugar Labs needs to express a clear, realistic technology roadmap. For example, we have been talking a lot about Sugar on Android, mixing a lot of different things under that name. We need to clarify what that really is. Here are my thoughts, inspired by the oversight board meeting thread. * Wait and see what happens with the XO. Support existing deployments by producing images with the most recent Sugar release. Stick to a Fedora 18 base system, the work to upgrade is highly non trivial. Provide custom rpms for the sugar modules and a few dependencies, most importantly Webkit, which is required by web activities. In the short term, we don't need backport Webkit2 to F18. In the long term, we need find a solution to move to a newer Fedora in the XOs, maybe 20 or 21. * Ensure web activities run well in web browsers. This will cover Android and other non-Linux systems. * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one or two ARM boards (Beagle board black and Cubox-i seems to be the best we could pick at the moment). Talk to the manufacturers to get publicity on the images we produce and devices for the developers. Maybe not only ARM hardware. At least in South America, many places are using Classmates in educative projects. I know talks between OLPC and Intel were difficult in the past, but is a different world now. Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Yep. Sugar is running in classmates out of the box. In Uruguay for example. -- .. manuq .. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
On 6 November 2013 16:12, Gonzalo Odiard gonz...@laptop.org wrote: * Wait and see what happens with the XO. Support existing deployments by producing images with the most recent Sugar release. Stick to a Fedora 18 base system, the work to upgrade is highly non trivial. Provide custom rpms for the sugar modules and a few dependencies, most importantly Webkit, which is required by web activities. In the short term, we don't need backport Webkit2 to F18. Please elaborate :) I think developing web activities on two very different platforms (WebKit1 and WebKit2) is a bad idea, it will involve more work (and pain) then doing some backporting. In the long term, we need find a solution to move to a newer Fedora in the XOs, maybe 20 or 21. Yes, ideally. I just don't see this happening in the short time and I'm worried it might not happen at all, given the kind of work that seems to be involved. It would be awesome to be proven wrong... Until that happens though I think we need to be able to get the latest sugar (and it's dependencies) on a XO. * Ensure web activities run well in web browsers. This will cover Android and other non-Linux systems. * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one or two ARM boards (Beagle board black and Cubox-i seems to be the best we could pick at the moment). Talk to the manufacturers to get publicity on the images we produce and devices for the developers. Maybe not only ARM hardware. At least in South America, many places are using Classmates in educative projects. I know talks between OLPC and Intel were difficult in the past, but is a different world now. Yes! I think it would be good to research Intel hardware. After all they are using this wonderful secure boot stuff (sigh) instead of locking the OS, which would make things much easier... ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Tech roadmap
On 6 November 2013 16:20, Manuel Quiñones ma...@laptop.org wrote: Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Yep. Sugar is running in classmates out of the box. In Uruguay for example. You mean people are using them in Uruguay deployments? Which distro? ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Tech roadmap
2013/11/6 Daniel Narvaez dwnarv...@gmail.com: On 6 November 2013 16:20, Manuel Quiñones ma...@laptop.org wrote: Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Yep. Sugar is running in classmates out of the box. In Uruguay for example. You mean people are using them in Uruguay deployments? Which distro? I don't know the details. Maybe Flavio knows. -- .. manuq .. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
On 6 November 2013 16:45, Gonzalo Odiard gonz...@laptop.org wrote: In the short term, we don't need backport Webkit2 to F18. Please elaborate :) I think developing web activities on two very different platforms (WebKit1 and WebKit2) is a bad idea, it will involve more work (and pain) then doing some backporting. Well, with a little patch in our F18 rpm, I have all the web activities working ok in webkit1. A important missing feature is the web inspector, but they work ok. We never solved the document domain issue right (if I remember correctly you failed to get a in-activity web server running)? Current web activities are super simple but as they become more complex I think we will run into issues, domain being just one example. I'd rather not have to figure out WebKit1 *and* WebKit2 solutions every time that happens. I was looking at compile the webkit rpm from F19 in F18, but had many dependencies. I didn't explore other alternatives. Yeah, we might need to rebuild a few other deps. As soon as I have a bit of time I plan to look into doing these rebuilds in an automated way using COPR. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
On Wed, Nov 6, 2013 at 12:53 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 6 November 2013 16:45, Gonzalo Odiard gonz...@laptop.org wrote: In the short term, we don't need backport Webkit2 to F18. Please elaborate :) I think developing web activities on two very different platforms (WebKit1 and WebKit2) is a bad idea, it will involve more work (and pain) then doing some backporting. Well, with a little patch in our F18 rpm, I have all the web activities working ok in webkit1. A important missing feature is the web inspector, but they work ok. We never solved the document domain issue right (if I remember correctly you failed to get a in-activity web server running)? No. the web-server issue is already solved. Current web activities are super simple but as they become more complex I think we will run into issues, domain being just one example. I'd rather not have to figure out WebKit1 *and* WebKit2 solutions every time that happens. I hope we find the way to keep it simple :) Gonzalo ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez dwnarv...@gmail.com wrote: I forgot a note about toolkits * The gtk2 toolkit is deprecated and frozen but it will be supported as long as possible (at some point I guess some dependencies might start disappearing from distributions, making that problematic). The gtk3 toolkit is supported, backward API compatibility is guaranteed, it's not going to be deprecated in the foreseable future. The web toolkit is experimental, we provide no API guarantee yet, when it's mature it will be the preferred way to write activities (because of cross platform compatibility). The other one to add to this list is gstreamer. At the moment we have some support for gstreamer 1.0 and some (mostly gtk2) Activities still using gstreamer 0.10. The 0.10 release will be disappearing sooner rather than later (I wouldn't be surprised if this happened in F-21/F-22 time frame). I would love to see us be able to remove the dependency on two gst stacks, at the moment at least Clock, Speak, Record and Memorise need to be converted from gstreamer-python / gst 0.10 to gst 1.0 with Introspection support, whether this requires migration to gtk3 at the same time is unknown to me. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
Gstreamer 0.10 is part of what I'm calling gtk2 toolkit, it's not completely accurate but we have been using than terminology. So it seems we are going to run into the issue of gtk2 toolkit pieces disappearing earlier then I expected. I think you can move to gst 1.0 only if you already ported to gtk3. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
No. the web-server issue is already solved. If we want to support WebKit1, I think we should do it upstream then. I'm still not thrilled about that but not opposed to it either. Good. We can see what is the better way to do it. May be check the webkit version installed? Just for reference, the changes we did are here: https://github.com/godiard/au1b_rpms/blob/master/sugar-toolkit-gtk3/0001-Adapt-webactivity-to-work-with-webkit1.patch Gonzalo ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
Clock, Speak, and part of Memorize use gstreamer just to do text to speech. I would like to have tts provided by Sugar as a service, probably using dbus and a api in sugar-toolkit-gtk3. That would simplify these activities and solve other problems we have, like by example the keep the language names translated and updated in every place. Gonzalo On Wed, Nov 6, 2013 at 1:40 PM, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez dwnarv...@gmail.com wrote: I forgot a note about toolkits * The gtk2 toolkit is deprecated and frozen but it will be supported as long as possible (at some point I guess some dependencies might start disappearing from distributions, making that problematic). The gtk3 toolkit is supported, backward API compatibility is guaranteed, it's not going to be deprecated in the foreseable future. The web toolkit is experimental, we provide no API guarantee yet, when it's mature it will be the preferred way to write activities (because of cross platform compatibility). The other one to add to this list is gstreamer. At the moment we have some support for gstreamer 1.0 and some (mostly gtk2) Activities still using gstreamer 0.10. The 0.10 release will be disappearing sooner rather than later (I wouldn't be surprised if this happened in F-21/F-22 time frame). I would love to see us be able to remove the dependency on two gst stacks, at the moment at least Clock, Speak, Record and Memorise need to be converted from gstreamer-python / gst 0.10 to gst 1.0 with Introspection support, whether this requires migration to gtk3 at the same time is unknown to me. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Tech roadmap
On Wed, Nov 6, 2013 at 12:35 PM, Gonzalo Odiard gonz...@laptop.org wrote: Clock, Speak, and part of Memorize use gstreamer just to do text to speech. I would like to have tts provided by Sugar as a service, probably using dbus and a api in sugar-toolkit-gtk3. That would simplify these activities and solve other problems we have, like by example the keep the language names translated and updated in every place. I've had a few false starts trying to port Measure to GST 1.0. Once I get that working, Turtle Art will follow (that is why I still haven't released the GTK 3 version of Turtle Art). -walter Gonzalo On Wed, Nov 6, 2013 at 1:40 PM, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez dwnarv...@gmail.com wrote: I forgot a note about toolkits * The gtk2 toolkit is deprecated and frozen but it will be supported as long as possible (at some point I guess some dependencies might start disappearing from distributions, making that problematic). The gtk3 toolkit is supported, backward API compatibility is guaranteed, it's not going to be deprecated in the foreseable future. The web toolkit is experimental, we provide no API guarantee yet, when it's mature it will be the preferred way to write activities (because of cross platform compatibility). The other one to add to this list is gstreamer. At the moment we have some support for gstreamer 1.0 and some (mostly gtk2) Activities still using gstreamer 0.10. The 0.10 release will be disappearing sooner rather than later (I wouldn't be surprised if this happened in F-21/F-22 time frame). I would love to see us be able to remove the dependency on two gst stacks, at the moment at least Clock, Speak, Record and Memorise need to be converted from gstreamer-python / gst 0.10 to gst 1.0 with Introspection support, whether this requires migration to gtk3 at the same time is unknown to me. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
Did you run into any specific issue? On Wednesday, 6 November 2013, Walter Bender wrote: On Wed, Nov 6, 2013 at 12:35 PM, Gonzalo Odiard gonz...@laptop.orgjavascript:; wrote: Clock, Speak, and part of Memorize use gstreamer just to do text to speech. I would like to have tts provided by Sugar as a service, probably using dbus and a api in sugar-toolkit-gtk3. That would simplify these activities and solve other problems we have, like by example the keep the language names translated and updated in every place. I've had a few false starts trying to port Measure to GST 1.0. Once I get that working, Turtle Art will follow (that is why I still haven't released the GTK 3 version of Turtle Art). -walter Gonzalo On Wed, Nov 6, 2013 at 1:40 PM, Peter Robinson pbrobin...@gmail.comjavascript:; wrote: On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: I forgot a note about toolkits * The gtk2 toolkit is deprecated and frozen but it will be supported as long as possible (at some point I guess some dependencies might start disappearing from distributions, making that problematic). The gtk3 toolkit is supported, backward API compatibility is guaranteed, it's not going to be deprecated in the foreseable future. The web toolkit is experimental, we provide no API guarantee yet, when it's mature it will be the preferred way to write activities (because of cross platform compatibility). The other one to add to this list is gstreamer. At the moment we have some support for gstreamer 1.0 and some (mostly gtk2) Activities still using gstreamer 0.10. The 0.10 release will be disappearing sooner rather than later (I wouldn't be surprised if this happened in F-21/F-22 time frame). I would love to see us be able to remove the dependency on two gst stacks, at the moment at least Clock, Speak, Record and Memorise need to be converted from gstreamer-python / gst 0.10 to gst 1.0 with Introspection support, whether this requires migration to gtk3 at the same time is unknown to me. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
On Wed, Nov 6, 2013 at 2:10 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Did you run into any specific issue? It has been a while, but I had some issues with lack of introspection support with some pad stuff... will look again over the weekend. -walter On Wednesday, 6 November 2013, Walter Bender wrote: On Wed, Nov 6, 2013 at 12:35 PM, Gonzalo Odiard gonz...@laptop.org wrote: Clock, Speak, and part of Memorize use gstreamer just to do text to speech. I would like to have tts provided by Sugar as a service, probably using dbus and a api in sugar-toolkit-gtk3. That would simplify these activities and solve other problems we have, like by example the keep the language names translated and updated in every place. I've had a few false starts trying to port Measure to GST 1.0. Once I get that working, Turtle Art will follow (that is why I still haven't released the GTK 3 version of Turtle Art). -walter Gonzalo On Wed, Nov 6, 2013 at 1:40 PM, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez dwnarv...@gmail.com wrote: I forgot a note about toolkits * The gtk2 toolkit is deprecated and frozen but it will be supported as long as possible (at some point I guess some dependencies might start disappearing from distributions, making that problematic). The gtk3 toolkit is supported, backward API compatibility is guaranteed, it's not going to be deprecated in the foreseable future. The web toolkit is experimental, we provide no API guarantee yet, when it's mature it will be the preferred way to write activities (because of cross platform compatibility). The other one to add to this list is gstreamer. At the moment we have some support for gstreamer 1.0 and some (mostly gtk2) Activities still using gstreamer 0.10. The 0.10 release will be disappearing sooner rather than later (I wouldn't be surprised if this happened in F-21/F-22 time frame). I would love to see us be able to remove the dependency on two gst stacks, at the moment at least Clock, Speak, Record and Memorise need to be converted from gstreamer-python / gst 0.10 to gst 1.0 with Introspection support, whether this requires migration to gtk3 at the same time is unknown to me. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
On Wed, Nov 6, 2013 at 7:13 PM, Walter Bender walter.ben...@gmail.com wrote: On Wed, Nov 6, 2013 at 2:10 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Did you run into any specific issue? It has been a while, but I had some issues with lack of introspection support with some pad stuff... will look again over the weekend. I would look at the gst 1.2.0 release and see how you get on there, it's in Fedora 20. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Tech roadmap
/On 06/11/2013 13:31, Daniel Narvaez wrote:// //You mean people are using them in Uruguay deployments? Which distro?/ -- In Uruguay we have Classmates II (called Magallanes) in some High Schools, that comes with Ubuntu 10.01.3 and Sugar Sweets Distribution (0.94.1), you can download the image here http://www.ceibal.edu.uy/Articulos/Paginas/%C2%BFC%C3%B3mo%20flasheo%20mi%20Magallanes%20MG2%20Ubuntu_.aspx. (hardware http://www.ceibal.edu.uy/Articulos/Paginas/hardware-magallanes-3.aspx and Software http://www.ceibal.edu.uy/Articulos/Paginas/software-magallanes.aspx specifications). In other High schools the children have XO 1.5, 1.75 or 4.0, and in some kindergardens and schools (1st grade) they have OLPC tablets http://www.ceibal.edu.uy/Articulos/Paginas/informacion-de-la-tablet.aspx with Android. By the way: in High Schools there are very few people who uses Sugar, they normally use the Gnome interface, as in primary School, except for a part of the children that still have the XO 1.0 without Gnome. Paolo Benini Montevideo ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sur] Sugar oversight board meeting
On Mon, Nov 4, 2013 at 11:05 PM, Peter Robinson pbrobin...@gmail.comwrote: 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. This wiped out a year and a half of hard work on my part and others who were successfully building SoaS as the pillar of our marketing strategy, cf. BBC coverage etc. We had been marketing SoaS as a concept - Sugar on OLPC now available on a $5 stick. Mel's approach was to turn SoaS into an example of how Fedora was well-suited as a technical platform for themed spins - certainly true, but of no interest to teachers. Unfortunately, key components for a smooth teacher experience - an up-to-date liveUSB installer, Sugar branded first-run screens such as Trisquel - became more, not less difficult to create with the spin status. Of course, this wasn't the only effort by community members to lay claim to SoaS; a former contributor had even registered a domain name and built a separate SoaS minisite, hoping to obtain exclusive distribution rights, and only closed the site under pressure. In traditional free software projects, engineers make the decisions then communicate (usually quite late in the process) with their marketers. This is almost completely ineffective, which is why I wasn't prepared to contribute time and expertise under those conditions. The several thousand USD I had contributed to seed the marketing effort (remember the branded USB sticks?) had allowed us to obtain excellent results, however as of two years ago I've been unable to continue that financing for personal reasons. Looking forward, I myself feel prebuilt VMs with pancake installers for Windows, OSX and GNU/Linux (including SoaS images cf. [1]) would be our best bet to offer a Sugar experience to interested teachers. I use a VirtualBox VM on a Mac when I present Sugar to audiences, and it works very well, inheriting network connections, fullscreen etc. Of course, the downside is enormous download images, and I don't underestimate the work and infrastructure required to keep a matrix of images available. So yes Peter, I salute your hard work on SoaS; for want of a better strategy it has even been kept on the SL homepage for three years. However, for SoaS to aid SL in raising awareness, allowing teachers to overcome the installation and unfamiliarity barriers, and providing a path to non-OLPC hardware in a world massively dropping the PC for tablets, additional teacher-friendly components are necessary and the marketing needs to be done by marketers. Sean Sugar Labs Marketing Coordinator P.S. I'm quite interested in your proposals concerning ARM boxes; I have always maintained that a non-OLPC OEM deal would allow us to bypass the installation barrier. That said, my interest in the Raspberry Pi is from a marketing standpoint - they have over a million sold, corporate sponsorships in the UK, wide press coverage, retail distributors, only one official SD card OS for non-advanced users, and are seeking education partners to better reach students. 1. http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Virtual_machines ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sur] Sugar oversight board meeting
El 06/11/13 17:35, Sean DALY escribió: On Mon, Nov 4, 2013 at 11:05 PM, Peter Robinson pbrobin...@gmail.com mailto: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 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
In F18 we can do: from gi.repository import WebKit2 but later crash, not sure where. Gonzalo On Wed, Nov 6, 2013 at 8:20 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 6 November 2013 18:32, Gonzalo Odiard gonz...@laptop.org wrote: No. the web-server issue is already solved. If we want to support WebKit1, I think we should do it upstream then. I'm still not thrilled about that but not opposed to it either. Good. We can see what is the better way to do it. May be check the webkit version installed? Just for reference, the changes we did are here: https://github.com/godiard/au1b_rpms/blob/master/sugar-toolkit-gtk3/0001-Adapt-webactivity-to-work-with-webkit1.patch I think the best way to detect it would be to import WebKit2, if it fails fall back to WebKit. I'm not sure what's the best way to maintain the two different implementations though. Maybe two modules with identical interfaces, imported as webview. So something like this in webactivity.py: try: from gi.repository import WebKit2 except ImportError: pass if WebKit2: from sugar.activity import webkit1view as webview else: from sugar.activity import webkit2view as webview class WebActivity: def __init__(self): self._web_view = webview.WebView() ... ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
Yeah, is a option. Gonzalo On Wed, Nov 6, 2013 at 8:50 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 7 November 2013 00:37, Gonzalo Odiard gonz...@laptop.org wrote: In F18 we can do: from gi.repository import WebKit2 but later crash, not sure where. Hrm, yeah, I had forgot the exact situation in Fedora 18... Then I'm afraid the only solid approach I can think of is testing for a SUGAR_WEBKIT_VERSION environment variable, set perhaps by a /usr/bin/sugar patched by the rpms. -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Tech roadmap
Cool stuff. As for Fedora it would be great to have builds with the latest sugar (stable and unstable) releases. I'm not saying to ship those to deployments of course, but they would help upstream development, marketing and testing... And they would help AC to make the transition to the next sugar release smoother. On 7 November 2013 02:05, David Farning dfarn...@activitycentral.comwrote: Please see the link at the bottom left of http://dextrose.ac/platform/ for the Sugar on Ubuntu images which Activity Central and Plan Ceibal are jointly developing. For stability it is based on Ubuntu 12.04 and Sugar .98. The testing is done on classmate to meet Plan Ceibal's specifications. I should work equally well on any machine that boots Ubuntu. It is currently is small scale testing by a couple hundred teachers. When the image meets Ceibal's quality standards the pilot will scale to approximately 10,000 units for wider testing. For more information, I have CC Anish Mangal, the project owner (agile speak) and Ruben Rodriguez the lead developer. Ruben has the strongest back ground on the technical issues involved in the port. Anish has the deepest understanding of timelines and objectives. On Wed, Nov 6, 2013 at 9:31 AM, Daniel Narvaez dwnarv...@gmail.com wrote: On 6 November 2013 16:20, Manuel Quiñones ma...@laptop.org wrote: Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Yep. Sugar is running in classmates out of the box. In Uruguay for example. You mean people are using them in Uruguay deployments? Which distro? ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- David Farning Activity Central: http://www.activitycentral.com -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Tech roadmap
I agree :) Right now, we are sitting back and seeing what roll OLPC-Australia is going to play in the ecosystem. The One Education distribution out of Australia is a combination of Dextrose, Sugar .100 and some custom patches. My semi-informed guess is that Walter and Rangan ( https://www.laptop.org.au/about ) are going to position One Education as the successor to OLPC-OS. I hope that we will learn more at about their plans at basecamp. ( http://olpcbasecamp.blogspot.com/ ) This would take care or the leading edge on Fedora. On the Ubuntu side we have a bit of a challenge balancing bleeding edge and stability. Sugar and Fedora tend to run a bit ahead of Debian and Ubuntu in library versions. It take a significant amount of effort to backport the necessary libraries to Ubuntu LTS. For this release we agreed that the proper balance of innovation and stability was Sugar .98 on Ubuntu 12.04. The next decision point will be which version of Sugar to use for the 14.04 release due in the second quarter of 2014. On Wed, Nov 6, 2013 at 8:05 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Cool stuff. As for Fedora it would be great to have builds with the latest sugar (stable and unstable) releases. I'm not saying to ship those to deployments of course, but they would help upstream development, marketing and testing... And they would help AC to make the transition to the next sugar release smoother. On 7 November 2013 02:05, David Farning dfarn...@activitycentral.com wrote: Please see the link at the bottom left of http://dextrose.ac/platform/ for the Sugar on Ubuntu images which Activity Central and Plan Ceibal are jointly developing. For stability it is based on Ubuntu 12.04 and Sugar .98. The testing is done on classmate to meet Plan Ceibal's specifications. I should work equally well on any machine that boots Ubuntu. It is currently is small scale testing by a couple hundred teachers. When the image meets Ceibal's quality standards the pilot will scale to approximately 10,000 units for wider testing. For more information, I have CC Anish Mangal, the project owner (agile speak) and Ruben Rodriguez the lead developer. Ruben has the strongest back ground on the technical issues involved in the port. Anish has the deepest understanding of timelines and objectives. On Wed, Nov 6, 2013 at 9:31 AM, Daniel Narvaez dwnarv...@gmail.com wrote: On 6 November 2013 16:20, Manuel Quiñones ma...@laptop.org wrote: Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Yep. Sugar is running in classmates out of the box. In Uruguay for example. You mean people are using them in Uruguay deployments? Which distro? ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- David Farning Activity Central: http://www.activitycentral.com -- Daniel Narvaez -- David Farning Activity Central: http://www.activitycentral.com ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Localization] Translation Manual (in Spanish)
El 29/10/13 08:18, Chris Leonard escribió: Nothing would make me happier than to take myself out of the account creation loop, but on observing the number of dummy accounts being created (and activated) each day, I reluctantly took the step fo turning off self-serve registration to protect the integrity of the precious L10n work. Hi, I'm glad to report that you can be happy now. Alsroot gave me access today to current pootle and I managed to activate the built-in captcha for registration. I created three users, but I'm not sure how to remove them: test, test-captcha and test-captcha-again. It will be a good idea to keep an eye on new users as maybe spammers can defeat some kinds of captchas. Hopefully not. About the diagram shared by Laura, is it a good first step for a completely new language that requires it, to translate the glibc_helper.po http://translate.sugarlabs.org/export/Sandbox/gn/glibc_helper.po file first and submit it to localization@ , or do you have another suggestion for a first step? Regards, Sebastian ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
