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