[IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread C. Scott Ananian
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 opportuni

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Walter Bender
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 wrote: > Hi folks.  I wish to make a radical proposal: > Sugar's days on OLPC hardware are numbe

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Rafael Ortiz
On Wed, Feb 16, 2011 at 2: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. > > Are there links or info about this efforts ? > -walter > > On Wed, Feb 16, 2011 at 2:09 P

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Martin Langhoff
Hi folks.  I wish to make a radical proposal: Sugar is starting to move forward again. We could focus or we could Get Distracted! :-) [ Yes, there are some interesting hints on the Android side. And on the cloud. And Tablets! And ChromeOS! And Win7-on-Nokia! Don't forget Kinect. Rebase and reimp

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread C. Scott Ananian
On Wed, Feb 16, 2011 at 2:28 PM, Martin Langhoff wrote: > Sugar is starting to move forward again. We could focus or we could > Get Distracted! > Well, you can pretend that the current course is not heading into a brick wall, or you can choose one or two new ideas and make them work. What I'm ar

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Christian Bryant
I'm curious, is there a comprehensive requirements and/or design document for Sugar against which the recommendation is measured? I'd be curious to see a "gap analysis" that supports the argument to not use Python. If nothing else, I'd vote for a solid wiki page that can properly frame the idea,

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread C. Scott Ananian
On Wed, Feb 16, 2011 at 3:26 PM, Christian Bryant < christianabry...@linux.com> wrote: > I'm curious, is there a comprehensive requirements and/or design > document for Sugar against which the recommendation is measured? I'd > be curious to see a "gap analysis" that supports the argument to not >

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread 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 wrote: Hi folks. I wish to make a radical propo

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Frederick Grose
On Wed, Feb 16, 2011 at 3:19 PM, C. Scott Ananian wrote: > On Wed, Feb 16, 2011 at 2:28 PM, Martin Langhoff < > martin.langh...@gmail.com> wrote: > >> Sugar is starting to move forward again. We could focus or we could >> Get Distracted! >> > The opportunity is that 'We' could become larger, as i

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Chris Ball
Hi Scott, Thanks for the proposal, lots of combustible material here. :) I wouldn't be very excited about just porting Sugar activities to a stock Android base. I think our goals for Sugar are mainly to build educational software that: * can be appropriated -- translated, modified, discussed.

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread C. Scott Ananian
On Wed, Feb 16, 2011 at 6:42 PM, Chris Ball wrote: > Thanks for the proposal, lots of combustible material here. :) > I was hoping "ask interesting questions", as Martin says. > I wouldn't be very excited about just porting Sugar activities to a > stock Android base. I think our goals for Sug

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread C. Scott Ananian
Stepping back for a moment, the key question is: how can we get Sugar out of the window manager and network manager and activity update and UI toolkit business, where it's just not keeping up (and wasting our efforts), and concentrate on the stuff we're all really here for: enabling kids to learn a

[IAEP] What kind of jack can you use for sensors?

2011-02-16 Thread Steve Thomas
I am working on a project where kids will measure tempature and humidity as part of testing and designing solar stills. What kind of jack do I need to connect to my sensors? I assume I plug it into the microphone jack and that should work with the Etoys World Stethescope. Stephen

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Chris Ball
Hi Scott, > If Android apps to date have not accomplished this, that just > means there's an opportunity! I think the infrastructure is > what's missing here: reusable libraries for collaboration / > sharing. Something Pippy-like or Java-compiler-like that makes > it possible to di

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Frederick Grose
On Wed, Feb 16, 2011 at 7:53 PM, Chris Ball wrote: > {...} > > That does sound interesting -- I don't know much about what it's > possible to do with JavaScript these days, but the combination of > being faster than Python and being pervasively editable is exciting. > Do you know of any proof-of-

Re: [IAEP] What kind of jack can you use for sensors?

2011-02-16 Thread Nicholas Doiron
Microphone jack is the best way to go, especially if you are using eToys. Where are you getting the sensors from? Are you using an XO laptop? We had an environmental sensing class in Uganda that used temperature and light sensors. To give a basic view of what the sensor is doing, I modified th

Re: [IAEP] What kind of jack can you use for sensors?

