Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[C A. R. <an...@ex...>]

On Thu, Oct 7, 2010 at 6:58 PM, Lenore Horner <lh...@si...> wrote:
> From my perspective of wanting to use Visual to let physics students work with problems
> they can't solve analytically (at least not at their math level), having to start off with one line
> of "this gives us access to the tools we need" rather than 5 or 10 lines of the same makes a
> lot of sense.  I'm NOT teaching programming in that case.

And that is understandable, but it only works for a single use case:
Visual as a standalone tool, in it's own environment.  While this may
indeed be the prevalent use case at the moment, a narrow focus here is
really going to cripple Visual's appeal to other avenues and
developers who may later hack on the core; students are *never* going
to help make Visual itself any better, and lack of a stable
library/API make it a moving target for integrators.

Since it's clear that the "visual" namespace is frozen, I really think
we just need to create a new package, say "libvisual", whose focus is
to be agnostic to how it's being used, and as flexible as possible.
then...

> All of the import and scene creation stuff is noise that we have to get past to get to the
> modeling.  I admit I'm trying to have my cake and eat it too.  I like the output and scene
> control available in visual better than in the Easy Java Simulation program but I'd like to
> minimize the programming aspects the way EJS does.

"visual", if following the above, will eventually be reduced to a
meeting ground of various tools being imported from libvisual, numpy,
etc., and will barely do _anything_ itself.  All functionality will be
encompassed by the library python module [libvisual], which itself
will interact with the C (or is it C++) module.

You could then go ballistic adding convenience functions and whatnot,
like quickstart(), to build a scene, etc., without affecting
integrators, and without affecting the stable-esque API of libvisual.

This was why I originally suggested something like:

from visual.presets.physics import *

or similar, as then there would be an actual namespace to put various
"shortcut" modules to build preconfigured environments, and it's a
small change compared to what's currently done; though I don't know
how much demand there would be for something like this.

> For me, Visual is a modeling tool not a programming tool.

For me, it's a generic tool for rendering and controlling 3D
environments in a natural and intuitive way from Python.  In my
far-from-finished-on-the-back-burner-for-now-data-aggregation-tool,
Visual is simply part of a plugin that could render real-time data to
a 3D environment; the tool itself uses SSH libraries, protocol
buffers, other GUI libraries, and a smattering of other utilities.
Visual was so cool; within a couple days and far less code, I had a
clone of gltail (http://www.fudgie.org/), since I didn't have to deal
with OpenGL directly.

Anyway, I'm just trying to stress that (IMO) the focus should be on a
building a quality 3D graphics python library, reusable by anyone in a
variety of capacities; the other stuff is icing on said cake.

C Anthony