[Edu-sig] Elementary graphics library

[Paul D. Fernhout]

Oh right, sorry, I'd lost sight of the fact it was in a web browser.
I've been wrestling with related issues for PataPata in choosing a 
specific graphics library or creating a simplified cross-platform display 
context, so I am a little mixed up here.

Still, just to show it can be done in theory (doesn't mean it's worth 
doing of course :-) see:
   http://mail.python.org/pipermail/image-sig/2003-July/002332.html
Evidently, you can convert a TK canvas to postscript, and then postscript 
to something else with another tool (e.g. Ghostscript), though no one 
replied to the question directly of how to make a PNG easily. Or you can 
grab pixels off the screen.

And for Ruby, you can do it:
   http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/63279
"If your Tcl/Tk supports it and your Ruby/Tk links such Tcl/Tk,
probably you can use the following line.
ph = TkPhotoImage.new('format'=>'window', 'data'=>canvas_widget_path)"
Though that solution may depend on platform availability.

In either case, I'm not sure if you can draw to a TK canvas without having 
the canvas widget displayed somewhere (which might be doable on a web 
server in theory, but would be tricky in practice). So, Cairo is a good 
approach for a web app and can easily do that without a GUI as the sample 
code shows:
   http://cairographics.org/pycairo

=== on Cairo as the choice ===

I'm definitely getting the warm fuzzies about Cairo given that, as Dethe 
says, both Mozilla and GTK have adopted it.

In which case, I will elaborate my earlier comment on one proposed design 
goal here at
   http://crunchy.python-hosting.com/wiki/GraphicsDoc
of:
   "The library is designed to be simple, easily extensible, and work with 
different back end rendering engines."
I'd like to raise the issue of whether to try to make a new cross-platform 
context, or whether to just commit to Cairo as being cross platform enough 
(maybe with just a minor wrapper for Cairo if you wanted something simpler).

On that point, I'm just trying to get at the notion that if a 
cross-platform toolkit like Cairo exists (since TK is at best awkward as 
another cross-platform choice), then perhaps having another cross-platform 
layer on top of that starts to be questionable as part of the goal, since 
it would seem that it might add to the complexity of developing the code 
with an extra layer of indirection. I agree, multiple back ends sound nice 
in theory, I'm just wondering if in practice it is worth the effort given 
a cross-platform choice exists (I'm wrestling with the same issue with 
PataPata).

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. 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. 
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. 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. Sure, other languages have their uses, but Python 
can get you pretty far and then still be useful (as glue).

In this case, because I guess it would probably be so easy to either just 
subclass or write a few functions for a Cairo context otherwise, it 
becomes a design goal issue of, "Is it more important to *potentially* 
support multiple backends for a simple display context, or is it more 
important to provide a display context that is easy to use and yet does 
not limit a kid's imagination and possibilities once they get started with 
it (assuming it runs on the platform they have access to)?".

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?

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. And, that selection of 
libraries features in my next post (on PySqueak/PataPata). That level of 
standardization might be a pipe dream of course, but still, as an edusig 
community, having a set of technologies like those as commonly recommended 
ones for intro Python programmers might still be of great benefit (when 
going beyond the command line or text handling). Right now, if I'm going 
to write educational software for Python, the only thing I can count on 
easily being installable cross-platform is TK/Tkinter. And if we are 
agreeing that is not a good enough solution (say, for web graphics as in 
this case), then it seems to me it would be nice to push along a good set 
of emerging standards rather than spend a lot of time writing all sorts of 
extra abstraction layers to support lots of libraries. I mean sure, if you 
have a commercial product, fine, support everything, but time is so 
limited for these things, that having just one good library choice which 
is a "no brainer" in each area of interest in learning GUI&graphics with 
Python (widgets, 2D, 3D) can save a lot of time and painful searching. So, 
maybe this is a variant of, if TK is not good enough anymore as a standard 
given the things people want to do with Python and how they want them to 
look, then what's next? An "EasyCairo" display context for Python which is 
made popular might be an important part of that push.

Anyway, just my two cents. :-)

--Paul Fernhout

Andre Roberge wrote:
> On 6/1/06, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
>> Amazing how much of these decisions often hinge on easy installability 
>> and
>> ready availability. So, as another comment for the original poster, 
>> can TK
>> as a backend meet the basic graphics operations desired?
>>
> Doubtful, since Johannes's intent is to render graphics in a web browser,
> 
> not in a separate window.
> 
> André