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