[IAEP] For Sugar Everywhere, Google-ize!

[William Schaub]

On 02/16/2011 02:11 PM, Walter Bender 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.
>
> -walter
>
> On Wed, Feb 16, 2011 at 2:09 PM, C. Scott Ananian<cscott at cscott.net>  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!)
>> IAEP at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>>
>
>

I think it would be very hard to try and make sugar activities run under 
Android. you may think jython is an option but I don't think jython can 
run at all
in the "java" environment provided by android. as it does not implement 
the full Java APIs and its virtual machine is radically different. you 
would first need to port jython to run on the dalvik virtual machine and 
use the android APIs.

Or you might be able to get away with doing something like the Android 
Scripting Environment(3rd party project) which packages up a real python 
interpreter onto the android and uses RPC calls to access the android 
APIs in order to use the UI elements. but forcing native non-supported 
runtime environments onto the phone might not be th best approach.

I'm looking into trying to make an activity of my own run on the android 
platform myself so I've already looked into this. While I hope to use 
the ASE as a template to build my application package on (so i can run 
network services written in python and some other native bits) I don't 
think theres much getting around still having to use Java for the UI. 
and even then I will want to do a pure (android flavored) java 
implementation down the road anyway for android because it would just be 
a lot less clunky that way.

I really wish google had gone with python instead of their own version 
of Java.

If you still want to try and do sugar on the android in a backwards 
compatible way I would look into how the ASE is implemented as a 
starting point.
you would basically have to make your own display system as well as just 
being able to run python in order to even render the pygtk calls.

Either way you would have a huge amount of native ARM binaries compiled 
and packaged just for the android and if they decided to make android 
phones with anything other than ARM chips in them you would have plenty 
of trouble.

I still need to get my main sugar activity working on the OLPC (I'm 
re-writing it from my perl prototype into Python and packaging it as a 
normal sugar activity) first but I do plan on making it work on the 
android and will be glad to share my experiences with that if anyone is 
interested.