[Edu-sig] Elementary graphics library

Andrew Harrington aharrin at luc.edu
Sat Jun 3 05:27:19 CEST 2006


I am not a great follower of the graphic wars, but I agree with both 
Andre and Paul from what I have seen. 

We are talking here about a basic issue with open source infrastructure 
(and commercial standards for that matter).  Is it worth it doing my 
thing my way that only some will be able to use, or give up something, 
time at least for now, and agree on a standard?  There is the separate 
issue in Python of what goes in the standard distribution or in edubuntu 
for that matter.

If there is real agreement, ongoing support is more likely to follow, 
but big players supporting a good looking emerging standard like Cairo 
certainly does not hurt.  Think now about the money for wxPython, which 
has been coming from Mitch Kapor's OSAF.  If his Chandler project is 
thinking of dropping wx, that is not only an issue about how good wx is 
as a general system, but where is the support going to come from in the 
future....

In the Windows world in particular, easy installation is a big deal.  
That is what the user base is expecting.  I was just reading a rave 
review of the new Ubutu release by someone who only needed to give 
about100 line of commands and instructions for what 10-15 places to 
insert them so the Ubuntu version would actually work well on his 
system.  This was supposed to be good enough to attract Windows users.  
In what universe?

Andy
 
Andre Roberge wrote:

> On 6/2/06, *Paul D. Fernhout* <pdfernhout at kurtz-fernhout.com 
> <mailto: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.
>
> [snip]
>
>
>     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!
>
> [snip]
>
>
>     So anyway, looking back at Johannes' original proposal,
>        http://users.ox.ac.uk/~orie1763/coder-python.pdf
>     <http://users.ox.ac.uk/%7Eorie1763/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). 
>  
> André
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig
>  
>


-- 
  Andrew N. Harrington
  Computer Science Department      Undergraduate Program Director
  Loyola University Chicago        http://www.cs.luc.edu/~anh
  512B Lewis Towers (office)       Office Phone: 312-915-7982
  Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
  820 North Michigan Avenue        aharrin at luc.edu
  Chicago, Illinois 60611          



More information about the Edu-sig mailing list