Recent Changes

Development
1

If you haven’t been keeping up with svn commit logs, here are whats new;

: Tools & Extensions now return a QUndoCommand pointer (or null) which
is a command that performs and undoes whatever action the extension or
tool is doing. For the time being this should be only a concern for
tools/extensions that modify the Molecule, not the GLWidget.

: Tools now have an added ::paint function that allows them to paint to
the GLWidget on GL updates. This is needed for a few reasons. Try out
ratation with the navigate tool and see what you think. Looks really
cool.

: Paths & Environment variables have been fixed. If you do an install
of Avogadro it should automatically have the correct paths for loading
all the plugins:
$CMAKE_INSTALL_PREFIX/lib/avogadro/{tools|extensions|engines}
*** if you are running avogadro from the build directory you should
still setup your environment accordingly. The important env variables
and suggested values (replace $BUILD_DIR with your build directory =) )
AVOGADRO_TOOLS=$BUILD_DIR/libavogadro/src/tools
AVOGADRO_ENGINES=$BUILD_DIR/libavogadro/src/engines
AVOGADRO_EXTENSIONS=$BUILD_DIR/avogadro/src/extensions

: Am I missing anything we’ve discussed in irc and I haven’t posted?

Thanks to everyone who is getting involved. It’s really helping and
everything is going great. Don’t get too worried about breaking stuff
or whatever, i haven’t been putting in much documentation (tsk tsk) but
i’ll get to it eventually. If you see anything undocumented and you
know what is going on, please document it =). Also, if you’re digging
through codo to learn stuff that’s a great time to write a bit of
documentation (help keep it in your mind and probably better as you just
learned it). Hope everyone is feeling good about progress and happy
with their work.

Avogadro? More like Awesomegadro!

Donald

2

On Friday 04 May 2007 06:16:05 Donald Ephraim Curtis wrote:

: Tools now have an added ::paint function that allows them to paint to

the GLWidget on GL updates. This is needed for a few reasons. Try out
ratation with the navigate tool and see what you think. Looks really
cool.

Yay! That’s exactly what I wanted, and yes, the rotation looks great. Now, as
we’ve already discussed on IRC with Marcus, one can go far beyond just
drawing a sphere – a whole new world of eye-candy becomes possible!

One thing by the way: in your code in NavigateTool::paint() :

  foreach(Engine *engine, widget->engines())
  {
    if(engine->isEnabled())
    {
      double engineRadius = engine->radius(_clickedAtom);
      if(engineRadius > renderRadius) {
        renderRadius = engineRadius;
      }
    }
  }

Here’s a good reason why IMHO we could want to introduce a notion of “active
rendering engine”. The idea is that some engines are rendering engines
(spheres, bs, bsdy, sticks) and some aren’t (label, debug). Even though it is
possible and useful to have more than one engine enabled at a given time,
there should always be exactly one /rendering/ engine enabled. That would let
us simplify the above code:

renderRadius = widget->renderingEngine()->radius(_clickedAtom);

Another thing I need to discuss is why in the tools we keep passing widget as
argument instead of storing it in the class. Does that mean you would like
tools to be able to work with more than one glwidget? In that case there is
one thing I need to draw your attention on. In NavigateTool I have introduced
a member pointer _glwidget, to reduce argument-passing. It’s being updated by
mouse events. I think that’s OK even if the tool must be used with more than
one widget, because you can’t click on two different widgets simultaneously.
As soon as you click on another widget, _glwidget becomes updated.

Just wanted to make sure that’s OK.

Cheers,
Benoit