[Edu-sig] PySqueak: pyGTK & Cairo & pygtkglext (OpenGL) next?

[Paul D. Fernhout]

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.