[Edu-sig] PySqueak: more on the cultural divide among paradigms

[Dethe Elza]

[snip]

John Zelle wrote:
> I've been thinking about just this sort of project.

That's a relief, sometimes I think I'm the only one thinking in this direction.

> My hunch is that a Vpython
> in Python is now very doable using PyOpenGL. By building on OpenGL, most of
> the heavy graphics lifting can be done on the graphics card (even cheap ones
> are ridiculously fast these days). The OpenGL API is now standardized and
> stable for development, as long as one sticks to basic features for which
> hardware acceleration can be taken as a given.
>
> But OpenGL is not a modeling API, it's purely for drawing things. We need a
> higher-level standardized scene graph layer (ala VPython). This combination
> would make the entire graphics stack down to hardware Python based. VPython
> as it stands is very nice, but it is not extendable in Python. Want a more
> realistic shading model? No can do. Texture mapping? Out of luck.
> Stereo-modes? (well OK, but I had to do that in C++ ;-).  It might be that
> something like the PyOpenGL Context code base could be used as a starting
> point.

Yes, these are exactly the issues I run into with VPython (that, and
having to run it on OS X in linux-emulation mode).

> Along-side the modeling layer we need a good OpenGL-based gui toolkit as well.
> You really can't build a decent GUI in something like VPython.  It would be
> nice if solid, good-looking applications could be built entirely on Python
> w/o having to introduce some other C/C++ dependencies.  Relying only on
> OpenGL would give us a truly portable GUI kit (except for a very thin layer
> that glues it to the underlying windowing system ala GLUT). It could have a
> consistent, though not necessarily native look and feel anywhere OpenGL runs.
> I'm willing to give up native look and feel provided the toolkit looks great
> and has really snappy performance. Another approach would be to make the GUI
> themeable, so folks could easily implement themes to mimick standard native
> widget sets. Basing on OpenGL should provide these abilities. The entire
> X-library has now been impelemented on OpenGL, there's no reason in principle
> a decent OO gui framework couldn't also be built there (and there are already
> some candidates out there to use as models).

By making VPython play well with other OpenGL-based systems we should
be able to get this "for free" or nearly so.  For one thing, The 2D
system Cairo has an OpenGL backend called Glitz, and folks are
definitely using Cairo to build GUIs.

> > I know I'd love to have a 3D environment that was both easy to use,
> > and extensible.
>
> Exactly. I agree that Vpython in Python would be a great start.

Yeah!

> To me, it seems that a 2D/3D persistent scene-graph API  paired with a GUI
> toolkit, both based on PyOpenGL is the obvious first step toward this goal.
> Alone, it would not really be very Squeak-like, but a Squeaky IDE needs the
> ability to describe a persisitent view (2D or 3D) as a basic starting point.
> On top of that foundation others can build the ultimate constructivist
> educational platform...or just some neat, useable 2D and 3D applications.
> Others could work on extending and improving the whole shebang without having
> to know any C or C++.
>
> The only question in my mind is how do we get started in making this vision a
> reality? I'd love to dive in and start working on it myself, but
> realistically, I've already got a lot of committments (writing is *$&% hard
> work :-). Where do we go from here? Ideas Dethe?

I have taken a stab at reimplementing VPython in PyOpenGL, but ran out
of motivation. I have some outstanding time committments for my
hobby-coding time for the next month or so, but would be willing to
take this up again.  Certainly the OpenGL context work would make a
good starting point, at least for tips and examples, even if the final
result was not built on that.  There is also an open-source X3D engine
which might be useful for an example state machine.  One of the
reasons I periodically get excited about Python bindings to 3D engines
like Blender, Ogre, Panda3d, etc., is that I hope that they will
provide a better basis to build a new, inclusive VPython on than raw
OpenGL, but I think that is just wishful thinking and I should roll up
my sleeves and Just Do It.

> By the way, how is the non-Fink port of Vpython for OSX going? We could really
> use that right now. My Mac students don't want to mess with Fink just to do a
> few Vpython projects.

Their build system defeated me.  I finally gave in and installed the
Fink version, which pulls in Gnome, among other things (632 MB to
access the OpenGL that is *built in* to OS X).  It took many hours to
install, requires X, and brings my system to a crawl when I use it.  I
think my time might be better used porting it to Python than trying to
fix their autoconf-and-Boost madness.  As you say, simplicity is what
makes VPython shine, and the system doesn't actually do all that much.
It's a shame that the simplicity ends when you try to build it.

--Dethe

>
> --
> John M. Zelle, Ph.D.             Wartburg College
> Professor of Computer Science    Waverly, IA
> john.zelle at wartburg.edu          (319) 352-8360
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>