OK… I’m going to reply on the avogadro list to keep this archived.
so from what i’ve seen of openbabel; it’s already got a great
backend for molecules and such. however, like you were saying
there are a lot of primitives.
Yes, I think basing on Open Babel for the molecule bits has a lot of
advantages – obviously I also know the code and can thus use it
effectively. OB also already has access to Perl and Python for
“plugins.”
And of course, if the editor is under the GPL, we can also share some
of the Ghemical code if we like.
I think in your talking about rendering, the individuals should
render themselves, being C++ classes, maybe based off the object
sub-class.
Well, I thought long and hard about this. The problem is that
chemists like many different rendering views. For example, in
Ghemical, there’s wireframe, balls and sticks, spheres, cylinders…
and sometimes it’s nice to have a mix of these… So I don’t think
the atoms and bonds should have code to render themselves, actually.
If someone wants to add a new rendering view (e.g., 2D circles or
something) then each primitive needs the new rendering code.
So I think the rendering architecture should have two bits:
- A rendering queue (i.e., what needs to be updated) → OpenGL /
screen buffer - A set of render classes which accept certain primitives
So you’d have WireframeRenderer which accepts Atom, Bond, etc. You’d
have SurfaceRenderer which would accept electron density maps,
orbitals, etc.
An individual primitive (e.g., an atom) would have a reference to its
renderer and when needed would put itself and the renderer onto the
queue. This would also allow one atom (or set of atoms) to be viewed
as wireframe, while another was a big sphere. Each primitive keeps
track of any rendering options different from the defaults.
Maybe name it GLObject then you have GLAtom / GLBond… and so
then if you ever want to add a new primitive it would be easy to
just make it a subclass of GLObject (which would contain common
functions like render / delete etc etc).
Yes, this is good.
The thing i think would be good discussion is talking about
toolkits. I’d definitely say no java; even though it’s really
portable. Something like GTK is great, but i definitely would want
to go with GTKmm (the C++ implementation). What kind of GUI
programming do you feel comfortable with?
I see three possibilities:
- GTK / GTKmm
- Qt
- wxWidgets
I haven’t coded much with Qt, although it’s designed for C++ and
cross-platform. Reading through the documentation, it seems like it’s
reasonably well organized and has a much more obvious integration
with OpenGL. (e.g., saving the window pixmap to a file is about 2
calls).
Cheers,
-Geoff
P.S. QGLWidget.html::renderPixmap() => QPixmap::save()
ok i think this is enough e-mails for today. take