[Visualpython-users] Not Enough Python in VPython?

[Jim T. <jt...@mi...>]

I'm sure I'm not alone in wishing that VPython would integrate better 
with our more full featured programs.  The best technique I've come up 
with so far is to put the visual code in a separate thread and use 
queues to talk between my python based (GUI) program and the visual code 
and it's standalone window.

I've been perusing the source code to see if there is a way to get 
visual to use a window I manage.  It seems it might be possible by 
rewriting display.cpp to use a passed GTK window handle/id to create the 
display and eliminating gui_main.  However I use wxPython which while 
based on GTK on linux, it uses native libraries on other platforms.  So 
that is not a great solution for me.

However there is a common denominator available with almost any decent 
GUI library -- OpenGL.  What I was thinking was this -- how critical is 
it that the 'GUI' portion of visual be implemented in C++?  From what I 
can tell, 0% of Visual Python is actually implemented in Python.  Why 
couldn't all the GTK portion of the library be implemented in pyGTK?  
Wouldn't that actually make development easier?  In my experience Python 
is up to 10x better from a development perspective.  I didn't see 
anything particularly performance critical in the GTK code side of 
things, did I miss something?  Implementing the library as a python GUI 
+ C++ OpenGL would make it possible to have alternate GUI front end 
options such as wxPython, or an expert mode with no default windows 
suitable for integrating with an existing GUI program.

Has this been considered before and tossed out as non-feasible?  Did I 
overlook something critical in the source code?  I have not spent lots 
of time yet but I am up for trying to do a proof of concept if it is not 
a known dead-end.  The other thing I was considering is trying to do a 
re-implementation in 100% python and then profiling to determine what 
portions if any should be moved into C++.  It seems to me that most of 
my calls to visual are during the model definition phase where 
performance is not really an issue.  Outside of re-positioning / 
re-orienting, relatively few functions are called every display loop.  
Are the locations of the bottlenecks already known?  Is this idea silly? 

I really like Visual Python from the point of view of ease of use of the 
library.  However there are serious limitations (perhaps unnecessarily 
so) once you move beyond demo programs and I fear that at some point I 
may be forced to 'graduate' to OpenGL.  I would love to see Visual as an 
easy way to start doing 3D (as it is now) and as your knowledge grows, 
remove the training wheels and have  a great way to do advanced things 
as well.

JT