[sugar] Develop Activity

[Ian Bicking]

Andrew Clunis wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tue, Dec 19, 2006 at 08:41:12AM -0800, Alan Kay wrote:
>> Hi Andrew --
>>
>> I guess I agree with what you say about Python and its structure, but 
>> I was thinking much more about what the children see, not so much the 
>> developers.
> 
> That brings up another problem.  I myself was a child not so long ago,
> and as I started to become interested in computer programming and
> software development, it was important to me that I was "on the same
> level" as all other desktop application developers (I admit that I was
> a bit of a weirdo, though).

I think there might be room for two kinds of development environments; 
one that is proper Python, directories, etc, and one that is more 
constrained.  This goes against the "same level" idea, but I don't know 
if everyone will mind so much.

The idea then would be that someone (more experience) would set up the 
framework of an activity.  The child would edit just a few files, 
ideally just one file.  There might even be some constraints in how the 
module could be set up -- e.g., no fancy module-level execution to make 
the module hard to reload.

Here's a use case:

Writing chat bots is fun.  The basic code is pretty clear -- you start 
up a chat session with a user, and messages come in and responses go 
out.  Clearly there's more to it, but this is all the child is 
interested in, and all the child needs to be interested in.

The Chat Bot Activity Factory Activity creates a new activity.  There's 
one file, "chatbot.py", that the child edits.  It contains the basic 
framework:

from chatsession import ChatSession

class Session(ChatSession):
     def respond(self):
         return 'Hello '+self.buddy.name


And maybe it has some other methods (maybe just no-op methods that can 
be usefully extended or changed), plus some docstrings to help the child 
figure out what's going on.

The child really has a lot of freedom from here.  They can connect to 
websites, do calculations, maybe read things from the journal, whatever. 
  But they don't have to think too much about what goes into making a 
chat bot, and they can get very immediate results from their work.

This could actually apply to anything, really; this could be part of the 
development environment as a whole.  Now that I think about it, it 
doesn't seem to hard.  You just need a Activity Factory Activity, and 
some metadata about the resulting activity to help guide children 
through the first parts of development.

One example would set up a Sugar GUI activity.  It would create all the 
basic files, the main loop, etc.  It would contain enough so that you 
could start the resulting activity and see something.  It would also 
have some metadata telling the Develop activity where the child can 
start work.  The generated files can inline documentation.  (In what 
language?  That's the kicker -- anyway, we can localize the docstrings, 
even if we can't really localize the API itself)

It's also possible that other languages could be supported; e.g., Logo 
through PyLogo.  It doesn't give you the full power of Python (e.g., OO 
stuff is hard to do through PyLogo), but it gives you a lot, and could 
potentially be localized in a way that Python could not.  Anyway, while 
that's not an appropriate language for an entirely activity (for 
instance, it's very slow), it can be appropriate for extending 
appropriately constrained portions of the activity.

Of course, then there's the notion of plugins.  If you write one chat 
bot program, do you need to have children fork it and extend, or can 
they just extend the activity directly given stable and public extension 
points?  So far Activities lack any notion of plugins in this style, 
except perhaps through dbus (which is still too vague by itself, and 
would need to be expanded upon).



-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org