[Edu-sig] PySqueak: pyGTK & Cairo & pygtkglext (OpenGL) next?
Paul D. Fernhout
pdfernhout at kurtz-fernhout.com
Sat Jun 3 20:19:10 CEST 2006
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
But from a free software perspective,
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).
[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,
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
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).
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
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
in the edusig thread discussing PySqueak implementation ideas:
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#
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.
because it is designed in a way to make it back-end neutral.
And there is an experimental Cairo port as a backend:
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)?
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
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
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:
leading mainly to:
"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
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
"The Paradox of Choice: Why More Is Less"
and "The Tyranny of Freedom"
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.
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
> 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.
More information about the Edu-sig