Nows the time

Development
1

Hello Geoff

After this past week Avogadro is pretty sweet working. I spent a bit of
time doing the logic for the drawing tool and it seems to work pretty
well. It isn’t ROCK SOLID as i’d like it to be but there shouldn’t be
any segfaults.

The biggest issue I have is that when a plugin / tool changes anything
there needs to be an update. Right now i have it setup so that any
primitive Atom / Bond / Residue has an update() function that sends a
signal to it’s parent (in our case Molecule). I use the term Molecule
and Model as synonyms. When an atom is added it sends a signal and
right before being deleted it sends a signal. The problem is that
whenever data changes it’s up to the person changing the data to send
the update call. Now this is good and bad. It’s good because say i
update a vector and the atom index. For optimization sake i don’t
really want to make TWO update calls, i just need one. On the other
hand it means that widgets and the GL don’t get updated until this
happens.

You can also do an update() on the molecule. Right now i have this
setup so that in our GL it updates everything and in our TreeView it
updates everything. When i say it updates everything, it doesn’t
rebuild the data, it just updates the display of every item. We assume
that whenever addition / deletion happens then the widget is aware of
this.

Eventually it will be great with the update thing to optimize our GL
stuff. Most notably we would only need to update display lists for
items that have changed. This is in the future. I know Benoit is
concerned about it but it’s just not something I can do right now.

Anyways, libavogadro will get bigger as we need it. But the GLWidget
and the MoleculeTreeView widgets both are part of the library. Right
now the MoleculeTreeView has no signals that we are concerned about.
Eventually it will have some like primitiveSelected() or something like
that. We’ll tackle that when we get to context menus and
primitiveProperties and things like that.

So this long email is just for you guys, when you have a chance, to pull
down the source and compile it. There are few “known” bugs; the biggest
is that you need to set “AVOGADRO_TOOLS=/tools” else it
segfaults. I haven’t figured that out. Geoff, on Mac i think you can
export AVOGADRO_ENGINES=/engines and that should get your
engines. Happy Hunting.

-Donald

2

Great work, Donald! (though I haven’t yet found time to check it out)

Eventually it will be great with the update thing to optimize our GL
stuff. Most notably we would only need to update display lists for
items that have changed. This is in the future. I know Benoit is
concerned about it but it’s just not something I can do right now.

It’s true that I’m concerned about how many FPS you get, but not so much about
that, for two reasons:

First, this doesn’t affect FPS, as you only have to update objects as a result
of a particular user interaction. So this can only possibly be a UI latency
issue, not a FPS issue (yes, UI latency is also very important - but in my
experience this has never been noticeable in kalzium 3d, though it might
become noticeable if you do more complex things in avo).

Second, anyway, looking at the setup() method in Sphere and Cylinder:

void Sphere::setup( int detail )
{
if( detail == m_detail ) return;
m_detail = detail;
initialize();
}

As you see the first line with the if() prevents unnecessary recomputations.
So you can call setup() as often as you like without making checks.

Benoit