Re: [Visualpython-users] Not Enough Python in VPython?

[Stef M. <s.m...@ru...>]

hi Jim,
if the main goal is to embed the VPython window in your own GUI,
why not just dock the VPython window in your own GUI ?
cheers,
Stef

Jim Thomas wrote:
> 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
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>
>