Man, i am the king of long emails onces i get rolling.
Well, I think what benoit is saying is that libavogadro should contain
the plugin “interface” and maybe some default functionality. So
imagine this scenario:
While Eclipse is a very good ideal, i think that the kde-kioslaves are a
better example for the situation we have here, but i am by no means a
kioslave expert. In this case there is a library which konqueror shares
and there could feasibly be other programs which support the library.
Something like amarok would need specifically the plugin to read ipods
and thus would also depend on the required plugin.
But I think we are getting off track. The main question is whether we
make the tools inteface for the GLWidget part of the libavogadro
(libavogadro manages the tools and loads them) or leave it as it is now
where applications must provide the interface for the tools and it seems
like the general concensus is that plugins which modify the glwidget
(tools) should be handled by the library and not the application using
the library. How we actually package these tools or release them later
is irrelevant to me. The fact is that someone may feasibly want a
plugin that comes with neither avogadro nor kalzium and can add that to
both applications in one install.
I also think we should get used to using terms which express their use;
engines - things that render parts of our glwidget
tools - things which turn the mouse (and maybe keyboard) into a tool for
modifying part of the glwidget.
extensions - things which “extend” the functionality of avogadro.
plugin - any /all of; engine, tool, extension
In general using the term “plugin” is so general it could mean one thing
to one person and one thing to another.
So i guess in re-reading Geoff’s email my question is if you also want
to put the interface for “extensions” into libavagodro? Meaning that
Kalzium could take advantage of the Ghemical plugin or the GAMESS plugin
for generating input decks. I don’t think this is a bad idea either.
At some point though we have to draw the line and say this is something
specific for Avogadro and not the library.
(Fri, Mar 09, 2007 at 09:44:29AM -0500) Geoffrey Hutchison firstname.lastname@example.org:
On Mar 9, 2007, at 9:22 AM, Benoît Jacob wrote:
I see how it works, I’m fine with its plugins-based design
I think the plugins would be a very valuable part of libavogadro,
so I’d put
them in libavogadro. This way, more apps would be interested in the
avogadro project. One could then release into a separate package
more advanced plugins like libgamess.so.
I’m sorry, but I that doesn’t sound logical to me.
Take a look at Eclipse, which was a large part of my inspiration.
Essentially everything is a separate loadable plugin. Small features,
big advanced features, everything in between. Same for image-editing
programs like GIMP, Photoshop, etc. Perl and Python don’t include
their entire libraries – you can download and install new modules.
Do you have a problem that Open Babel includes all its formats as
separate plugin modules? Does that make it less interesting or
valuable? (No, in principal, it makes it better since you only need
to load the functions you use = less memory.)
If Avogadro is defining the API for plugins, then those modules are
just as valuable to be downloaded or installed separately, IMHO. As
Armando said, perhaps it’s better to split out some common plugins
(e.g., navigation, measurements, labels, etc.). I think people are
going to be interested in the whole project because it’s designed
well and makes it really easy to add new plugins.
Again, it’s just my $0.02, but I think it’s better to go for
individual plugins for almost everything. I know I don’t like
Donald’s selectrotate, but that’s OK because I can go write my own.
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
Avogadro-devel mailing list