Project

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

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

It’s also not GPL. Granted, you can use it free as much as you want;
but it still has a weird license.

I haven’t done any of GL coding before so I think in my free time (what
little there is) i might try to dig up some info on it.

On Apr 18, 2006, at 2:30 PM, Donald Ephraim Curtis wrote:

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

It’s also not GPL. Granted, you can use it free as much as you
want; but it still has a weird license.

Yes, it’s completely GPL. It happens to also have a commercial
license if you want to develop non-GPL’ed code–that obviously
doesn’t apply in our case. At one point it wasn’t under the GPL,
but the developers decided there was no problem with offering it
under the GPL as well.
http://www.trolltech.com/developer/faqs/index.html?
catid=1953&id=191#answer

I think it looks great – the documentation is much better than
wxWidgets or GTKmm:
http://doc.trolltech.com/4.1/index.html

I’m willing to use whatever toolkit seems to make the most sense – I
certainly have more experience working with GTK than the others. But
having looked at the development docs and demos for each, I think Qt
is great.

I haven’t done any of GL coding before so I think in my free time
(what little there is) i might try to dig up some info on it.

It’s not so hard – the Ghemical code actually has some nice examples
of doing OpenGL work. Also, most of the widget sets we’ve described
have OpenGL examples. The beauty is that if the code design is done
right, the OpenGL bits are all in one place and much of the work
(e.g. GUI) doesn’t need to care.

Cheers,
-Geoff

Yes, it’s completely GPL. It happens to also have a commercial license
if you want to develop non-GPL’ed code–that obviously doesn’t apply in
our case. At one point it wasn’t under the GPL, but the developers
decided there was no problem with offering it under the GPL as well.
http://www.trolltech.com/developer/faqs/index.html?catid=1953&id=191#answer

wow, nice. i haven’t been keeping up. totally a good move for them.

I think it looks great – the documentation is much better than
wxWidgets or GTKmm:
http://doc.trolltech.com/4.1/index.html

I’m willing to use whatever toolkit seems to make the most sense – I
certainly have more experience working with GTK than the others. But
having looked at the development docs and demos for each, I think Qt is
great.

I tend to be more of a fan of the “look” of GTK but as far as the
toolkit goes; it’s C and not as immediately portable. It depends on
how much one cares about native support etc.

Looking through the GTKmm FAQ and documentation it looks pretty good.
Like you said, not AS well documented. I’m looking into re-writing
GTK-GAMESS so that it’s GTK2 so maybe i’ll give gtkmm a chance and see
how it comes. I’m still coming around to C++. OO is nice but i love
the rawness of C :slight_smile: ok i think this is enough e-mails for today. take
it easy…