[Kalzium] Molecular Viewer Bug

[Johannes Simon]

> Let's find out why. Edit the body of this method: void Color::set(const 
> OpenBabel::OBAtom *atom) add add qDebug()'s to see what's going on. Is the 
> if(!atom) exiting the method prematuredly? If not, can you check the 
> std::vector rgb returned by OpenBabel?
Same colors there: m_red = 0, m_green = 0, m_blue = 0, m_alpha = 1.
I also checked atom->GetAtomicNum() which it passes to etab.getRGB(),
and I found that it is the correct atomic number. So I took a look into
the openbabel source code, src/data.cpp in the openbabel tree, to be
exactly, and there I found this in OBElementTable::GetRGB(int
atomicnum):

if (atomicnum < 0 || atomicnum > static_cast<int>(_element.size()))
   {
     colors.push_back(0.0);
     colors.push_back(0.0);
     colors.push_back(0.0);
     return(colors);
   }
So I had openbabel output _element.size() which is 117, so this does not
seem to be the problem. After all, I should have added more debug
output, but it simply takes to long to compile to play with it to find
out where it starts returning wrong numbers.

> > Changing m_red (or m_gree,m_blue,m_alpha)
> > at the beginning of applyAsMaterials() doesn't make any difference at all.
> 
> Uh, now that's strange. setting m_red to 1 should make a visual 
> difference (everything should look more red, at least not black)! If it 
> doesn't, that's a separate bug. I prefer to believe that we 
> didn't understand each other.
Ok, my bad. For some reason, the changes just didn't take into effect
last time I recompiled Kalzium. Now it does show me some white sticks,
but no actual atoms after all.

Joh