<br><br><div class="gmail_quote">On Wed, Feb 16, 2011 at 2:11 PM, Walter Bender <span dir="ltr"><<a href="mailto:walter.bender@gmail.com">walter.bender@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
FWIW, there are already some efforts underway to port some Sugar<br>
activities to Android... hope to learn from those efforts in the short<br>
term.<br>
<br></blockquote><div><br></div><div>Are there links or info about this efforts ?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
-walter<br>
<div><div></div><div class="h5"><br>
On Wed, Feb 16, 2011 at 2:09 PM, C. Scott Ananian <<a href="mailto:cscott@cscott.net">cscott@cscott.net</a>> wrote:<br>
> Hi folks. I wish to make a radical proposal:<br>
> Sugar's days on OLPC hardware are numbered. Sugar as presently written is<br>
> not developing quickly enough, and hasn't made significant progress towards<br>
> supporting the new touchscreen devices coming down the pike.<br>
> This isn't a problem: it's an opportunity!<br>
> I believe that SugarLabs should radically embrace "Sugar Everywhere". In my<br>
> opinion, this means attempting to target Android or ChromeOS with Sugar<br>
> activities as quickly as possible.<br>
> "But these OSes aren't geared for learning!" you might respond. Neither was<br>
> Linux, until Sugar arrived! Nor was GNOME!<br>
> First, let's take a serious look at where we *actually* are with respect to<br>
> self-programmability of Sugar.<br>
> There isn't a serious IDE. None of the Sugar software is accessible via the<br>
> Journal. Much of it is actually writable only by root!<br>
> Python is a great pedagogic language, but the best tutorials to show how<br>
> Sugar can be hacked start by teaching kids vi!<br>
> Viewed dispassionately, we have fallen very short of the 'view source'<br>
> ideals, and activities like Scratch or Etoys provide a much better pedagogic<br>
> introduction to programming than attempting to read through the python<br>
> sources of Sugar does.<br>
> If Sugar were to rebase on Android, one of the first tasks would be to<br>
> figure out how to run as many of the existing activities in Android as<br>
> possible. This can be done via projects like Jython, which implement Python<br>
> in Java, and by reimplementing some of the underlying Sugar collaboration<br>
> and storage services. The activities are the most important part of Sugar!<br>
> We don't need to reimplement the frame, or activity management, or<br>
> networking configuration (at first) -- take advantage of the hardware<br>
> support of Android and build on its OS services, and concentrate SugarLab's<br>
> limited energies on the activities.<br>
> In addition to getting Scratch/Etoys/Speak/Pippy to run on Android, the<br>
> Sugar community can contribute a simple Java compiler to make Android<br>
> more-fully self-hosting. Perhaps some small hacks to Android are needed to<br>
> allow it to install apps from its own filesystem. Android is open source,<br>
> go for it! The result may be a slightly tweaked android, but<br>
> Sugar-on-Android will be portable to hundreds of different low-cost phones<br>
> and tablets from any number of different manufacturers. Sugar everywhere!<br>
> Or perhaps consider rebasing Sugar on ChromeOS. Existing Sugar applications<br>
> could run in a plugin, or as a Chrome extension. In addition, new Sugar<br>
> activities could be written in *web standard languages*. In my travels in<br>
> South America, Python is still an oddball out-lyer. But universities are<br>
> eager to teach HTML and Javascript. Further, Javascript interpreters in<br>
> browsers are many times faster than Python, and getting faster all the time.<br>
> Consider also that the "Chrome Debugger" is already a *much* better IDE<br>
> than Pippy, and already fulfills the most important goal of the "view<br>
> source" manifesto -- you can click on *any visible thing* on the webpage,<br>
> and see immediately what code produced it. We're still a very long way from<br>
> that goal in Sugar/Python. Again, we can build on the system support of<br>
> Chrome OS (starting apps, configuring networking, preferences, etc) and<br>
> build activities as web applications (which can use a special chrome<br>
> extension for additional services, including collaboration and the journal)<br>
> which can again run on a large number of different devices.<br>
> Portable devices are the future. Lots of manufacturers are already spending<br>
> enormous amounts of effort on hardware porting and all the UI and network<br>
> and system management tasks for their devices. Sugar shouldn't need to<br>
> reproduce this work, or be tied to particular hardware. By capitalizing on<br>
> the existing work done for Android or ChromeOS, SugarLabs can concentrate on<br>
> what makes Sugar great: strong support by educators, excellent activities,<br>
> and a focus on making the system introspectable and hackable.<br>
> --scott<br>
> --<br>
> ( <a href="http://cscott.net/" target="_blank">http://cscott.net/</a> )<br>
><br>
</div></div>> _______________________________________________<br>
> IAEP -- It's An Education Project (not a laptop project!)<br>
> <a href="mailto:IAEP@lists.sugarlabs.org">IAEP@lists.sugarlabs.org</a><br>
> <a href="http://lists.sugarlabs.org/listinfo/iaep" target="_blank">http://lists.sugarlabs.org/listinfo/iaep</a><br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
Walter Bender<br>
Sugar Labs<br>
<a href="http://www.sugarlabs.org" target="_blank">http://www.sugarlabs.org</a><br>
_______________________________________________<br>
IAEP -- It's An Education Project (not a laptop project!)<br>
<a href="mailto:IAEP@lists.sugarlabs.org">IAEP@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/iaep" target="_blank">http://lists.sugarlabs.org/listinfo/iaep</a><br>
</font></blockquote></div><br>