[OLPC-Games] Embedding pygame in gtk.

[C. Scott Ananian]

On Dec 25, 2007 12:51 AM, Mike C. Fletcher <mcfletch at vrplumber.com> wrote:
> But OLPCGames is intended to support non-trivial activities as well, and
> to my eyes it *seems* like Pippy could support those reasonably easily.
> If it will never support them, then we probably need a more generic
> mechanism put into OLPCGames.  At the least, I would expect a generic
> mechanism to pack the *whole* activity into the Journal, not just a
> single file.  Even if Pippy only edits a single file from the activity,
> having the whole file stored would let a more involved IDE work on the
> package and would at least give Pippy a chance not to produce garbage
> output if the user changes the one file it knows to edit.

Something like Pippy will eventually support multiple files; I've even
tentatively called this "Poppy" =).  But, as you can tell, I'm
deliberately trying to downplay expectations for Pippy.  I'll describe
why below...

> Which is fine.  It still seems like Pippy should be able to handle
> loading an .xo file just as easily as you handle loading a directory of
> examples.  The difference would simply be having a way to specify a new
> name for a file and maybe having a "delete" operation for files.

It's complexity I think is better suited for a larger tool, that's all.

> Anyway, the point I was *trying* to make, before we got onto the "Pippy
> is great" track ;) , was that the details you are going to need to deal
> with eventually are largely handled by OLPCGames already.  I'm currently
> working on breaking out the functionality a little so that it can be
> more readily used piece-meal as well.

And the question I meant to ask was:  should OLPCGames be integrated
into the Pippy library?  Or should we be distributing OLPCGames as
part of the base system, so that we wouldn't need to shoehorn it into
a library?  Or should we just take the bits which are most relevant to
a Pippy application and put that into the library, and leave out the
rest?

> able to edit the source for non-trivial projects.  If Pippy will *never*
> have that, then I'm hesitant to add Pippy-specific code to the general
> library.

Pippy won't ever edit completely arbitrary projects.  'Develop' might.
 'Poppy' probably won't: I'll probably continue to insist on a
slightly stereotyped activity layout in order to simplify the learning
curve and UI.  All datafiles may go into a "data" directory, say, and
the main activity file will always be named 'activity.py', etc.  We
might allow multiple files but no subdirectories.

> > Again, Pippy *exists right now*, unlike versioned files in the
> > Journal.  And it's useful in its current state!
> >
> Um, why the intensity/defensiveness?  I don't believe I declared Pippy
> useless.  I merely pointed out how it could be more useful.  AFAIK Pippy
> is a useful way to learn coding.  The OLPCGames users are generally
> working on slightly larger projects, I'm pointing out what would make
> connecting Pippy up to their games useful to them.  Having a view source
> key automatically linked into your activity that can only view 1/100th
> of the code there is more likely to confuse kids than help them learn...
> i.e. we'd need to make the binding optional until IDE support for large
> packages is widespread.

I apologize for the defensiveness.

I've seen a lot of interesting projects around the XO falter because
people get all excited about what *could* happen and start building
elaborate castles, only to get *nothing* done because their ambition
was so great.  As a result, I've developed a knee-jerk reaction
(sorry!) against complexity, and prefer to concentrate on a series of
small steps that improve the present situation.

Pippy is designed to be a small tool for simple programs.  It's not
(the mythical) 'Develop'.  However, it can be pushed pretty far if
it's all a kid has.  There are small features I'd like to add: a
drag-and-drop way to set the activity icon (which unfortunately
requires a way to create .svg files on the laptop -- another place
where I think our desire to support all of SVG has gotten in the way
of someone writing a minimal icon-editor application), and some way to
localize the generated applications (ok, this isn't really a small
feature).

But I'd like the libraries which the kid learns to use in Pippy be
scalable to full-scale applications once they graduate to 'Poppy' or
'Develop'.  Hence, it seems wise to use the OLPCGames library where
possible -- but the complexity has to be low enough that it doesn't
interfere with Pippy's primary goal, which is introductory
programming.

> That said, you could certainly use the OLPCGames wrapper to handle the
> problem of upgrading a Pippy Pygame activity to a "real" activity
> embedded in GTK with the various support mechanisms you might desire.

Right.  I'm imagining an
  from pippy.pygame.activity import *
being all that's required to generate a proper Activity.

> As for versioned Journal entries, I was actually suggesting allowing
> versioned directory names when saving out a .xo to the file-system.
> That is, allow ~/Activities to include both a ~/Productive-1.activity
> and a ~/Productive-2.activity with Sugar choosing the latest by default
> to show on the launch bar, but providing options to launch the earlier
> ones.  With that you could have Pippy auto-increment versions and save
> out.  If you had the sub-version support as well (i.e. 1.1) then you
> could do that without having massive version inflation when you finally
> publish/share.  That does not, of course, handle all the evil questions
> of two people concurrently modifying the activity and then joining the
> same activity, but without using hashes and the like that's not likely
> going anywhere anyway.  Still, as you seem to be saying we are only
> looking at today's API, you are correct, there is no such support that
> I'm aware of.

You can manually set a version number when you save a Pippy activity;
as above I'm hesitant to try to address the other problems without
concurrent work on the datastore (which hopefully will occur in
Update.2!).
 --scott

-- 
                         ( http://cscott.net/ )