PySqueak: pyGTK & Cairo & pygtkglext (OpenGL) next?
Short version: Would people here be willing to install PyGTK 2.x and pygtkglext (OpenGL on GTK) and related files on their machines *if* there was a Python-based software package they *really* wanted to use? Mac and Windows are of issue mainly, since GNU/Linux probably is probably trivial install. Does anyone under Mac or Windows have happy experience doing that for either PyGTK or the 3D extension pygtkglext (either in a home or a lab setting Long version: While exploring the issue of restricted evaluation environments (I am considering having PataPata windows communicate by passing textual Python programs :-) I came across this on Python 3.0 wish list: http://wiki.python.org/moin/PythonThreeDotOh "Include wxPython or PyGtk in core library [for Py3K]? Would anygui also be a good option. Place Tkinter into legacy status? (Musing again. Seems like we need a more mainstream, higher performance standard GUI in the core distribution. wxPython is very popular, so I suggested it as an option. The PyGtk is an awesomely thin layer over the C library and it makes Gtk objects look like native Python classes.)" Now given the wx bashing lately (including from the OSI Chandler project I linked to), and the Cairo blessing(?), that PyGTK comment got me thinking. Also, Francois mentions somewhere he wanted to move beyond TK for his work. Well, I just implemented a rudimentary TK proof-of-concept version of PataPata. And the inspector is live in the world. And I am not as dissatisfied with the look or performance of TK as I thought I would. [Though of course it still needs more work.(*)] BUT, I read that, and the squeaky gears in my brain start creaking, thinking, "hmmm, Python2.x, GTK, and Cairo?". And after a Google, this link has me pretty excited: Writing a Widget Using Cairo and PyGTK 2.8 http://www.pygtk.org/articles/cairo-pygtk-widgets/cairo-pygtk-widgets.htm and so I tried the file there and it ran on my Debian machine without needing to install anything (though I have in the past installed lots of stuff, so I don't know about stock distributions of Debian Python, but clearly this support is just an apt-get away apparently, at least as far as Cairo). From the link: "Cairo is a powerful 2-dimensional graphics library designed to support a number of modern graphics techniques including stroking, alpha blending and antialiasing. It supports multiple output formats, which allows developers to use the same code to display graphics on the screen, print them to the printer or accelerate them with OpenGL. As of GTK+ 2.8, GTK+ has been integrated with the Cairo 1.0 rendering library, giving developers access to this flexible graphics API. PyGTK added Cairo support in the 2.8 version. See the wiki for further info." There is also PyGtkGLExt for Python 3D OpenGL support (though I have not tried it): http://gtkglext.sourceforge.net/ Example Python 3D program: http://mail.gnome.org/archives/gtkglext-list/2004-April/msg00012.html I really like the idea of using something like Cairo if it is picking up steam (see my previous post in "Elementary Graphics Library"). And 3D support sounds good too (rather than the TK developers leaving behind TK's togl :-( ). As I reflect on it, I am also willing to trade-off 90% of popularity for PataPata right now in terms of easy install for Mac/Windows *if* it would make my life under Debian easier to get something neat working that I and a few others want to use, and has the promise of picking up easy install in a couple of years (like if Python3K went with pyGTK as a default). Plus I already have wx and tk versions, so it's not like people could not try the basic idea on those platforms. The issue is more a matter of where I shoudl be putting more energy, since if I could use GTK and Cairo and PyGtkGLExt for cross-platform widgets, 2D graphics, and 3D graphics, then long-term it makes it easier for me to maintain a system using common cross-platform standards, especially because I don't have to put in much of an extra dumbed down "compatibility" layer. For example, I can just pass GTK events around rather than translate them to my own; I can use Cairo calls rather than my own simplified 2D context; I can assume everyone is using the same way to access 3D graphics rather than try to abstract initialization out; and so on. Now, this compatibility issue is a bit more complex, because I would like to run PataPata things as applets on Jython, but I'm not sure that is important enough at the start to prevent using an otherwise promising cross-platform solution CPython works with, given that I'm not sure how important Applets really are, and in the future there might be more person-power to make some GUI object wrappers that runs both on GTK and Swing. Obviously, I could search the PyGTK and gtkglext list archives: http://www.daa.com.au/mailman/listinfo/pygtk http://mail.gnome.org/mailman/listinfo/gtkglext-list/ but I was curious what people here had to say from an educator context. There are also other cool software projects like PythonCAD that use PyGTK: http://www.pythoncad.org/ It woudl be more work to switch yet again, but I find just about anything can be made right if you are willing to start over a couple of times. :-) Or, in short, having done the sensible thing of deciding to "Run away!" to TK when faced with all the choices in the "Elementary graphics library" thread, I'm wondering now whether the "Holy Hand Grenade" sacred relic Brother GTK Maynard from Cairo carries: http://en.wikipedia.org/wiki/Holy_Hand_Grenade_of_Antioch could get the PataPata entourage safely past the killer rabbit of cross-platform issues. :-) I'm certainly not the only one asking that question right around now: http://www.myddrin.com/trashdeerwood/index.cgi/Development/67 http://wiki.osafoundation.org/bin/view/Jungle/TechnologyChoices I've looked in the edusig list's archive and pyGTK is mentioned in about 30 posts over about six thread. Dave Reed on 12/26/2004 05:30 PM was very encouraging of is a year and a half ago. http://mail.python.org/pipermail/edu-sig/2004-December/004302.html He wrote: "I've used it on Linux/Solaris, Windows XP and Mac OS X and it works fine on all of them. If I was coding for Windows only, I'd probably pick a different widget set, but since I have little interest in programming for Windows right now, I think glade/gtk is a great combination." So it seems like by now it should be a fairly safe choice? So, my question to educators or parents here using Mac and Windows is, are you willing to go to the trouble (or have you already?) to make sure PyGTK and a >= 2.8 GTK are running on your system at school or at home *if* there was an application you really wanted to use? Would using PyGTK & PyCairo & pygtkglext be more a show stopper or an incentive? I'm not saying you would do it right now, just more, would you or could you do it if you really wanted to? If so, or if there is at least a sense that it is possible, I think I will be very tempted to (once again) make another version of PataPata (PySqueak) that is GTK oriented. I've never tried to use PyGTK on the Mac or Windows, so any feedback on it's current use in an educational context of for packages you use for other things would be appreciated (i.e. do you already use packages that depend on PyGTK?) --Paul Fernhout (*) The TK version still has a bug retrieving text from a multi-line TK text box. And everything is sloppily floating around. And no save/load world buttons yet.
Paul, From a Mac user's perspective I think the answer is probably not. This approach would put PySqueak on a similar trajectory as vpython which requires us to use X11 on the mac in order to get GTK and friends working. Further, this arrangement forces us to make separate builds of python using fink or darwin ports, which in turn gives us two separate python installations on our Macs. Several have tried to port vpython to a native (non-X11-dependent) implementation on the mac over the last few years but nobody has succeeded yet. There is some work in GTK+ 2.9.x to get a native port of GTK working on the mac. Maybe when this effort is finally successful then native versions of vpython and other packages will be easier. So, personally I would be sad to see PySqueak head down this road. But I also think that the effort required to get everything working under X11 would be too difficult for many beginners. Brad On Jun 2, 2006, at 6:00 PM, Paul D. Fernhout wrote:
Short version:
Would people here be willing to install PyGTK 2.x and pygtkglext (OpenGL on GTK) and related files on their machines *if* there was a Python- based software package they *really* wanted to use? Mac and Windows are of issue mainly, since GNU/Linux probably is probably trivial install. Does anyone under Mac or Windows have happy experience doing that for either PyGTK or the 3D extension pygtkglext (either in a home or a lab setting
Long version:
While exploring the issue of restricted evaluation environments (I am considering having PataPata windows communicate by passing textual Python programs :-) I came across this on Python 3.0 wish list: http://wiki.python.org/moin/PythonThreeDotOh "Include wxPython or PyGtk in core library [for Py3K]? Would anygui also be a good option. Place Tkinter into legacy status? (Musing again. Seems like we need a more mainstream, higher performance standard GUI in the core distribution. wxPython is very popular, so I suggested it as an option. The PyGtk is an awesomely thin layer over the C library and it makes Gtk objects look like native Python classes.)"
Now given the wx bashing lately (including from the OSI Chandler project I linked to), and the Cairo blessing(?), that PyGTK comment got me thinking. Also, Francois mentions somewhere he wanted to move beyond TK for his work.
Well, I just implemented a rudimentary TK proof-of-concept version of PataPata. And the inspector is live in the world. And I am not as dissatisfied with the look or performance of TK as I thought I would. [Though of course it still needs more work.(*)] BUT, I read that, and the squeaky gears in my brain start creaking, thinking, "hmmm, Python2.x, GTK, and Cairo?".
And after a Google, this link has me pretty excited: Writing a Widget Using Cairo and PyGTK 2.8 http://www.pygtk.org/articles/cairo-pygtk-widgets/cairo-pygtk- widgets.htm and so I tried the file there and it ran on my Debian machine without needing to install anything (though I have in the past installed lots of stuff, so I don't know about stock distributions of Debian Python, but clearly this support is just an apt-get away apparently, at least as far as Cairo).
From the link: "Cairo is a powerful 2-dimensional graphics library designed to support a number of modern graphics techniques including stroking, alpha blending and antialiasing. It supports multiple output formats, which allows developers to use the same code to display graphics on the screen, print them to the printer or accelerate them with OpenGL. As of GTK+ 2.8, GTK+ has been integrated with the Cairo 1.0 rendering library, giving developers access to this flexible graphics API. PyGTK added Cairo support in the 2.8 version. See the wiki for further info."
There is also PyGtkGLExt for Python 3D OpenGL support (though I have not tried it): http://gtkglext.sourceforge.net/ Example Python 3D program: http://mail.gnome.org/archives/gtkglext-list/2004-April/ msg00012.html
I really like the idea of using something like Cairo if it is picking up steam (see my previous post in "Elementary Graphics Library"). And 3D support sounds good too (rather than the TK developers leaving behind TK's togl :-( ). As I reflect on it, I am also willing to trade-off 90% of popularity for PataPata right now in terms of easy install for Mac/ Windows *if* it would make my life under Debian easier to get something neat working that I and a few others want to use, and has the promise of picking up easy install in a couple of years (like if Python3K went with pyGTK as a default). Plus I already have wx and tk versions, so it's not like people could not try the basic idea on those platforms.
The issue is more a matter of where I shoudl be putting more energy, since if I could use GTK and Cairo and PyGtkGLExt for cross-platform widgets, 2D graphics, and 3D graphics, then long-term it makes it easier for me to maintain a system using common cross-platform standards, especially because I don't have to put in much of an extra dumbed down "compatibility" layer. For example, I can just pass GTK events around rather than translate them to my own; I can use Cairo calls rather than my own simplified 2D context; I can assume everyone is using the same way to access 3D graphics rather than try to abstract initialization out; and so on. Now, this compatibility issue is a bit more complex, because I would like to run PataPata things as applets on Jython, but I'm not sure that is important enough at the start to prevent using an otherwise promising cross-platform solution CPython works with, given that I'm not sure how important Applets really are, and in the future there might be more person-power to make some GUI object wrappers that runs both on GTK and Swing.
Obviously, I could search the PyGTK and gtkglext list archives: http://www.daa.com.au/mailman/listinfo/pygtk http://mail.gnome.org/mailman/listinfo/gtkglext-list/ but I was curious what people here had to say from an educator context. There are also other cool software projects like PythonCAD that use PyGTK: http://www.pythoncad.org/
It woudl be more work to switch yet again, but I find just about anything can be made right if you are willing to start over a couple of times. :-) Or, in short, having done the sensible thing of deciding to "Run away!" to TK when faced with all the choices in the "Elementary graphics library" thread, I'm wondering now whether the "Holy Hand Grenade" sacred relic Brother GTK Maynard from Cairo carries: http://en.wikipedia.org/wiki/Holy_Hand_Grenade_of_Antioch could get the PataPata entourage safely past the killer rabbit of cross-platform issues. :-)
I'm certainly not the only one asking that question right around now: http://www.myddrin.com/trashdeerwood/index.cgi/Development/67 http://wiki.osafoundation.org/bin/view/Jungle/TechnologyChoices
I've looked in the edusig list's archive and pyGTK is mentioned in about 30 posts over about six thread. Dave Reed on 12/26/2004 05:30 PM was very encouraging of is a year and a half ago. http://mail.python.org/pipermail/edu-sig/2004-December/004302.html He wrote: "I've used it on Linux/Solaris, Windows XP and Mac OS X and it works fine on all of them. If I was coding for Windows only, I'd probably pick a different widget set, but since I have little interest in programming for Windows right now, I think glade/gtk is a great combination." So it seems like by now it should be a fairly safe choice?
So, my question to educators or parents here using Mac and Windows is, are you willing to go to the trouble (or have you already?) to make sure PyGTK and a >= 2.8 GTK are running on your system at school or at home *if* there was an application you really wanted to use? Would using PyGTK & PyCairo & pygtkglext be more a show stopper or an incentive? I'm not saying you would do it right now, just more, would you or could you do it if you really wanted to? If so, or if there is at least a sense that it is possible, I think I will be very tempted to (once again) make another version of PataPata (PySqueak) that is GTK oriented. I've never tried to use PyGTK on the Mac or Windows, so any feedback on it's current use in an educational context of for packages you use for other things would be appreciated (i.e. do you already use packages that depend on PyGTK?)
--Paul Fernhout (*) The TK version still has a bug retrieving text from a multi- line TK text box. And everything is sloppily floating around. And no save/load world buttons yet. _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Brad- Thanks for the feedback. That's just what I like to hear even if it is negative. I'll be curious if other Mac users agree. Do you have any preferences for cross-platform Mac support (other than native Cocoa)? Are then either of wx or tk then more appealing from an easy installability stand point right now? Would good support for either of tk or wx then be your "vote"? Or would you (see below) also think Java (with Jython) is OK? And so wx, tk, or Java could all work for you on the mac? Any order of preference? I'd be especially curious if you think PyCairo by itself would have the same installation problems as pyGTK on the mac. Because if it was an easy install, then I could start thinking more on the issue of having a native Cocoa window with related event processing on the Mac, and a GTK one for GNU/Linux, and a something else (wx?) for Windows, but have the widgets draw in Cairo (sort of like Squeak does it, but with Cairo instead of Python bitmap handling). For now it sounds like I should stick with making progress on the TK front and solve as many issues as I can that don't entail too much commitment to a GUI while I continue to get more feedback on this. Here are some more musings on a few more alternatives, trying to emphasize a Mac perspective. === Jython and Java? ==== For me, the easiest Mac development platform that is also cross-platform with an easy install is probably going with Jython and Swing under Java. I've already done projects that way and they were fairly smooth. I like the technology, and even have hopes Sun will free Java one day (or that it won't matter at some point, with other free initiatives). Certainly Java, for good or bad, has made inroads into education, and even if I think the Java language itself has major design problems and limitations, the latest 1.5 JVM itself isn't that bad a platform for other things like Jython. The fact that PataPata under Java would not look completely Mac-like isn't that big an issue (as I see it) as it might be if I was making a plain application. But from a free software perspective, http://www.gnu.org/philosophy/java-trap.html Java has some issues, including installation problems for Java under GNU/Linux (though I'm still seeing how the recent Sun announcement plays out with Debian and free software developers). http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml [It is not without controversy.] Still, Jython 2.1 "just works" under most any JVM, and PataPata could go pretty far with just that (including delivering educational applets written in Python/Jython), even ignoring Jython advancements now under way (2.2 alpha). In that case it is the latest Mac users which I would guess are more likely to say "yes" to easy Java use (while holding their noses :-), Windows with a "maybe", but the GNU/Linux camp more likely to say "no" (historically Java doesn't come with GNU/Linux by default, though again, the Sun announcement is having an effect on those policies). Of course there are free Java versions, http://www.gnu.org/software/classpath/ http://www.kaffe.org/ and they might work well enough for my purposes, if I bundled the entire GNU Classpath and a JVM with the distribution (or as an optional 50MB or so "install this first if you have no working Java" package) or just pointed people at it with links. Also, while I can count on a Mac OS X user to have Java pre-installed, the same can't be said for Windows (the maybe). A Jython solution means I can just say, "well it works if you install Java". I don't really think performance will be effected or the software will be that limited by working with Java (other than the limits of Jython 2.1 [and evolving] vs. Python 2.4, though that includes things like not having twisted or Idlelib's rpc). Java even has various OpenGL interfaces (though I have not really used any of them). http://www.opengl.org/resources/java/ So, as a side issue, choosing to focus on Java hinges on if I could expect a lot of teachers in the computer lab or parents at home to have a recent (>= 1.4.2) JVM installed? Or be willing to install one? And I think the answer there is probably mostly "yes", since Java has made big inroads into education. Personally, I do like the idea of using CPython over Jython because it has the latest bells and whistles. And I know people can wrestle with Java issues often on install (though seem to accept that more than for, say, GTK :-) perhaps because they see a bigger win for getting Java to work). And I am leery of "the Java Trap". Still, Jython is a nice system, and I could see even hacking it for prototype performance more easily than CPython in some ways, since I have already studied some how it works under the hood and have a feeling about where I could intervene with how it does lookups for things. Since I would likely bundle Jython and related Python libs with any distribution (so I know what the end user is working with) it isn't that hard to just include a slightly modified Jython for performance in a jar file, whereas perhaps people are more likely to notice and get upset if I bundle in a new version of CPython? (And I would rather be modifying Jython than CPython, since Java is somewhat easier to work with than C.) So, maybe I should think harder about a Jython/Swing version of PataPata (at least as another proof of concept)? It certainly is more preferable to me to do a Jython/Java version with tools I know than to start thinking about doing a native Cocoa version and dealing with that learning curve (plus borrowing my wife's ibook and hunching over a tiny single screen. :-). === another alternative that might be more mac friendly -- GNUStep? === Dethe had suggested GNUStep http://www.gnustep.org/ in the edusig thread discussing PySqueak implementation ideas: http://mail.python.org/pipermail/edu-sig/2006-April/006190.html so maybe I should explore that idea more? From what I see, of the current popular cross-platform tools readily available and (tk, wx, qt, gtk, fox, some others), GNUStep seems like the most advanced in terms of underlying design and it might be the best single candidate if I wanted to have the best looking and most pain-free current Mac support with a cross-platform potential (other than Java)? I know pyGTK and friends is going to work well on GNU/Linux, and be easy to install and so forth, like with Ubuntu/Edbuntu. I know it supposedly will work under Windows and the Mac if you make the effort (though it is painful, especially compared to Java). For Windows, there is even a GTK# under dotNet. http://gtk-sharp.sourceforge.net/ Whereas, I am a little leery of GNUStep (as opposed to pure Mac Cocoa) not being a stable enough platform, especially on Windows, and especially as various new versions are rolled out which might be incompatible and so on. I'm not sure whether it is practical to bundle a GNUStep runtime with a frozen Python package the way, say, I can and have easily done with CPython and wx. I don't know enough about the GNUStep community to really know what I can count on or be confident will run where. In general, there do seem to be a lot of platforms supported by GNUStep. http://www.gnustep.org/resources/sources.html#windows because it is designed in a way to make it back-end neutral. And there is an experimental Cairo port as a backend: http://www.gatago.com/gnu/gnustep/discuss/13547347.html though I would expect you could still use Cairo in you app with GNUStep running on a better supported backend? And OpenGL support exists, though maybe not yet for Windows (here is a comment from a year ago)? http://www.aegidian.org/bb/viewtopic.php?t=664&sid=24191e4c94dcea80e2550886cec62226 Just looking at the web sites and comments about it, I kind of get the feeling stuff like Cairo or OpenGL is still in flux and stuff may or may not work everywhere (although when it does work, it is terrific). I have previously played with GNUStep on my Debian box, though I found it somewhat confusing GUI-wise and doing unexpected (buggy?) things (windows appearing and disappearing erratically, menus only showing up some places, dialogs on the wrong screen, and so on, though that might be in part because I have a three monitor setup and apps don't test for that?). Still, I feel like those could probably be overcome on the Mac and on GNU/Linux fairly readily (given Cocoa and GNUStep have a common OpenStep ancestor, http://wiki.gnustep.org/index.php/Cocoa and given that GNUStep being "GNU" it is probably going to have interested GNU/Linux developers). So, it is Windows that might be left out with that approach? Of course, one of GNUStep's claim to fame is easy change to GUIs , so PataPata isn't such a big win on that platform as it would be under Java or GTK or wx or tk. And, PataPata's approach might possibly conflict with some design principles of GNUStep. Also, the Google results for GnuStep and Python in a search: http://www.google.com/search?hl=en&lr=&q=GnuStep+Python leading mainly to: http://pyobjc.sourceforge.net/ "There is limited support for GNUstep, most of the unittests pass on GNUstep on Linux/ix86. However, we do still have some serious problems with real scripts." which doesn't inspire too much confidence for me that Python+GNUStep everywhere is a popular thing to do (as opposed to Python+Cocoa just on the Mac, which seems popular, e.g. Dethe uses it) or will be fairly painless to manage (whereas pyGTK for GTK with Python is all over the place, and seems to work well out of the box in my own limited testing). === some more general comments === So, GTK might still make more sense for my own early convenience of course if I wanted CPython with modern widgets, 2D, and 3D, with my crossing my fingers Mac versions get easier to install. :-) But I agree with you, that does not then sound like the best solution from today's Mac user's perspective. Surprisingly, I have been finding with now maintaining a wx and a tk version of PataPata that there is not quite as much difficulty as I expected with adding another platform's widgets. So, I could consider maybe keeping a current TK version for everyone and down the road having a GTK version for some fancy stuff which is a headache to install on Mac/Windows? (Assuming you think TK works well enough in practice on the Mac?) Or maybe even a GNUStep version? Or even one for Cocoa? It really isn't that hard to wrap some basic widgets it seems. The big issues with multi-platform support for multiple-widget sets is the multiplication of testing releases on multiple platforms (each of which can have numerous configurations, and versions of various libraries). I don't want to have to do that. Compared to that, there is less work involved to comprehensibly wrap all of a specific widget set, since it is just a one-time thing plus some debugging, and that can also be done incrementally as one decides to use each widget. This professor, Barry Schwartz, at Swarthmore http://www.swarthmore.edu/SocSci/bschwar1/ writes on: "The Paradox of Choice: Why More Is Less" http://www.amazon.com/gp/product/0060005688/103-3423194-6030260?v=glance&n=283155 and "The Tyranny of Freedom" http://www.swarthmore.edu/SocSci/bschwar1/self-determination.pdf about how having too many (mostly similar) choices actually makes people more unhappy and leads to inaction than having just a few good ones. Hopefully PataPata won't get too stuck in that, even though I am spinning my wheels in the cross-platform mud right now at the start. :-) I've been continuing work on the TK version right now, since between keeping current wx and tk it makes a nice challenge for me to get the code factored well (removing duplication), and there is still a lot to do that is not too GUI specific. I've got the tk code browser now working live inside the world (code in SVN, some significant limitations and bugs still though), though of course having the development tools live in the same world you are developing makes for the typical Squeak Smalltalk problem of how you can shoot yourself in the foot by, say, deleting the Inspector Morphs. After solving some other bugs, I hope to get two worlds communicating (one with the world of interest and one with an inspector) through a server, all of which should ideally be GUI neutral, though may impose other dependencies and install issues (like if I use twisted as opposed to Idle's rpc code or something custom). Some security issues to work out there, as ideally I want the worlds communicating by passing Python programs (going with the idea of storing PataPata state as textual Python code, like it currently does for worlds). Anyway, thanks again for the feedback. Any other comments are appreciated. --Paul Fernhout Brad Miller wrote:
From a Mac user's perspective I think the answer is probably not. This approach would put PySqueak on a similar trajectory as vpython which requires us to use X11 on the mac in order to get GTK and friends working. Further, this arrangement forces us to make separate builds of python using fink or darwin ports, which in turn gives us two separate python installations on our Macs.
Several have tried to port vpython to a native (non-X11-dependent) implementation on the mac over the last few years but nobody has succeeded yet. There is some work in GTK+ 2.9.x to get a native port of GTK working on the mac. Maybe when this effort is finally successful then native versions of vpython and other packages will be easier.
So, personally I would be sad to see PySqueak head down this road. But I also think that the effort required to get everything working under X11 would be too difficult for many beginners.
On 03/06/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote: Just for feedback, I've just installed PyGTK & GTK+ 2.8 runtime & pyCairo on a WinXP box and its really quick: 1 exe for each to double click on. http://www.pcpm.ucl.ac.be/~gustin/win32_ports/ The 3D gtkglext is more difficult for now (I didn't find any exe): => mingw , make for win, etc ... Maybe for very *motivated* people (under win and mac-intel), a "heavy-gear" possibility to be sure that most things are well set-up will be a patapata-liveCD (maybe based on something like Morphix - that I might try this summer). While checking this I've just found out that "pyro" made an apparently nice live-CD (with knoppix) : http://www.pyrorobotics.org/?page=PyroLiveCD Actually I think it would also be useful to have a ~ "PythonWorldEdu-LiveCD" with : - Python resources (+ videos) - all the educational Python softs possible (patapata, vpython, Crunchy-Frog, rur-ple, "gnu-math", pyro, pygeo, pygame, pymol, etc ...) - Pyhon and Python bindings apps to make contents with (Blender, Gimp, etc) or to play games. In fact I'd like something I could show to people and say : all this software are done either in Python or you can tinker them with Python (bindings) and if you want to begin to discover/learn Python all you need is the live CD and begin playing with all these. Concerning your java options, I don't know if you've seen the Logo TNG Gui on OS-X : http://education.mit.edu/starlogo-tng/tutorial-videos/ I'm not a big Java fan but if Java applets could help to bring patapata in a browser with some python code background it could be important. For Alan Kay the browser is something to reconsider: http://www.redhat.com/archives/olpc-software/2006-April/msg00035.html (And I would rather be modifying Jython than CPython,
since Java is somewhat easier to work with than C.) So, maybe I should think harder about a Jython/Swing version of PataPata (at least as another proof of concept)?
Dear me I don't now were you find all this pluridisplinarity and energy ! I don't know what you eat (or drink) in the morning but I want to order the same ;) Concerning the different graphical/GUI choices I just don't now enough yet to be useful but I'm following with interest your investigations. Maybe, If after gathering feedback's you're not sure about the choices to make, I tend to advise to go with the one you "feel" you will have the more fun with :) I'm quite convince of that after reading Pekka Himanen book (phD at 20 ...) which have also an interesting intro of Torwald about the 3 (survival,social, and fun) needs : http://www.pekkahimanen.org/ http://www.netvironments.org/ECulture/Module3/HackerEthic/ francois
On 6/3/06, francois schnell <francois.schnell@gmail.com> wrote:
On 03/06/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:
- Python resources (+ videos) - all the educational Python softs possible (patapata, vpython, Crunchy-Frog, rur-ple, "gnu-math", pyro, pygeo, pygame, pymol, etc ...) - Pyhon and Python bindings apps to make contents with (Blender, Gimp, etc) or to play games.
In fact I'd like something I could show to people and say : all this software are done either in Python or you can tinker them with Python (bindings) and if you want to begin to discover/learn Python all you need is the live CD and begin playing with all these.
Concerning your java options, I don't know if you've seen the Logo TNG Gui on OS-X : http://education.mit.edu/starlogo-tng/tutorial-videos/
Nice! This is obviously not the work of hobbyists. However, while the GUI is impressive, I am somewhat puzzled by their choice of angle measurement: 0 degree is "up" (i.e. y-axis in the traditional notation), 90 degrees is "right" (i.e. x-axis), etc. So, angles are increasing in the clockwise direction, starting from the y-axis. I wonder what their rationale is to use this non-conventional notation. It reminds me of the standard choice for the origin (top left) of screen image, with increasing y-coordinates going down, versus the standard mathematical choice for the origin (center ... or bottom left) with increasing y-coordinates going up. I'm not a big Java fan but if Java applets could help to bring patapata in a
browser with some python code background it could be important. For Alan Kay the browser is something to reconsider: http://www.redhat.com/archives/olpc-software/2006-April/msg00035.html
After reading Kay's post, I can say that Crunchy Frog appears to be heading in a similar way (fingers crossed) where you will be able to do turtle graphics. (And, hopefully, eventually ... embedded rur-ple :-) Who knows, one day, perhaps patapata will be supported in a browser using Crunchy Frog. (mostly Python with some javascript code and using the <canvas> tag.) André
Francois- Thanks for the field report and links. So, just based on only these two comments (yours and Brad's), for GNU/Linux and recent Windows compatablity, pyGTK and Cairo are probably "works out of the box" experiences for most, but on Mac they are not. And 3D with pygtkglext is problematical on both Win and Mac (and I have not tried it either under Debian), so 3D that way sounds like a future thing at best. Live CDs sound great for the field (we had the earlier discussion about it on edusig a month or two back, including a link to a Python software distribution on a GNU/Linux bootable CD), http://wiki.python.org/moin/PythonCd though for individuals, like you say, they have to be motivated to make and boot a CD, more so than a simple download onto their current system. I read a few of the Alan Kay posts in that thread just now, and I think he is right on people not wanting to spread technology developed after the 1960s (and objects are a 1970s thing. :-). He sounds frustrated about it, but then so am I. :-) The site that he linked to was down, but the follow up reports suggested that some people had problems with the code there (JavaScript in a browser?), so even a browser based solution failed to deliver easy access to programming for people. No suprise with all the different versions of browsers out there (especially among people liable to try that demo). I personally have little interest trying to dumb something down to the browser level because I want to use things I make to write big systems, which would be hard in a browser, although I think it is none-the-less worth trying for others with different interest, like Johannes' Summer of Code project. I may have mentioned it here before, but one of my relatives who is a teacher had to sign a document saying she could be fired if they installed any software on her classroom computer. (The school district is worried about getting audited for copyright violations). But, presumabl, Java applets might be OK? I think the licensing issue and installation ease issue is a much bigger deal on the K-12 level than at the home or college level. One thing in the back of my mind since she told me that was some sort of dynamic application plus licensing information system where she could get her district to allow installation of a plugin or application which only allowed free software top be run on it. That way, they district is safe from lawsuits, and she has access to educational materials. It might be nice if some versions of PataPata or such could include that sort of capability -- only accepting applications digitally signed as being free to use (the opposite of must DRM software :-). Is edusig more composed of people on the college level, that we may not get too many K-12 educators chiming in on this? Or maybe it is not such a big problem outside the USA? See: "FREEZE! THIS IS A SOFTWARE RAID" http://www.businessweek.com/1997/09/b351634.htm and: "Guitar maker plays a Linux tune" http://www.infoworld.com/articles/hn/xml/02/11/27/021127hnerniball.html?s=ID... Can't find a school raid one off hand, but I know I have seen them before. Still, JavaScript is powerful and prototype-based, so something to keep thinking about. By the way, there is a JavaScript based interchange language Python binds to which I forget the name of which I had been thinking of using in PataPata instead of (unsafe) Python for data interchange (though I would prefer Python and a limited Python parser, say that only called a list of functions and classes, but people say wait for PyPy) -- if I could just remember what is was called. Thanks for the links. Got some ideas from Logo:TNG (I looked at two clips). Nice, and Squeak has something like it for some programming apps, but personally, I think (like Kirby?) that programming is more about language and text manipulation. Probably nothing wrong with introducing it as they do (nice idea of making statements like buttons), just that I would not want to maintain a complex application built that way. :-) So it falls in that category I mentioned in the elementary graphics thread of "making powerful tools easy to use for simple things vs. making it easy to do some simple things and that's it". Now, not having seen more of that system, it may well do very complex things (and I think the later Logos can). Some of this depends on the audience, I guess. On the other links, what's with these smart people from Finland? Now there is someplace that it sounds like you should go to drink the water. :-) Me, I'm sacrificing some sleep and it will catch up with me. [I have a consulting project that might be coming up so I want to get as much done as possible before that distracts me, in hopes it might pick up speed on its own afterwards if it reaches a "critical mass" point.] But nothing like an audience to get one motivated. I appreciate your interest, and hope at some point you might try the TK version in SVN -- though I have not packaged it, so you'd need to check it out with SVN (or download each of about twenty files separately, ouch). http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/ I could make a package if that makes it a lot easier though. The inspector is now live in the world, and you can now save and load files with TK widgets. You can even delete the save and load buttons. :-) I'm trying to resolve a bug right now related to the prototype delegation; I've spent hours trying to trace what is probably some tiny mistake somewhere; it is related to copying a TK button and modifying the copy's click method and having the first buttons click method still called; so I haven't wanted to make a new released version with that problem. Anyway, I'd be curious to read your opinion on whether a TK version would hold your interest (or the interest of other educational people) given you mention somewhere on your site an interest in moving from tk to wx. If TK is good enough for you, I might keep developing with it for a while just to see how far it can go (hopefully to the point of a HyperCard like thing), since it is, for good or ill, the most cross-platform easy-install solution right now for Python GUIs and related graphics. Even wx takes an extra set of libraries. (I also think PataPata could make TK a little more approachable in some ways. :-) Then, with a little magic and tinkering, maybe a future Jython version could come along to make any future HyperCard-like PataPata stacks into applets? It really does not take that long to wrap the basic widgets of a system (a suprise for me, as I thought it would), and I already know Jython and Swing (my TK was very rusty). Anyway, I think a TK HyperCard-like system (and eventually raiding the PythonCard demos :-) that might be a nice next goal to aim for. Not as funky as pyGTK and Cairo and OpenGL, but something I could show ready progress on to some point of critical mass. However, if there are a predominance of "yes" responses to my other post about one click Java3D, I might think about moving to Jython and Swing. Even though two of my four tests failed, I think they failed due more to lack of OpenGL support on one machine than Java WebStart failing, which would mean a regular Jython Swing app might run correctly with one click more often than not. Anyway, for now, I am pushing along with TK as these issues percolate and I get feedback. Several things I need to do (e.g. making PataPata worlds talk to each other so you can have you app in one and the development tools in another) have little to do with the GUI anyway. All the best. --Paul Fernhout francois schnell wrote:
On 03/06/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote: Just for feedback, I've just installed PyGTK & GTK+ 2.8 runtime & pyCairo on a WinXP box and its really quick: 1 exe for each to double click on. http://www.pcpm.ucl.ac.be/~gustin/win32_ports/
The 3D gtkglext is more difficult for now (I didn't find any exe): => mingw , make for win, etc ...
Maybe for very *motivated* people (under win and mac-intel), a "heavy-gear" possibility to be sure that most things are well set-up will be a patapata-liveCD (maybe based on something like Morphix - that I might try this summer).
While checking this I've just found out that "pyro" made an apparently nice live-CD (with knoppix) : http://www.pyrorobotics.org/?page=PyroLiveCD
Actually I think it would also be useful to have a ~ "PythonWorldEdu-LiveCD" with :
- Python resources (+ videos) - all the educational Python softs possible (patapata, vpython, Crunchy-Frog, rur-ple, "gnu-math", pyro, pygeo, pygame, pymol, etc ...) - Pyhon and Python bindings apps to make contents with (Blender, Gimp, etc) or to play games.
In fact I'd like something I could show to people and say : all this software are done either in Python or you can tinker them with Python (bindings) and if you want to begin to discover/learn Python all you need is the live CD and begin playing with all these.
Concerning your java options, I don't know if you've seen the Logo TNG Gui on OS-X : http://education.mit.edu/starlogo-tng/tutorial-videos/
I'm not a big Java fan but if Java applets could help to bring patapata in a browser with some python code background it could be important. For Alan Kay the browser is something to reconsider: http://www.redhat.com/archives/olpc-software/2006-April/msg00035.html
(And I would rather be modifying Jython than CPython,
since Java is somewhat easier to work with than C.) So, maybe I should think harder about a Jython/Swing version of PataPata (at least as another proof of concept)?
Dear me I don't now were you find all this pluridisplinarity and energy ! I don't know what you eat (or drink) in the morning but I want to order the same ;)
Concerning the different graphical/GUI choices I just don't now enough yet to be useful but I'm following with interest your investigations. Maybe, If after gathering feedback's you're not sure about the choices to make, I tend to advise to go with the one you "feel" you will have the more fun with :) I'm quite convince of that after reading Pekka Himanen book (phD at 20 ...) which have also an interesting intro of Torwald about the 3 (survival,social, and fun) needs : http://www.pekkahimanen.org/ http://www.netvironments.org/ECulture/Module3/HackerEthic/
francois
On 04/06/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:
Francois-
Live CDs sound great for the field (we had the earlier discussion about it on edusig a month or two back, including a link to a Python software distribution on a GNU/Linux bootable CD), http://wiki.python.org/moin/PythonCd though for individuals, like you say, they have to be motivated to make and boot a CD, more so than a simple download onto their current system.
Oops I missed that, they should add an "edu section", thanks I'll try it . I read a few of the Alan Kay posts in that thread just now, and I think he
is right on people not wanting to spread technology developed after the 1960s (and objects are a 1970s thing. :-). He sounds frustrated about it, but then so am I. :-) The site that he linked to was down,
You're right the site isn't accessible for me neither. When I tried it a few weeks ago it worked well. I may have mentioned it here before, but one of my relatives who is a
teacher had to sign a document saying she could be fired if they installed any software on her classroom computer.
[...] "FREEZE! THIS IS A SOFTWARE RAID"
http://www.businessweek.com/1997/09/b351634.htm and: "Guitar maker plays a Linux tune"
http://www.infoworld.com/articles/hn/xml/02/11/27/021127hnerniball.html?s=ID... Can't find a school raid one off hand, but I know I have seen them before.
Yes we have the same threats in French education and posters from the BSA everywhere in schools : http://francois.schnell.free.fr/bazar/exigez-loriginal.JPG http://swpat.ffii.org/gasnu/bsa/ Personally I hope they will even be more aggressive towards education, thanks to them it really helps to spread Free Software much quicker ! I heard Quebec ditched MS Office in secondary education for Open Office because of these threats. Other countries like Spain and Brazil are now massively going for Linux in secondary education. Me, I'm sacrificing some sleep and it will catch up with me. [I have a
consulting project that might be coming up so I want to get as much done as possible before that distracts me, in hopes it might pick up speed on its own afterwards if it reaches a "critical mass" point.]
Still take care of yourself ! undefined day you should ... time.sleep (7*60*60) But nothing like an audience to get one motivated. I appreciate your
interest, and hope at some point you might try the TK version in SVN -- though I have not packaged it, so you'd need to check it out with SVN (or download each of about twenty files separately, ouch). http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/ I could make a package if that makes it a lot easier though.
Don't worry about the package I've actually co the repository a day ago (on my XP and Kubuntu box) and will check for updates often to have my current juicy PataPata version :) Here's the problem I have with the Tk version: On Win XP : - If I alt-right-click on a Morph and call the inspector it doesn't work (ie I can see in the dos window that it called InspectMorph <Prototype xxxxx> but the inspector doesn't focus on this Morph) - If I manually search for a morph in the Inspector (where it says "morphs <'type list'>") and if I try to change its color for example (lets say 'red') and click "accept" => the morph disappear from the world and the dos window says : problem drawing morph <Prototype xxxx> On Kubuntu Dapper Drake: - the alt (left or right) click doesn't work as expected : if I want to drag a morph I'm always dragging the whole application window and I can't drag an individual Moph anymore. If do an alt-right click I can't access the menu to inspect the morph (I have a ~"resize" icon for the mouse cursor). - I have the same bug than for XP if I want to change a value in the inspector. Maybe it is related to the bug you were talking about ? I can make a quick screencast if it helps you to visualize the problem. francois
All the best.
--Paul Fernhout
On 03/06/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote: Just for feedback, I've just installed PyGTK & GTK+ 2.8 runtime & pyCairo on a WinXP box and its really quick: 1 exe for each to double click on. http://www.pcpm.ucl.ac.be/~gustin/win32_ports/
The 3D gtkglext is more difficult for now (I didn't find any exe): => mingw , make for win, etc ...
Maybe for very *motivated* people (under win and mac-intel), a "heavy-gear" possibility to be sure that most things are well set-up will be a patapata-liveCD (maybe based on something like Morphix - that I might
this summer).
While checking this I've just found out that "pyro" made an apparently nice live-CD (with knoppix) : http://www.pyrorobotics.org/?page=PyroLiveCD
Actually I think it would also be useful to have a ~ "PythonWorldEdu-LiveCD" with :
- Python resources (+ videos) - all the educational Python softs possible (patapata, vpython, Crunchy-Frog, rur-ple, "gnu-math", pyro, pygeo, pygame, pymol, etc ...) - Pyhon and Python bindings apps to make contents with (Blender, Gimp, etc) or to play games.
In fact I'd like something I could show to people and say : all this software are done either in Python or you can tinker them with Python (bindings) and if you want to begin to discover/learn Python all you need is the live CD and begin playing with all these.
Concerning your java options, I don't know if you've seen the Logo TNG Gui on OS-X : http://education.mit.edu/starlogo-tng/tutorial-videos/
I'm not a big Java fan but if Java applets could help to bring patapata in a browser with some python code background it could be important. For Alan Kay the browser is something to reconsider: http://www.redhat.com/archives/olpc-software/2006-April/msg00035.html
(And I would rather be modifying Jython than CPython,
since Java is somewhat easier to work with than C.) So, maybe I should think harder about a Jython/Swing version of PataPata (at least as another proof of concept)?
Dear me I don't now were you find all this pluridisplinarity and energy ! I don't know what you eat (or drink) in the morning but I want to order
francois schnell wrote: try the
same ;)
Concerning the different graphical/GUI choices I just don't now enough yet to be useful but I'm following with interest your investigations. Maybe, If after gathering feedback's you're not sure about the choices to make, I tend to advise to go with the one you "feel" you will have the more fun with :) I'm quite convince of that after reading Pekka Himanen book (phD at 20 ...) which have also an interesting intro of Torwald about the 3 (survival,social, and fun) needs : http://www.pekkahimanen.org/ http://www.netvironments.org/ECulture/Module3/HackerEthic/
francois
Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
francois schnell wrote:
Still take care of yourself ! undefined day you should ... time.sleep (7*60*60)
Well, after a good night's sleep, the bug I've spent endless time chasing, scouring all the delegation code in Prototypes.py for perhaps ten or so hours on and off, turned out to be a problem in the GUI code from all the way back to the wx code I copied for tk (which it turns out had the same problem). So nothing wrong with the delegation code (though I did optimize it some, and add a debugging flag during all the hair pulling. :-). Avoiding these kind of mistakes is just the reason "pair programming" is surprisingly cost effective. http://www.pairprogramming.com/ From there: "One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work." Someone looking over my shoulder when I wrote the original code might have noticed that and saved me lots of debugging. Need to add support for doing that virtually over the net with PataPata someday. :-) It's amazing how much even a novice programmer can contribute to an expert's productivity by just noticing something like that and asking a question about it while the code is being first written. For those who are curious, or to mildly challenge your students, here is the offending piece of code (though most of the problem was knowing where to look, of course. :-): def duplicateMorph(self, morph): newMorph = morph.copy() self.addMorph(newMorph) newMorph.x += 5 newMorph.y += 5 if morph.getPropertyDefinition("createEmbeddedWidget"): morph.createEmbeddedWidget() World.duplicateMorph = duplicateMorph As the Monty Python team might say, "Can you spot the loony [bug]?" :-) ============================ ==== If you need a hint: === ============================ If I had done a better job of naming the input variable to "originalMorph" this would have been a more obvious problem. Solution below: (*) I also corrected the wx version, which used the identical code, which I had copied to the tk version.
Don't worry about the package I've actually co the repository a day ago (on my XP and Kubuntu box) and will check for updates often to have my current juicy PataPata version :)
Great. :-)
Here's the problem I have with the Tk version:
On Win XP :
- If I alt-right-click on a Morph and call the inspector it doesn't work (ie I can see in the dos window that it called InspectMorph <Prototype xxxxx> but the inspector doesn't focus on this Morph) - If I manually search for a morph in the Inspector (where it says "morphs <'type list'>") and if I try to change its color for example (lets say 'red') and click "accept" => the morph disappear from the world and the dos window says : problem drawing morph <Prototype xxxx>
On Kubuntu Dapper Drake:
- the alt (left or right) click doesn't work as expected : if I want to drag a morph I'm always dragging the whole application window and I can't drag an individual Moph anymore. If do an alt-right click I can't access the menu to inspect the morph (I have a ~"resize" icon for the mouse cursor). - I have the same bug than for XP if I want to change a value in the inspector.
Maybe it is related to the bug you were talking about ? I can make a quick screencast if it helps you to visualize the problem.
Sorry about those difficulties. You've kept me busy for the afternoon. :-) Probably no need for a screencast for these issues, but I'd love to see one for TK once things are working well for you. First, so it works at all (even with smoke coming out :-)? That was my first concern, and implicitly I think that is answered by "yes". :-) Hooray! For the the inspector tree updating, that was simply not finished. I had known about this, but I has just had not got around to fixing it. I have now fixed it and it is in the latest SVN. Should work for all platforms. The non-widget morph disappearing and generating a drawing error message is most likely a problem with validation of whatever was entered for the color field. If TK can't interpret the color value of the widget, it can't draw it. I can't be certain that is the problem, but I think that is the most likely cause because I have seen it happen myself (like if I put in "blue" instead of "blue"). There is a color selector dialog now used under TK, though you need the world menu. In testing this just now, I'm finding the TK multi-line edit is adding an extra newline. I think this is a known TK issue, so I just now changed the code in SVN to strip that out, otherwise this will never work from the inspector? You can also use a new right click menu option of "edit value" which gives you a popup single line editor where you can enter "blue" and no newline is appended for sure. Please let me know if that problem persists after the latest SVN, in case it was from something else. I just added a way to validate (or otherwise alter) any changes to properties, using a "callBeforeSetFunction" defined in a property for a prototype, but I have not tested it. :-) Also, I do not know what are valid TK color options or how to determine this. [There is also another bug with setting colors if you use the color setting dialog and save the world, when it reads it in there will be an error and a loss of the color, though the world should still load properly otherwise and the inherited color will be used.] Alt clicking is problematical under Linux because the default (for Gnome?) seems to be that alt click will drag the window in the window manager. I'm thinking the dragging or resize curso behavior might be due to this. Under Gnome, you can change Window manager preferences so that ALT does not drag windows (choose the "Windows" key instead). The reason I picked "Alt" where I would rather have picked "Ctrl" is that Ctrl-click is used for multi-select in lists commonly, which I think is a common thing to want to do. I don't know of a common use for ALT (but maybe there is?). I don't have a good answer for this (other than changing the window manager preferences), although in response to this I just added support for setting the Meta key selection by uncommenting something in "options.py" so you could use Ctrl-click easily if you wanted to after editign that file. Still, I don't like making such a core part of the GUI changeable in terms of leading to confusion, so I don't know if this should stay). Another alternative would be to use Ctrl in all widgets except lists? Though that might be confusing in its own right. Maybe you or someone else can think of a better approach to this? Please me know if these workarounds don't work for you. By the way, I moved the choice of GUI to "options.py" as well. wx should still work. If everything seems OK with you with these fixes, I think I will soon bump the version number up to 1.1 and make another file release. The last really annoying thing I know of is that sometimes when you drop a widget it continues to drag; that needs more work first though; hopefully it is not a fundamental tk problem. I'll be curious if that is GNU/Linux only? Also, there is flicker in the TreeWidget from how it is used, but I think that is livable (I can't find an easy way to freeze it for a while like I did under wx). And drawn morphs are always below widget morphs but can sometimes be dragged if they are above them in the world morph list -- not sure what to do about that, other than get rid of the drawn morphs and make them draw in widget frames with a canvas (the likely solution). There is also no way to raise and lower morphs. Or the biggy new thing needed for HyperCard-like functionality, compositing morphs (or at least, nesting them). Lots more to do, but probably OK to put those off for the next release. Thanks for your fortitude for living on the "bleeding edge" of technology, and I appreciate your continued interest and comments with the jump to TK. I now it's been a bumpy ride switching widgets toolkits, and I tried to do it fast to keep momentum moving on this project. I'm hoping that once the system is working well with TK it should be more malleable for more Python programmers. --Paul Fernhout (*) To understand the bug, renaming the input variable from "morph" to "originalMorph" should make the problem more obvious: def duplicateMorph(self, originalMorph): newMorph = originalMorph.copy() self.addMorph(newMorph) newMorph.x += 5 newMorph.y += 5 if originalMorph.getPropertyDefinition("createEmbeddedWidget"): originalMorph.createEmbeddedWidget() World.duplicateMorph = duplicateMorph That shows how the code used the original "morph" instead of "newMorph" to instantiate the new native widget, thus resultign in hooking up, say, a new native button to the old button's Morph prototype. So the the new Morph would never receive click events from the new native button, as they would go to the old Morph prototype directly. All the time I assumed it was some instead a problem with the delegation code. So the corrected code, both that works and that is clearer. def duplicateMorph(self, originalMorph): newMorph = originalMorph.copy() self.addMorph(newMorph) newMorph.x += 5 newMorph.y += 5 if newMorph.getPropertyDefinition("createEmbeddedWidget"): newMorph.createEmbeddedWidget() World.duplicateMorph = duplicateMorph A tip off to me should have been that the new morph was not offset by 5 pixels in X and Y as with the drawn widgets. I had noticed that, but thought I'd look into that problem later. It was only when I started thinking about that anomaly instead that I found this bug. I am now thinking that had I looked harder at the newMorph, I might also have noticed that the widget field was presumably still None.
On 04/06/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:
Alt clicking is problematical under Linux because the default (for Gnome?) seems to be that alt click will drag the window in the window manager.
D'oh ! I should have thought of that. I was on KDE (Kubuntu is an Ubuntu distro which is KDE centric).I've just changed the "Alt" in "System Settings > Desktop > Window Behavior" and now its fine :) I'll test later on Gnome and XFCE. If everything seems OK with you with these fixes, I think I will soon bump
the version number up to 1.1 and make another file release.
Maybe you could go for a little smaller frame than 850 in height : on a 1024*768 setting I can't catch the the "save button" and it wil help me for screencasts :) BTW I just love now the fact that I can drag and reorganize completely all the elements of the interface (buttons, inspector) in term of position, size, etc. Cool. The last
really annoying thing I know of is that sometimes when you drop a widget it continues to drag;
I didn't saw that yet but sometimes (rarely) on Win & LInux, if I alt-click & drag a widget/morph quickly and then if I stop pushing the alt-key and continue to move the mouse away the morph drop but if I press the alt key again in the world the morph go to the new position of the mouse. This is not a big problem (at least for me). Also, there is flicker in the TreeWidget from how it is used, but I think
that is livable (I can't find an easy way to freeze it for a while like I did under wx).
I think its fine I don't find it disturbing. On the other-hand on WinOS if I right-alt-click on a morph I need to engage in the menu and "quickly" stop pressing the alt-key (otherwise the menu is flickering and its difficult to choose an entry of the menu). When you know it after its fine. Lots more to do, but probably OK to put those off for the next release. Yes, sure :) .
I now it's been a bumpy ride switching widgets toolkits, and I tried to do it fast to keep momentum moving on this project.
I like bumpy rides, flat and straight roads are boring ... I'm hoping that once the
system is working well with TK it should be more malleable for more Python programmers.
I hope too, BTW I could maybe present your work in the Python section of the Libre Software Meeting in July in France if you're OK with that and if you feel it's not too soon. It's a kind of "big bazaar" in a French University and there's a Python section too organised by the French Python User Group (AFPY). I could apply for a small presentation (there maybe won't be a lot of people since there are lots of // tracks in this meeting but it could interest some python users/developers). http://www.rmll.info/?lang=en BTW I can now also change values and method without any problems with your new version. Well done, time to sleep on this part of the globe, time.sleep(7*60*60) :) francois --Paul Fernhout
francois schnell wrote:
Maybe you could go for a little smaller frame than 850 in height : on a 1024*768 setting I can't catch the the "save button" and it wil help me for screencasts :)
Good idea. I shrunk the example to 800x600, and repositioned and shrunk some widgets to make that all fit, so as to make screencasts / screenshots of the example world easier. The changes are in SVN. If you need space to work, you can always enlarge the window after it is running. Anything to help keep those great screencasts coming. :-)
BTW I just love now the fact that I can drag and reorganize completely all the elements of the interface (buttons, inspector) in term of position, size, etc. Cool.
Glad you like it. That is the ultimate promise of the system. At this point, in theory, you should be able to bootstrap it completely using just itself. In practice, I find myself still editing the original source files for now. I'm not sure at what point I would make the switch over. I have a feeling I have to think more deeply about issues related to multiple worlds sharing code, and also a difference between application code prototypes and library code prototypes, perhaps with a writer that doesn't write out library prototypes but puts a reference to them and the version of the library to load from when the world reloads. Still, you can now "shoot yourself in the foot" by deleting the inspector widgets (or doing a "clear"). What I want to have is worlds talking to worlds, so your inspector can be in another world, where it is not operating on itself (you could then have another inspector operating on it in another world of course, recursively). I've just been reading about the TK "Send" command, which allows you to execute arbitrary TCL code in another TCL/TK application running in the same X session. That sounds like what I wanted to do with PataPata in terms of having worlds send Python code to each other. I had been worried about the security issues and wanting to have a Python sandbox for such code, but if TCL/TK has been doing this for more than a decade (with me reinventing this wheel :-) then it seems like doing that with Python should be acceptable as long as I do some minimal security equivalent to what TCL/TK does. [Which also means that all Python Tkinter apps may have been accepting this risk already for a very long time, too.] I could perhaps use the TCL "send" facility to get started; I need to look into that, though I read somewhere the TCL/TK Win32 may not support Send, it seems, so if that is true I definitely want something that does. Still lots to think about and do there.
I didn't saw that yet but sometimes (rarely) on Win & LInux, if I alt-click & drag a widget/morph quickly and then if I stop pushing the alt-key and continue to move the mouse away the morph drop but if I press the alt key again in the world the morph go to the new position of the mouse. This is not a big problem (at least for me).
Yes, that's the sort of thing, generally with fast drags, and I suspect it may have something to do with dragging widgets over or under other widgets at the same time. Not sure exactly where the problem is. I suspect it is in TK not processing some events fast enough somehow and perhaps even dropping events. I need to look more at this. One thing I have been thinking of, which might help with the TK events, is switching to a drag model where a drag starts when you press the ALT key down (not the mouse button), so to drag you would mouse over to a widget, press the ALT key, watch the widget move while dragging, and then let go of the ALT key when you were done. I'm hoping to code that up and see how it feels, and if it as a byproduct solves the problem. It may introduce another problem though -- if you press the ALT key at any other time when using the system (say by mistake) your widgets might move. I'll have to see if that is a serious problem in practice. Anyway, not certain I will do that, but just one approach. And not sure it will map to all platforms either.
On the other-hand on WinOS if I right-alt-click on a morph I need to engage in the menu and "quickly" stop pressing the alt-key (otherwise the menu is flickering and its difficult to choose an entry of the menu). When you know it after its fine.
Hmmm, need to think about that. Clearly that is awkward. I wonder how other widget editors cope with that. Originally, in an earlier proof of concept I had a right click menu (without requiring ALT) which joined together the widget options and the world options. (I could have made a cascading menu for the world options at the top, I guess). I'm reluctant to abandon the "ALT" difference for menus, but I could consider going back to that old approach. But if I do, then any common widget that puts up its own menu using native calls might not have access to the world menu (unless it explicitly does something). On the other hand, not many native widgets use menus out-of-the box I think (probably there are some fancy complex widgets, like graphs with their own internal menus). It seems like in using native widgets,there simply will need to be some compromises somewhere.
BTW I could maybe present your work in the Python section of the Libre Software Meeting in July in France if you're OK with that and if you feel it's not too soon.
It's a kind of "big bazaar" in a French University and there's a Python section too organised by the French Python User Group (AFPY). I could apply for a small presentation (there maybe won't be a lot of people since there are lots of // tracks in this meeting but it could interest some python users/developers). http://www.rmll.info/?lang=en
That would be fantastic. I'm still a little nervous PataPata is not finished or polished enough to have too many users right now. You've been tolerant of the bumpy ride (thanks); most people probably would not be. But maybe if you presented PataPata/PySqueak as an experimental work in progress? Or just a fun thing to try to see what is possible in Python using a prototype-programming paradigm? As opposed to presenting it as a finished work to use to build the next great misson-critical application. :-) Anyway, I don't want to discourage you from presenting on it. I think that would be great, and a few more interested people trying it on different platforms, say the Mac or FreeBSD, would be wonderful. And if a few of them wanted to build something on top of it or make improvements to the core, that would be great. I'm just trying to encourage you to keep the audience's expectations low for now, both because it is a work-in-progress and also mostly because I don't have the time myself to provide technical support to more than a handful of users right now. :-) Still, everything is in sourceforge, so there is lots of potential for collaboration there, including others taking it in new unexpected directions. === possible future directions === I think if I could have a Jython version where you could do a one click on a web site and get a Python/Jython PataPata prototype development environment runnign on your system, then that might be something realy worth reporting. :-) I was encouraged by the fact that when you and Andre tried it, the Java Webstart system worked as advertised and even gave you 3D images (if you have Java installed and OpenGL drivers properly configured). But adding such an extra platform also entails a bit more thinking and refactoring related to abstracting out cross-platform issues. That is the opposite of the advice I gave Johannes about committing to pyCairo in the "elementary graphics" thread, I know, :-) but I think a specific graphics library choice is easier to insist on then to insist on a single choice of an event driven widget set choice. For example, I would expect pyCairo probably doesn't require X11 be installed on the Mac. Here are pyCairo's Mac dependencies, by the way, but I am not sure what in practice that means for installation difficulties of a binary package? http://www.hmug.org/pub/MacOS_X/BSD/Development/Languages/python/pycairo/ I'm still tempted to make pyCairo an important part of PataPata down the road, but likely without a GTK requirement (since I think Brad has a good point on GTK issues for the Mac for now), especially if any Mac users chime in on the feasibility of an easy installation for just that part. It sounds like, from your report, and my experience, that using just pyCairo under Wind or GNU/Linux requires just a fairly easy install. Anyway, the widget sets were surprising easy to hook up, at least for the basics, so it seems to me that it might be possible, without too much trouble, to have cross-platform support for wx, tk, Jython/Swing, GTK, and Cocoa/Mac, at least as far as the basics of handling a button which clicks, a text field that you can get the current value, popup message boxes, and so on, which might then be enough to make simple cross-platform HyperCard like stacks. Obviously, people might want to do native things with the particular widget set they choose to use, but providing at least some simple cross-platform support for the most common things might making porting easier later. So, as I write this, I find myself, at some reluctance, following the "worser is Better" philosophy of design: http://www.jwz.org/doc/worse-is-better.html "The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing." :-)
BTW I can now also change values and method without any problems with your new version.
Thanks for the feedback that that part works. I'm thinking the original issue was from the tk text-entry extra newline issue, which I worked around. --Paul Fernhout
Just as an update, I've released a 1.10 version of PataPata at: http://sourceforge.net/project/showfiles.php?group_id=165910 As a recap of what is new relative to the previous version, there is now a TK version in addition to the wxWidgets version. The TK version has the inspector and other controls live in the world (so the inspector can inspect and modify itself, you can "shoot yourself in the foot" by deleting the file "open..." and "save..." buttons or the inspector edit field, etc.). One recent change related to the flicker and dragging problem discussed here is that the TK version no longer updates the inspector when you click on a morph. You have to ALT-right-click to bring up the menu and pick the first item which says "inspect morph". That solved both most of the flicker issue (still a little) and, more importantly, the dragging bug (where a widget kept tracking the mouse after you let go of it). This is little less convenient in some ways, but I'll see how people take to it. The interface feels a little less "hyper" now (in a good way). :-) No solution yet for the ALT-right-click menu flicker issue under windows. I did try to do just ALT-dragging to move morphs under TK (without a need for a mouse click), but gave up on it for now as I ran into a few issues. It turns out you need to click first in the frame to get TK to listen for keys. So, if you are just mousing over the window, and press ALT, it might in some cases not work. Also, frustratingly, the canvas (as opposed to a frame) seemed to ignore key events for some reason despite my trying lots of variations (you would think that would be resolvable, but with the first issue making me wonder if it was a good idea, I did not pursue that at great length). Still lots of stuff to do. --Paul Fernhout Paul D. Fernhout wrote:
francois schnell wrote:
I didn't saw that yet but sometimes (rarely) on Win & LInux, if I alt-click & drag a widget/morph quickly and then if I stop pushing the alt-key and continue to move the mouse away the morph drop but if I press the alt key again in the world the morph go to the new position of the mouse. This is not a big problem (at least for me).
Yes, that's the sort of thing, generally with fast drags, and I suspect it may have something to do with dragging widgets over or under other widgets at the same time. Not sure exactly where the problem is. I suspect it is in TK not processing some events fast enough somehow and perhaps even dropping events. I need to look more at this. One thing I have been thinking of, which might help with the TK events, is switching to a drag model where a drag starts when you press the ALT key down (not the mouse button), so to drag you would mouse over to a widget, press the ALT key, watch the widget move while dragging, and then let go of the ALT key when you were done. I'm hoping to code that up and see how it feels, and if it as a byproduct solves the problem. It may introduce another problem though -- if you press the ALT key at any other time when using the system (say by mistake) your widgets might move. I'll have to see if that is a serious problem in practice. Anyway, not certain I will do that, but just one approach. And not sure it will map to all platforms either.
On the other-hand on WinOS if I right-alt-click on a morph I need to engage in the menu and "quickly" stop pressing the alt-key (otherwise the menu is flickering and its difficult to choose an entry of the menu). When you know it after its fine.
Hmmm, need to think about that. Clearly that is awkward. I wonder how other widget editors cope with that. Originally, in an earlier proof of concept I had a right click menu (without requiring ALT) which joined together the widget options and the world options. (I could have made a cascading menu for the world options at the top, I guess). I'm reluctant to abandon the "ALT" difference for menus, but I could consider going back to that old approach. But if I do, then any common widget that puts up its own menu using native calls might not have access to the world menu (unless it explicitly does something). On the other hand, not many native widgets use menus out-of-the box I think (probably there are some fancy complex widgets, like graphs with their own internal menus). It seems like in using native widgets,there simply will need to be some compromises somewhere.
kirby urner wrote:
On 6/5/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote: Besides write these posts to edu-sig? When do you ever find the time :-D.
Oh, it's part of the design process. :-) (*) From: http://www.pairprogramming.com/ "KNOWLEDGE IS commonly socially constructed, through collaborative efforts towards shared objectives or by dialogues and challenges brought about by different persons' perspectives. -- G. Salomon (book: Distributed Cognitions: Psychological and Educational Considerations)" So, I see these posts and replies as about socially constructing knowledge about good designs for educational computing platforms in Python (both to teach programming in Python and to deploy Python-based educational simulations), based on the needs and feedback of people who actually use Python in education. --Paul Fernhout
So, I see these posts and replies as about socially constructing knowledge about good designs for educational computing platforms in Python (both to teach programming in Python and to deploy Python-based educational simulations), based on the needs and feedback of people who actually use Python in education.
--Paul Fernhout
Yeah, pretty much what edu-sig has always been about, in large degree. What's changed recently is the PataPata flood. I'm not complaining: all this inventorying of graphical libraries has been useful. I feel much more informed than when we got started. Keep up the good work. Kirby
participants (5)
-
Andre Roberge -
Brad Miller -
francois schnell -
kirby urner -
Paul D. Fernhout