> 2 years ago I was involved with a project where we only
> wanted to use pymol as a rendering widget, but it was
> impossible. Our prototype used pymol's separate window, but I
> recommended that the project look for another solution
> because my impression was that the pymol project was more
> interested in being an application, and introducing new features.
That was true a couple years ago, but not so much anymore. Today,
heavily-resourced application efforts like Chimera, CCP4mg, and VIDA2
(not to forget VMD, Coot, and NOC) are successfully meeting many of the
needs that PyMOL was originally intended to address but never quite met.
The molecular graphics world has changed dramatically in six years, and
so much for the better!
I have no desire to see PyMOL become redundant, so we are steering
future development efforts toward a few well-defined niches:
(1) improved presentations and communications via PyMOL sessions and
shows,
(2) componentization of the PyMOL graphics code for easy embedding,
and
(3) sponsor-funded customization of the program to increase PyMOL
utility for big pharma and biotech, as well as universities.
> Glad to hear a "library" or "toolkit" usage will be a deliverable for
2.X.
Or much sooner, if you're willing to drive PyMOL from C.
Though PyMOL surely has an enduring future as an application, we are
committed to providing PyMOL molecular graphics to outside developers as
an object-oriented C library that can be embedded into Java,
ActiveX/.NET, Qt, Wx, Cocoa, or essentially any GUI framework that can
provide a native OpenGL rendering context along with mouse and keyboard
events.
At present, the C API is limited to a couple dozen core methods, but we
have been working with several groups to come up with a minimum
effective set. The PyMOL Java component: JyMOL (available for testing
upon request) is our first product based on this new API.
Ironically, the Python code now presents the toughest challenge. Though
the C portion of PyMOL (CMol) itself no longer has any state outside of
object instances, our Python API is still module-oriented and thus full
of global state. Getting ourselves out of that mess while maintaining
backward compatibility won't be easy, but we shall try! (in 2.x)
> (And, at least in 0.87,
> you couldn't dismiss the pymol window, because pymol insisted
> on terminating the whole application).
This was long-ago addressed with cmd.window("show") cmd.window("hide"),
and it is possible to furnish the "-z" option to start PyMOL with the
window hidden. The "window" method also enables the client to
dynamically resize and resposition the PyMOL window as needed (in
addition to doing so at startup via the command line). Thus, PyMOL 0.99
can fake being a component a whole lot better than 0.87 could, but you
are still limited to one PyMOL instance per process when using Python.
> The last time I used pymol was version 0.87, so the
> information below may very well be useless. Reader beware.
You can still "import pymol" to fire up a PyMOL instance in a parallel
thread.
Thank you for posting your experiences, Bob!
Cheers,
Warren
--
Warren L. DeLano, Ph.D.
Principal Scientist
. DeLano Scientific LLC
. 400 Oyster Point Blvd., Suite 213
. South San Francisco, CA 94080 USA
. Biz:(650)-872-0942 Tech:(650)-872-0834
. Fax:(650)-872-0273 Cell:(650)-346-1154
. mailto:war...@delsci.com
