[Edu-sig] Elementary graphics library
Paul D. Fernhout
pdfernhout at kurtz-fernhout.com
Sat Jun 3 00:52:51 CEST 2006
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:
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:
"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
=== 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
"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
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,
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
(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. :-)
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
>> 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.
More information about the Edu-sig