On 5/28/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:

If you haven't already, you could check out:

Also: PIL.ImageDraw http://www.esrf.fr/computing/bliss/python2/pil/PIL.ImageDraw.html http://www.pythonware.com/library/pil/handbook/imagedraw.htm "The ImageDraw module provide simple 2D graphics for Image objects. You can use this module to create new images, annotate or retouch existing images, and to generate graphics on the fly for web use." Aggdraw http://effbot.org/zone/draw-agg.htm "The aggdraw module implements the basic WCK 2D Drawing Interface on top of the AGG library. This library provides high-quality drawing, with anti-aliasing and alpha compositing, while being fully compatible with the WCK renderer." Matplotlib http://matplotlib.sourceforge.net/ "matplotlib is a python 2D plotting library which produces publication quality figures in a variety of hardcopy formats and interactive environments across platforms. matplotlib can be used in python scripts, the python and ipython shell (ala matlab or mathematica), web application servers, and six graphical user interface toolkits." Kiva http://code.enthought.com/kiva/ "Kiva is a multi-platform DisplayPDF drawing engine that supports multiple output backends, including Windows, GTK, and Macintosh native windowing systems, a variety of raster image formats, PDF, and Postscript." DrawBot/NodeBox (OS X only, but useful as examples of simple 2D systems) http://drawbot.com/index.html http://nodebox.net/manual/reference/topics.php "DrawBot is an powerful, free application for MacOSX that invites you to write simple Python scripts to generate two-dimensional graphics. The builtin graphics primitives support rectangles, ovals, (bezier) paths, polygons, text objects and transparency." PyCairo http://cairographics.org/pycairo "Cairo is a library for drawing vector graphics. Vector graphics are interesting because when they appear on screen, they don't lose clarity when resized or transformed." --Dethe

Paul D. Fernhout wrote:

Just a thought: rather than a new GUI implementation, improving the Python GUI FAQ with lots of this information and pros and cons and so on might be a very valuable effort just by itself. So much of choices depends on specifics and tiny details. For example, I'm fairly happy with wx, but there is this bug with dragging certain widgets under GTK 2.6. And of course, I also want platform independent fonts (and I'm not sure how to get those best, wx uses sizers to get platform independent dialog looks, but the sizes may still vary across platforms). Maybe this 2D, 3D, and Python GUI efforts needs a web site or blog or something? Some place where the nitty gritty details gets hashed out? Might be one already? Kind of like this one for programming languages? http://lambda-the-ultimate.org/ But specific to Python and graphics and user interaction? http://www.google.com/search?hl=en&q=python+graphics Might be something to think about if it does not already exist.

To answer part of my question, there was a Python GUI sig but it got retired in 1999. And I can't access the archives for some reason (when I wanted to see why): http://www.python.org/community/sigs/retired/gui-sig/ The link: http://mail.python.org/pipermail/gui-sig/ goes to: "The requested URL /pipermail/gui-sig/ was not found on this server." There is the ongoing Python Image Processign SIG http://www.python.org/community/sigs/current/image-sig/ though I had thought that was more oriented around the specific PIL package. It seems to me that graphics are a powerful way to show people something in terms of education, as well as a powerful way for kids to learn about themselves through visualization, so having all these choices made neat and tidy on a web site (or log kept up to date) for beginners or educators who want to make software seems like a good thing. Presumably the demise of Gui-sig suggests it is hard to keep up that sustained level of interest? But I know I see questions on this on the Python mailing list (i.e. what GUI should I use) all the time. Before this question was asked here, I had never really thought about how many options for Python and graphics and GUIs there really are -- dozens it seems. So, clearly any sort of effort put in this direction (including the original poster's plan to make simple wrapper) is going to be in the right direction. --Paul Fernhout

