Libavogadro design

So i’ve just been toying with implementing libavogadro which basically
contains everything that the plugins would use. The problem appears to
be that for a plugin to use any sort of class that we design it either
must compile the program binary using -rdynamic or design an external
library it can link to. Now the first way is frowned apon and doesn’t
fix the problem in Windows.

The problem is that the tools we implement will want to have access to
the GLWidget and some helper functions for gathering hits and rotating
etc. But the problem that i’m having and would like some input to is
where we draw the line.

Engines should definatly be part of the library installation. It is
then the idea that any application Kalzium / Avogadro can use
libavogadro to get a GLWidget and that GLWidget will automatically load
the plugins it uses (in much the same way that openbabel does).
However, I personally feel that any Tool plugins (drawing / rotating /
etc) should be the responsibility of the application to implement. Thus
if Kalzium wants to manipulate the GL widget it can do so by either
subclassing Avogadro::GLWidget or by attaching to the Signals (i believe
subclassing would have better performance?).

Any input is greatly suggested. Just getting the feel for this. Pretty
simple but a few problems with the Plugin system aparently.

On Jan 2, 2007, at 9:07 PM, Donald Ephraim Curtis wrote:

if Kalzium wants to manipulate the GL widget it can do so by either
subclassing Avogadro::GLWidget or by attaching to the Signals (i
believe
subclassing would have better performance?).

From what I’ve seen on the Qt website and other places, Signals is
actually quite fast and would probably be the “Qt clean” way to go.
For one, if other projects subclass the GL widget, wouldn’t they also
need to make that a separate library too?

Thanks for your work on this – I think having a library with shared
code will definitely help the code organization in general.

Cheers,
-Geoff

(Wed, Jan 03, 2007 at 10:02:19AM -0500) Geoffrey Hutchison geoff.hutchison@gmail.com:

On Jan 2, 2007, at 9:07 PM, Donald Ephraim Curtis wrote:

if Kalzium wants to manipulate the GL widget it can do so by either
subclassing Avogadro::GLWidget or by attaching to the Signals (i
believe
subclassing would have better performance?).

From what I’ve seen on the Qt website and other places, Signals is
actually quite fast and would probably be the “Qt clean” way to go.
For one, if other projects subclass the GL widget, wouldn’t they also
need to make that a separate library too?

Only if the functions they include in their subclass need to be called by
the tools. This is the case in any situation. In our case our tools
are currently getting passed two parameters (GLWidget, QEvent). Of
course this may not always be what we’re looking for but to get any of
the function from the parameters the classes must be defined external or
be exposed by the main program (g++ -rdynamic).

The idea would be that hopefully our GLWidget would give any app
(Kalzium) enough functionality. I need to get with Benoit and get
avogadro-lib using that math lib of his instead of our built-in vector
classes.

Actually we probably need to go with signals/slots because if we go with
subclassing then it’s possible our init() functions won’t get called.

Thanks for your work on this – I think having a library with shared
code will definitely help the code organization in general.

The only thing that bothers me is that i think our library and our app
should live in separate namespaces. And also i think I’m going to
rename from libavogadro to avogadro-lib. It may also be useful to just
have trunk be organized as follows;

trunk
-lib
–engines
-src
–tools

Although i’m currently running into the same problem that OB was facing.
#include “…/engine.h” rather than the proper #include
<avogadro/engine.h>

I also am switching to cmake. Qmake was just getting to be too much of
a headache. Not that cmake isn’t but it’s kde-appeased.

Thanks for your work on this – I think having a library with shared
code will definitely help the code organization in general.

Cheers,
-Geoff


Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options