visualpython-users

[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

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
>
>
>   

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

[Bruce S. <Bru...@nc...>]

I'm pretty swamped at the moment with finishing a textbook and can't 
give as good a response as I'd like, but I'll say very quickly that even 
being very careful to be as efficient as possible in C++ it's quite easy 
to get poor performance with VPython if you have lots of objects. What 
VPython does is quite difficult and time-critical.

And a quick comment on pyGTK: Many cross-platform schemes were 
attempted, and none was found adequate for building Visual on Windows, 
Mac, and Linux. That doesn't mean that it's not possible, only that the 
developers did try and didn't succeed. Maybe someone else will step 
forward and make a big improvement.

Bruce Sherwood

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
>   

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

[Bruce S. <Bru...@nc...>]

I asked David Scherer for an expert response to this question. Here's 
what he said:

"The question is whether some or all of the platform-specific window 
handling code could be written in Python.  The answer to this question 
is, I think, yes - as you may recall, I did some experimentation with 
that myself (in the context of a Mac port, and of eventually supporting 
visual widgets for windowing libraries).  The performance effect is not 
necessarily significant for the simple reason that things like display 
and mouse handling only do O(1) work per frame, while the heavy lifting 
is already in platform-independent C++.  On the other hand, the 
"productivity" benefit is not so clear either because the low level 
platform-specific APIs for windowing are usually not exposed or 
documented very well in Python, or are exposed only through optional 
libraries that are heavy dependencies, or are wrapped in higher level 
libraries that make some decisions inappropriate for Visual.  I think 
that, on balance, keeping the platform-specific code in C++ was the 
right decision for the "big three" platforms, but this decision could 
certainly be revisited in the future (especially for Linux, where 
dependency hell is socially acceptable).  More to the point, however, 
Python display implementations could be an excellent way of supporting 
edge cases like this one (displaying as part of a window managed by 
another library).

The Python display implementation I wrote is in the CVS history at 
/vpython-core2/site-packages/visual/pyglet.py, with "show dead files":

 http://visualpython.cvs.sourceforge.net/viewvc/visualpython/vpython-core2/site-packages/visual/?hideattic=0 


It makes a display window based on the pyglet library.  It probably 
won't work unmodified because of various changes made to visual since I 
stopped working on it, and I doubt it was ever full featured (e.g. no 
keyboard support), but it would be a good starting point for anyone 
experimenting in this area.  I would think someone could develop a 
wxwindows "visual widget" relatively easily, though there are surely 
traps for the unwary."

Bruce Sherwood

P.S. If I remember correctly, this particular approach using pyglet was 
abandoned in part because it didn't just immediately work on all platforms.

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
>   

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

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

Thank you Bruce for such prompt answers.  It sounds like I need to keep 
digging through the code and understand how it works better.  David's 
link at an old attempt gives me some hope that it might work.

JT

Bruce Sherwood wrote:
> I asked David Scherer for an expert response to this question. Here's 
> what he said:
>
> "The question is whether some or all of the platform-specific window 
> handling code could be written in Python.  The answer to this question 
> is, I think, yes - as you may recall, I did some experimentation with 
> that myself (in the context of a Mac port, and of eventually supporting 
> visual widgets for windowing libraries).  The performance effect is not 
> necessarily significant for the simple reason that things like display 
> and mouse handling only do O(1) work per frame, while the heavy lifting 
> is already in platform-independent C++.  On the other hand, the 
> "productivity" benefit is not so clear either because the low level 
> platform-specific APIs for windowing are usually not exposed or 
> documented very well in Python, or are exposed only through optional 
> libraries that are heavy dependencies, or are wrapped in higher level 
> libraries that make some decisions inappropriate for Visual.  I think 
> that, on balance, keeping the platform-specific code in C++ was the 
> right decision for the "big three" platforms, but this decision could 
> certainly be revisited in the future (especially for Linux, where 
> dependency hell is socially acceptable).  More to the point, however, 
> Python display implementations could be an excellent way of supporting 
> edge cases like this one (displaying as part of a window managed by 
> another library).
>
> The Python display implementation I wrote is in the CVS history at 
> /vpython-core2/site-packages/visual/pyglet.py, with "show dead files":
>
>  http://visualpython.cvs.sourceforge.net/viewvc/visualpython/vpython-core2/site-packages/visual/?hideattic=0 
>
>
> It makes a display window based on the pyglet library.  It probably 
> won't work unmodified because of various changes made to visual since I 
> stopped working on it, and I doubt it was ever full featured (e.g. no 
> keyboard support), but it would be a good starting point for anyone 
> experimenting in this area.  I would think someone could develop a 
> wxwindows "visual widget" relatively easily, though there are surely 
> traps for the unwary."
>
> Bruce Sherwood
>
> P.S. If I remember correctly, this particular approach using pyglet was 
> abandoned in part because it didn't just immediately work on all platforms.
>
> 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
>>   
>>     
>
> ------------------------------------------------------------------------------
> 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
>   

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

[Michele M. <mat...@gm...>]

I think there is the need to be able to use visual as a widget for any toolkit.

In my specific case I'm using a GTK GUI, but as Jim as written, I'm
able to detect an input an process the return value only if I leave
the main thread of the gtk gui and enter a while loop, until I return
the value back and get back into the main gtk loop.

This of course cause a lot of busy waiting, consuming the CPU and
offering a bad user experience.

If I understood correctly this was done before somehow...

Is that true?

On Tue, Jul 21, 2009 at 9:02 PM, Jim Thomas<jt...@mi...> wrote:
> Thank you Bruce for such prompt answers.  It sounds like I need to keep
> digging through the code and understand how it works better.  David's
> link at an old attempt gives me some hope that it might work.
>
> JT
>
> Bruce Sherwood wrote:
>> I asked David Scherer for an expert response to this question. Here's
>> what he said:
>>
>> "The question is whether some or all of the platform-specific window
>> handling code could be written in Python.  The answer to this question
>> is, I think, yes - as you may recall, I did some experimentation with
>> that myself (in the context of a Mac port, and of eventually supporting
>> visual widgets for windowing libraries).  The performance effect is not
>> necessarily significant for the simple reason that things like display
>> and mouse handling only do O(1) work per frame, while the heavy lifting
>> is already in platform-independent C++.  On the other hand, the
>> "productivity" benefit is not so clear either because the low level
>> platform-specific APIs for windowing are usually not exposed or
>> documented very well in Python, or are exposed only through optional
>> libraries that are heavy dependencies, or are wrapped in higher level
>> libraries that make some decisions inappropriate for Visual.  I think
>> that, on balance, keeping the platform-specific code in C++ was the
>> right decision for the "big three" platforms, but this decision could
>> certainly be revisited in the future (especially for Linux, where
>> dependency hell is socially acceptable).  More to the point, however,
>> Python display implementations could be an excellent way of supporting
>> edge cases like this one (displaying as part of a window managed by
>> another library).
>>
>> The Python display implementation I wrote is in the CVS history at
>> /vpython-core2/site-packages/visual/pyglet.py, with "show dead files":
>>
>>  http://visualpython.cvs.sourceforge.net/viewvc/visualpython/vpython-core2/site-packages/visual/?hideattic=0
>>
>>
>> It makes a display window based on the pyglet library.  It probably
>> won't work unmodified because of various changes made to visual since I
>> stopped working on it, and I doubt it was ever full featured (e.g. no
>> keyboard support), but it would be a good starting point for anyone
>> experimenting in this area.  I would think someone could develop a
>> wxwindows "visual widget" relatively easily, though there are surely
>> traps for the unwary."
>>
>> Bruce Sherwood
>>
>> P.S. If I remember correctly, this particular approach using pyglet was
>> abandoned in part because it didn't just immediately work on all platforms.
>>
>> 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
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

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

[Chris C. <scc...@gm...>]

Rather than a full port, why not just provide a hook where the user
can give visual an opengl context to draw on? In otherwords, have a
public 'display object' where the user can set the opengl context
either through a method call, or attribute access. Then the user could
just, for example, create a wx opengl context and pass that object to
visual to draw on. (this is how one uses pyglet from wx btw).

This is not all too different from how traits allows the user to
select either the wx or qt backend.

Cheers,

Chriscrap, i keep forgetting to hit reply to all... sorry:


On Thu, Jul 23, 2009 at 10:55 AM, Michele Mattioni<mat...@gm...> wrote:
> I think there is the need to be able to use visual as a widget for any toolkit.
>
> In my specific case I'm using a GTK GUI, but as Jim as written, I'm
> able to detect an input an process the return value only if I leave
> the main thread of the gtk gui and enter a while loop, until I return
> the value back and get back into the main gtk loop.
>
> This of course cause a lot of busy waiting, consuming the CPU and
> offering a bad user experience.
>
> If I understood correctly this was done before somehow...
>
> Is that true?
>
> On Tue, Jul 21, 2009 at 9:02 PM, Jim Thomas<jt...@mi...> wrote:
>> Thank you Bruce for such prompt answers.  It sounds like I need to keep
>> digging through the code and understand how it works better.  David's
>> link at an old attempt gives me some hope that it might work.
>>
>> JT
>>
>> Bruce Sherwood wrote:
>>> I asked David Scherer for an expert response to this question. Here's
>>> what he said:
>>>
>>> "The question is whether some or all of the platform-specific window
>>> handling code could be written in Python.  The answer to this question
>>> is, I think, yes - as you may recall, I did some experimentation with
>>> that myself (in the context of a Mac port, and of eventually supporting
>>> visual widgets for windowing libraries).  The performance effect is not
>>> necessarily significant for the simple reason that things like display
>>> and mouse handling only do O(1) work per frame, while the heavy lifting
>>> is already in platform-independent C++.  On the other hand, the
>>> "productivity" benefit is not so clear either because the low level
>>> platform-specific APIs for windowing are usually not exposed or
>>> documented very well in Python, or are exposed only through optional
>>> libraries that are heavy dependencies, or are wrapped in higher level
>>> libraries that make some decisions inappropriate for Visual.  I think
>>> that, on balance, keeping the platform-specific code in C++ was the
>>> right decision for the "big three" platforms, but this decision could
>>> certainly be revisited in the future (especially for Linux, where
>>> dependency hell is socially acceptable).  More to the point, however,
>>> Python display implementations could be an excellent way of supporting
>>> edge cases like this one (displaying as part of a window managed by
>>> another library).
>>>
>>> The Python display implementation I wrote is in the CVS history at
>>> /vpython-core2/site-packages/visual/pyglet.py, with "show dead files":
>>>
>>>  http://visualpython.cvs.sourceforge.net/viewvc/visualpython/vpython-core2/site-packages/visual/?hideattic=0
>>>
>>>
>>> It makes a display window based on the pyglet library.  It probably
>>> won't work unmodified because of various changes made to visual since I
>>> stopped working on it, and I doubt it was ever full featured (e.g. no
>>> keyboard support), but it would be a good starting point for anyone
>>> experimenting in this area.  I would think someone could develop a
>>> wxwindows "visual widget" relatively easily, though there are surely
>>> traps for the unwary."
>>>
>>> Bruce Sherwood
>>>
>>> P.S. If I remember correctly, this particular approach using pyglet was
>>> abandoned in part because it didn't just immediately work on all platforms.
>>>
>>> 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
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

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

[Michele M. <mat...@gm...>]

Hi All,

With the new Ipython (0.10) and the new pygtk it seems I'm unable to run
visual and pygtk at the same time. Because I really like visual high level
API to draw OpenGL graphics I was wondering if there is this interest in
trying to rewrite the gtk part using pygtk or modify it so it will be easier
to integrate visual in bigger program.

Anybody has some attempt that works?

Regards,
Michele.


On Thu, Jul 23, 2009 at 5:09 PM, Chris Colbert <scc...@gm...> wrote:

> Rather than a full port, why not just provide a hook where the user
> can give visual an opengl context to draw on? In otherwords, have a
> public 'display object' where the user can set the opengl context
> either through a method call, or attribute access. Then the user could
> just, for example, create a wx opengl context and pass that object to
> visual to draw on. (this is how one uses pyglet from wx btw).
>
> This is not all too different from how traits allows the user to
> select either the wx or qt backend.
>
> Cheers,
>
> Chriscrap, i keep forgetting to hit reply to all... sorry:
>
>
> On Thu, Jul 23, 2009 at 10:55 AM, Michele Mattioni<mat...@gm...>
> wrote:
> > I think there is the need to be able to use visual as a widget for any
> toolkit.
> >
> > In my specific case I'm using a GTK GUI, but as Jim as written, I'm
> > able to detect an input an process the return value only if I leave
> > the main thread of the gtk gui and enter a while loop, until I return
> > the value back and get back into the main gtk loop.
> >
> > This of course cause a lot of busy waiting, consuming the CPU and
> > offering a bad user experience.
> >
> > If I understood correctly this was done before somehow...
> >
> > Is that true?
> >
> > On Tue, Jul 21, 2009 at 9:02 PM, Jim Thomas<jt...@mi...>
> wrote:
> >> Thank you Bruce for such prompt answers.  It sounds like I need to keep
> >> digging through the code and understand how it works better.  David's
> >> link at an old attempt gives me some hope that it might work.
> >>
> >> JT
> >>
> >> Bruce Sherwood wrote:
> >>> I asked David Scherer for an expert response to this question. Here's
> >>> what he said:
> >>>
> >>> "The question is whether some or all of the platform-specific window
> >>> handling code could be written in Python.  The answer to this question
> >>> is, I think, yes - as you may recall, I did some experimentation with
> >>> that myself (in the context of a Mac port, and of eventually supporting
> >>> visual widgets for windowing libraries).  The performance effect is not
> >>> necessarily significant for the simple reason that things like display
> >>> and mouse handling only do O(1) work per frame, while the heavy lifting
> >>> is already in platform-independent C++.  On the other hand, the
> >>> "productivity" benefit is not so clear either because the low level
> >>> platform-specific APIs for windowing are usually not exposed or
> >>> documented very well in Python, or are exposed only through optional
> >>> libraries that are heavy dependencies, or are wrapped in higher level
> >>> libraries that make some decisions inappropriate for Visual.  I think
> >>> that, on balance, keeping the platform-specific code in C++ was the
> >>> right decision for the "big three" platforms, but this decision could
> >>> certainly be revisited in the future (especially for Linux, where
> >>> dependency hell is socially acceptable).  More to the point, however,
> >>> Python display implementations could be an excellent way of supporting
> >>> edge cases like this one (displaying as part of a window managed by
> >>> another library).
> >>>
> >>> The Python display implementation I wrote is in the CVS history at
> >>> /vpython-core2/site-packages/visual/pyglet.py, with "show dead files":
> >>>
> >>>
> http://visualpython.cvs.sourceforge.net/viewvc/visualpython/vpython-core2/site-packages/visual/?hideattic=0
> >>>
> >>>
> >>> It makes a display window based on the pyglet library.  It probably
> >>> won't work unmodified because of various changes made to visual since I
> >>> stopped working on it, and I doubt it was ever full featured (e.g. no
> >>> keyboard support), but it would be a good starting point for anyone
> >>> experimenting in this area.  I would think someone could develop a
> >>> wxwindows "visual widget" relatively easily, though there are surely
> >>> traps for the unwary."
> >>>
> >>> Bruce Sherwood
> >>>
> >>> P.S. If I remember correctly, this particular approach using pyglet was
> >>> abandoned in part because it didn't just immediately work on all
> platforms.
> >>>
> >>> 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
> >>>>
> >>>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> 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
> >>>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Visualpython-users mailing list
> >> Vis...@li...
> >> https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >>
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
>