Dethe- Thanks for these other links and comments (especially on wx). Putting all the dozens of options together, I definitely think PyCairo makes a lot of sense because it has been adopted under Linux for GTK (and for Mozilla), so it almost certainly has a future, and would make a solid choice for the library of drawing my own cross-platform widgets, and would avoid me even wanting to write a cross-platform compatibility layer because I could just use it as is (which relates to the original poster's question, although in their case I can still see the point to a simplifying wrapper for education, though less so the need to have multiple back ends). However, there is an ancient Chinese proverb that when confronted with making a decision between 100 different alternatives(*), the best choice is always to "Run Away!". :-) So, along those lines, I decided to start using TK again (used in the first PataPata proof of concept) for several reasons including mostly it is the Python default. I am trying to use its widgets rather than draw my own, and ignore cross-platform font problems, speed issues, bitmap drawing issues, and so on for now. I wanted something to give me some fast progress on the HyperCard/widget front, and at least now I can drag TK buttons now under GTK 2.6 with proper feedback. Though who knows what else will be broken or missing -- I already had to borrow Idle's tree widget. :-) I am also stuck with the tk canvas for drawing (until I understand how PIL works? Or until PyCairo can render to a TK Canvas or Frame?) Also on the plus side, OpenGL should then be available through togl (though I have not tried that, looks like it may no longer be supported?). Still liking wx for general stand-alone applications though. :-) The funny thing is, since PataPata is its own Squeak-like beast, the TK widgets actually look kind of funky and retro in it. :-) 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? --Paul Fernhout (*) Or a nasty rabbit with long sharp pointy teeth. Dethe Elza wrote:

"The full set of Ginsu 2D interfaces for only $9.95 a month? But wait, there's more..."

Mirra http://www.ixi-software.net/content/body_software_mirra.html "Mirra is a 2D openGL python library. It defines a set of classes to render primitive shapes (Text, Pixel, Line, Circle, Rect, Bitmap, BitmaPolygon) and manages rendering and user input (mouse and keyboard). Mirra focuses on interaction and implements an event listener and classes that receive mouse events. (in a way like macromedia director or flash do). It runs using pygame(SDL) but it can also be used under wxPython. Mirra is also thought to teach students (basically design and multimedia students) programming in python by playing around with graphics."

SVGDraw http://www2.sfk.nl/svg Create SVG (XML for 2D) images using Python.

...

My head is spinning. :-)

Just wait till we delve into 3D %-)

...

Just a thought: rather than a new GUI implementation, improving the Python GUI FAQ with lots of this information and pros and cons and so on might be a very valuable effort just by itself.

I think this is an excellent idea.

...

So much of choices depends on specifics and tiny details. For example, I'm fairly happy with wx, but there is this bug with dragging certain widgets under GTK 2.6.

I haven't used wx for some time, but when I did it a) sucked on OS X, and b) seemed to be a random mix of reasonably polished widgets and half-baked crap that would be as useful as writing your resume in crayon. It also suffers from being huge and very Windows-focused. I can understand using it on Windows (beats using MFC, but so does hitting yourself with a ball-peen hammer), but I think it goes downhill as you move to Linux and drops off the cliff when you go to OS X. Just my impression, though I've seen the same feelings expressed elsewhere. I'd sooner use PyGame, and PyGame sucks for general UI/event handling (by itself, there are libraries on top of PyGame which help).

Of all the systems, I think PyCairo has the most momentum (and also has OpenGL hardware acceleration). Mozilla and GTK are both moving to Cairo, so it's getting lots of real-world use, profiling, bug-fixing, and speed-ups. This makes it a bit of a moving target, but the APIs should be fairly stable even though the implementation is in flux.

Caveat emptor. I haven't spent a lot of time with any of these (on the Mac I can access Quartz from Python, which works for me). I'm planning to explore further for an article or blog at some point, but any recommendations I make at this point have to be taken with a huge grain of salt.

And of

...

course, I also want platform independent fonts (and I'm not sure how to get those best, wx uses sizers to get platform independent dialog looks, but the sizes may still vary across platforms). Maybe this 2D, 3D, and Python GUI efforts needs a web site or blog or something? Some place where the nitty gritty details gets hashed out? Might be one already? Kind of like this one for programming languages? http://lambda-the-ultimate.org/

Maybe just the Python Wiki? http://wiki.python.org/moin/

...

But specific to Python and graphics and user interaction? http://www.google.com/search?hl=en&q=python+graphics Might be something to think about if it does not already exist.

--Paul Fernhout

--Dethe

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@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é

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@kurtz-fernhout.com <mailto:pdfernhout@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@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@luc.edu Chicago, Illinois 60611