QMessageBoxEx

Development
1

Dear All
I am getting alway some trouble with the new QMessageBoxEx
Which version of Qt 4.x is supssed to include this class. qt from kde svn
does not include the header and also the 4.2.0-rc1 version

I have been studying avogadro code this weekend and trying to implement
multistructure support, so basicallIy I added some methods

Molecule* getCurrentMolecule() {
return _molecules.at(_currentmoleculeindex);
}

QList<Molecule*> getMolecules() { return _molecules

private
QList<Molecule*> _molecules; //replaing _molecule

However I find inheritance scheme too complicated, I think things will be
easier if i could simply code

for(it=_molecules.begin();it!=_molecules.end();++it)
{
currentEngine->render(*it);
}

Without having to deal with this view class, in fact I dont understand very
well the purpose of these class, should not be inside Engine class and not
Molecule ?

Dr. Armando Navarro Vázquez
http://desoft03.usc.es/armando
RIAIDT. Universidade de Santiago de Compostela

2

I am getting alway some trouble with the new QMessageBoxEx
Which version of Qt 4.x is supssed to include this class. qt from
kde svn
does not include the header and also the 4.2.0-rc1 version

This seems to have been added in the 4.2 development but has now gone
back to QMessageBox as of the rc1 version. I haven’t found any
information on the change.

I have been studying avogadro code this weekend and trying to
implement
multistructure support, so basicallIy I added some methods

Oh, great!

Without having to deal with this view class, in fact I dont
understand very
well the purpose of these class, should not be inside Engine class
and not
Molecule ?

Well, Donald would be the best one to answer this question. I believe
they’re required to allow custom rendering options (e.g., since one
molecule may be rendered multiple ways – wireframe for atoms and
bonds, and another view/render for the residue backbone).

My original design document for Avogadro suggested that the editor
itself should concentrate on a “one molecule at a time” view. Then to
handle multiple molecules, there’s a separate window(?) which allows
you to switch through a multi-molecule file. This other window would
have small 2D or 3D views of the separate molecules.

What do you think? I haven’t had a chance yet to get KryoMol working
on my Mac yet, although I did grab the code. Like Benoit, I’ve been
working on libraries (i.e., Open Babel 2.1).

Cheers,
-Geoff

3

(Tue, Sep 26, 2006 at 09:03:31AM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:

Without having to deal with this view class, in fact I dont
understand very
well the purpose of these class, should not be inside Engine class
and not
Molecule ?

Well, the last modifications i made changed this to a new “queue” type
system. You should see in the code now (and for the ball and stick
engine) that there is a function Engine::render(PrimitiveQueue *q) which
allows the engine to render; in linear time, all the primitives it
should render.

The GLWidget itself has a queue for each engine plus a queue for the
default engine. This way we can put primitives in multiple queues etc
(ie. when i want to render an atom and also render the residue sphere).
If that doesn’t make sense i’ll try to make it more clear.

I basically implemented the queue system and haven’t had the chance to
make the appropriate changes to all the Engines. But be assured, the
View classes are out for now. We are still sorta tossing around ideas
about how we want the rendering code to work. The View classes were my
first attempt at allowing for customizable rendering option for each
primitive.

I would suggest checking out the newest svn; rev. 62 and check out the
new queue type system. I believe it’s the best we have so far
especially considering optimization of GL rendering which is something
we are extremely concerned about.

My original design document for Avogadro suggested that the editor
itself should concentrate on a “one molecule at a time” view. Then to
handle multiple molecules, there’s a separate window(?) which allows
you to switch through a multi-molecule file. This other window would
have small 2D or 3D views of the separate molecules.

Well, eventually i’d like to see animation and loading of multiple
molecules per window (contained in a single file). I think the
restraint is “one file per window” which normally ammounts to one
molecule. I don’t think that it would be hard to implement either.
Like Geoff has said; think photoshop / gimp style. Of course we arent’
tyring to rip that off but we’re definatly trying to make the interface
similar so it is intuitive.

What do you think? I haven’t had a chance yet to get KryoMol working
on my Mac yet, although I did grab the code. Like Benoit, I’ve been
working on libraries (i.e., Open Babel 2.1).

I’m in the same boat. I’ve been working on some updates to Ghemical and
a research presentation. The next natural progression (as i’m so far
happy with the rendering setup) is to build the tool interface and start
getting our tool plugins going (drawing / erasing / etc etc).

Hope this helps,
Donald

4

Good, I will check this new version

Respect to the multimolecule think, I think that is better to have
multimolecule support in the core library, since otherwise would be difficult
to implement in the derived classes. I think this is necessary to handle
basic things like molecule superpotition, docking and others.
For instance my idea is to derive KryoMol for KDE 4 from Avogadro core visor,
and reimplement some things to be able to modify molecule.

By the way I have already written a Tree Visor for multistructure support for
another project I have, I think this is somenthing similar to wich Geoffrey
wants. It renders small thumbnails of molecules and when you move the mouse
over the thumbnail a small GL widget open, like a tooltip and you can zoom,
rotate etc. inside this Widget,

(Tue, Sep 26, 2006 at 09:03:31AM -0400) Geoffrey Hutchison
geoff.hutchison@gmail.com:

Without having to deal with this view class, in fact I dont
understand very
well the purpose of these class, should not be inside Engine class
and not
Molecule ?

Well, the last modifications i made changed this to a new “queue” type
system. You should see in the code now (and for the ball and stick
engine) that there is a function Engine::render(PrimitiveQueue *q) which
allows the engine to render; in linear time, all the primitives it
should render.

The GLWidget itself has a queue for each engine plus a queue for the
default engine. This way we can put primitives in multiple queues etc
(ie. when i want to render an atom and also render the residue sphere).
If that doesn’t make sense i’ll try to make it more clear.

I basically implemented the queue system and haven’t had the chance to
make the appropriate changes to all the Engines. But be assured, the
View classes are out for now. We are still sorta tossing around ideas
about how we want the rendering code to work. The View classes were my
first attempt at allowing for customizable rendering option for each
primitive.

I would suggest checking out the newest svn; rev. 62 and check out the
new queue type system. I believe it’s the best we have so far
especially considering optimization of GL rendering which is something
we are extremely concerned about.

My original design document for Avogadro suggested that the editor
itself should concentrate on a “one molecule at a time” view. Then to
handle multiple molecules, there’s a separate window(?) which allows
you to switch through a multi-molecule file. This other window would
have small 2D or 3D views of the separate molecules.

Well, eventually i’d like to see animation and loading of multiple
molecules per window (contained in a single file). I think the
restraint is “one file per window” which normally ammounts to one
molecule. I don’t think that it would be hard to implement either.
Like Geoff has said; think photoshop / gimp style. Of course we arent’
tyring to rip that off but we’re definatly trying to make the interface
similar so it is intuitive.

What do you think? I haven’t had a chance yet to get KryoMol working
on my Mac yet, although I did grab the code. Like Benoit, I’ve been
working on libraries (i.e., Open Babel 2.1).

I’m in the same boat. I’ve been working on some updates to Ghemical and
a research presentation. The next natural progression (as i’m so far
happy with the rendering setup) is to build the tool interface and start
getting our tool plugins going (drawing / erasing / etc etc).

Hope this helps,
Donald

–
Dr. Armando Navarro-Vázquez
RIAIDT. Univdade de Resonancia Magnetica
Universidade de Santiago de Compostela
http://desoft03.usc.es/armando/index.html