[OLPC-Games] Embedding pygame in gtk.

[Mike C. Fletcher]

C. Scott Ananian wrote:
> On Dec 24, 2007 11:11 PM, Mike C. Fletcher <mcfletch at vrplumber.com> wrote:
>   
>> Note that you should not be using a 1200x900 Pygame size when you are on
>> an OLPC if you are including a standard toolbar, as you will wind up
>> with some of your Pygame window cut off by the bottom of the screen.
>>     
>
> However, if you use 1200x900, then the 'Alt-Enter' shortcut for
> running full-screen does work, which is nice.
>   
Fair enough.  I suppose it's a trade-off you can make.  The shortcut
doesn't work in my jhbuild, incidentally.
>> BTW, why can't Pippy handle .xo files or dev directories?  Seems like a
>> fairly straightforward bit of functionality and would get away from
>> trying to shoehorn every activity into a single file.
>>     
>
> Pippy is deliberately supposed to be the 'most simple' introduction to
> programming; by not attempting to be a full IDE it has managed to
> actually exist, unlike Develop.  Handling multiple files increases the
> complexity of the UI by quite a large amount.
>   
I'm happy it exists.  Obviously there *are* activities which are
comparatively simple and straightforward, a simple wrapper around a
control, a game with comparatively trivial rules, utilities to do a
single, simple thing.

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.
>>  I can't say I've
>> ever seen a "real" Pygame game that was written all in a single file
>> with no resources required at all.  Pygame is all about raster graphics,
>> and that *normally* means bitmap files that need to be carried along
>> with the code.
>>     
>
> True enough.  But there are already several Pygame application written
> in Pippy (CJB's slide show program, a simple pong, etc) which can live
> quite happily within Pippy's limitations.
>   
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.

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.

While I'm hesitant to add code that only edits the "main" file of an
activity it would not be difficult to do.  I'd be more comfortable with
hooking up a show-code button to something that would *eventually* be
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.  That said, if we only hook up an entry point "view source",
and temporarily make it do the pippy-specific save-a-single-file, with
the goal of eventually having something that can handle an xo or
directory, that seems like a path forward.

We still have a bug/feature request where setting the size via
display.set_mode() doesn't propagate to the socket window, but other
than that the code should be quite straightforward to produce a new
OLPCGames-based activity from your Pippy activities (i.e. we have a
command-line tool that produces such activities from regular Pygame
games).  The pausescreen code would need to change (we use a slightly
different version that shouldn't require localization of the same string
in every activity that uses it (and allows for overriding the pausing
behaviour).  The code there is derived from Pippy's, but is refactored
to be usable in larger projects.
>> Also, Pippy should probably not be storing activities using "friendly"
>> names.  To do that it will often have to (ask the journal to) overwrite
>> an existing friendly-name version of the activity.  Most of the time
>> during development your copy of the activity will be borked, but you
>> still want access to the original version.  The obvious solution would
>> be to teach Sugar and the Journal to allow for versioned directories
>> named as a dotted version of the base version (and dotted of the dotted
>> if you branch from an unstable release)... or better yet, use a .bzr
>> repository stored along with the directory that contains the whole
>> development tree, downloading it from upstream on first edit of the
>> repository (or maybe just doing a local repository, space considerations
>> and all that).
>>     
>
> 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.

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.

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.

Peace out,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com