2011-02-16 Thread forster
> I am working on a project where kids will measure tempature and humidity as > part of testing and designing solar stills. > > What kind of jack do I need to connect to my sensors? > I assume I plug it into the microphone jack and that should work with the > Etoys World Stethescope. Steve You n

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Christoph Derndorfer
Am 17.02.2011 01:31, schrieb C. Scott Ananian: > Stepping back for a moment, the key question is: how can we get Sugar > out of the window manager and network manager and activity update and > UI toolkit business, where it's just not keeping up (and wasting our > efforts), and concentrate on the st

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Chris Ball
Hi Christoph, > So based on these assumptions, given the limited amount of > resources available, and assuming I haven't missed anything your > suggestion would basically mean sacrificing the potential to > significantly improve the experience of the current >1 million > Sugar users

Re: [IAEP] What kind of jack can you use for sensors?

2011-02-16 Thread Steve Thomas
Thanks I will add if testing goes well. Yes I am using on an XO. On Wed, Feb 16, 2011 at 8:11 PM, wrote: > > I am working on a project where kids will measure tempature and humidity > as > > part of testing and designing solar stills. > > > > What kind of jack do I need to connect to my sensors

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Christoph Derndorfer
Am 17.02.2011 02:53, schrieb Chris Ball: > Hi Christoph, > >> So based on these assumptions, given the limited amount of >> resources available, and assuming I haven't missed anything your >> suggestion would basically mean sacrificing the potential to >> significantly improve the

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Seth Woodworth
> 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. Scott, your suggestion is radical,

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Christian Bryant
I personally am excited to see new architectures that change the face of a familiar system. That said, I also believe the new architecture must benefit the end user either equal to or greater than the benefit of the original architecture. I also believe the support for those users should not dete

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Chris Ball
Hi, > Stepping back for a moment, the key question is: how can we get > Sugar out of the window manager and network manager and activity > update and UI toolkit business, where it's just not keeping up > (and wasting our efforts), and concentrate on the stuff we're all > really here

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Martin Langhoff
On Wed, Feb 16, 2011 at 7:31 PM, C. Scott Ananian wrote: > Stepping back for a moment, the key question is: how can we get Sugar > out of the window manager and network manager and activity update and > UI toolkit business, where it's just not keeping up (and wasting our > efforts), and concentrat

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Chris Ball
Hi Christian, (I should probably stop jumping into this thread and let other people reply so I can find out what they think too!) > I also believe the support for those users should not > deteriorate, meaning folks like the OLPC Support Gang need to > learn the new system (assuming troub

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Martin Sevior
The current collection of sugar apps use pyGtk for interfaces. In the case of Write, this is a C++ library linked with Gtk-2 with the UI written with pyGtk. It seems to me that the minimum requirement for this idea to have the remotest chance of reusing all the work that has gone into sugar so far

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Seth Woodworth
There is QT for android as another avenue for porting existing applications. But if the goal is a full featured word processing application, I suspect there are other routes to the same goal in the Android world. On Wed, Feb 16, 2011 at 10:16 PM, Martin Sevior wrote: > The current collection of

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread C. Scott Ananian
On Wed, Feb 16, 2011 at 10:16 PM, Martin Sevior wrote: > It seems to me that the minimum requirement for this idea to have the > remotest chance of reusing all the work that has gone into sugar so > far is for Gtk to have android graphics backend. Gtk-3.0 can > apparently now draw to HTML 5. > >

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread C. Scott Ananian
On Wed, Feb 16, 2011 at 10:01 PM, Martin Langhoff wrote: > I look back at when OLPC started, and some things have changed in the > world _we_ live in. But the kids we want to help with... their world > hasn't changed much. They still haven't got internet for starters. > Some things might be a tad

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread C. Scott Ananian
On Wed, Feb 16, 2011 at 9:46 PM, Chris Ball wrote: > Hi, > > > Stepping back for a moment, the key question is: how can we get > > Sugar out of the window manager and network manager and activity > > update and UI toolkit business, where it's just not keeping up > > (and wasting our effor

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Walter Bender
On Wed, Feb 16, 2011 at 9:46 PM, Chris Ball wrote: > Hi, > >   > Stepping back for a moment, the key question is: how can we get >   > Sugar out of the window manager and network manager and activity >   > update and UI toolkit business, where it's just not keeping up >   > (and wasting our effort

Re: [IAEP] For Sugar Everywhere, Google-ize!

2011-02-16 Thread Michael Stone
On Wed, 16 Feb 2011 at 21:46:04 -0500, Chris Ball wrote: Hi, > Stepping back for a moment, the key question is: how can we get > Sugar out of the window manager and network manager and activity > update and UI toolkit business, where it's just not keeping up > (and wasting our effor