[Edu-sig] Elementary graphics library

Andre Roberge andre.roberge at gmail.com
Sat Jun 3 02:01:37 CEST 2006

On 6/2/06, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
> Oh right, sorry, I'd lost sight of the fact it was in a web browser.

No problem, this thread is full of interesting meanderings.


> If Johannes commits to Cairo (at least, for now), it seems he could just
> subclass the context, add a few convenience methods to make triangles or
> do a turtle and such, and you then have something that is easy to use and
> *still* powerful.

Good point.

So, from an eXtreme programming point of view (i.e.
> "don't write code or add complexity before you are sure you'll need it"),
> I'd suggest then either just go with Cairo as an expected part of the
> system, or at most just make a thin simplified wrapper around Cairo, and
> if later there is a demand for other back ends, then add the layer then.

(Speaking on his behalf, until he comments on his own :-) That is what he
wanted to do. However, when trying to design a "library" that could be used
by 7 year-old kids ... I think he found out that it was not as easy as he
first thought.  For example: how do you introduce cartesian coordinates (for
positioning graphics objects) in a simple way?

Any suggestion for what the API should look like would be most welcome!

And with the 100% Cairo approach, then the comment  "There is no way it
> should be used for real world graphics - its sole purpose is educational."
> would no longer be needed.

I could not agree more with this approach (see below).

Kids would start off with this, say,
> "EasyCairo" context they can do some simple things with easily, and then,
> if they get curious, suddenly they could find themselves drawing warped
> text as quick speeds, when they realize it has inherited methods they
> could use. Or, not having looked at the implementation of pyCairo, if for
> some reason it could not be subclasses, one cold write a wrapper object or
> even just plain convenience functions that took it as an argument.
> I think there is a subtle point here about educational philosophy I can't
> quite put into words. Maybe it is something like, "Making real tools
> easier and safer to use so people can learn to do simple things with them
> more quickly is good (e.g. convenience functions for Cairo to draw
> circles); making "educational" tools that people can only do simple things
> with and then hit an artificial ceiling with and then get frustrated about
> as then need to move onto something else is bad (e.g. an entirely new
> display context you can only draw a few things with)."?
> And I think "Python" as a learning environment reflects that point. It is
> easy to start using Python, but unlike an "educational" version of, say,
> Logo or Basic doesn't force you to jump ship when the going gets tough, or
> when you design you want to use something to get real work done with. And
> I think that is why it is one of the best choices for people first
> learning programming.

Indeed.  And, if I may use it as an example, I think this is one of the
strength of RUR-PLE in comparison with Guido van Robot (or Logo, or whatever
else.)  RUR-PLE is Python ... with a few pre-defined commands.  In fact,
executing a RUR-PLE program is done via something like
exec "user_code" in my_globals()

I do some minor pre-processing of the "user_code" part to disallow import
statements and a few others (for security reason in a classroom environment,
to prevent kids sharing "dangerous" programs), but pretty much any valid
Python code can be executed!


> So anyway, looking back at Johannes' original proposal,
>    http://users.ox.ac.uk/~orie1763/coder-python.pdf
> it seems to me that just making Cairo a little easier to use would still
> fulfill the intent there (including being cross-platform enough), while
> not creating any artificial limits on what kids could do. Installation and
> availability still may be an issue, of course, but long term, won't that
> be solved for Cairo if Mozilla and GTK use it?

Agreed on both points.

Still, I should admit to being a little self-serving with my argument
> here; if Python educators got behind a good cross-platform standards like,
> say, Cairo, and GTK, and pygtkglext (for OpenGL), and it got bundled into
> the main CPython distribution in the future
>    http://wiki.python.org/moin/PythonThreeDotOh
> (or at least as an easy add-on package for Mac, Win, and GNU/Linux), then
> I think there would be enormous value for Python in education to have a
> solid GUI, 2D, and 3D display engines which everyone could count on for
> being available when introducing people to Python.

I don't consider that having such a library is a self-serving goal :-)
However, I am not hopeful that it will get bundled in the main Python
distribution.  I'll settle for an easy download (and, hopefully, for it to
be part of Edubuntu).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060602/46b2abcc/attachment-0001.html 

More information about the Edu-sig mailing list