Hi again,
I’d like to bring to libavogadro the navigation system I implemented in
Kalzium. That would be a plugin, side-by-side with selecrotate. But the
problem is, plugins are not currently in libavogadro. Is that meant to
change? How else can we share such plugins between Kalzium and other
Avo-based projects?
Cheers,
Benoit
This is a very good question. First, I will say I am not opposed to
this.
However, in talking with you before we had decided that the plugins
which “manipulated” the GL surface should be left to the application.
In rethinking this, I do not see why we couldn’t include these in the
library too. In this cause the GLWidget would be responsible for
loading the tools which are available to it.
The reason we said we were not going to include this was because not
everyone will want the “draw” tool. However, the other option we have is
that when an application needs a tool which is not included in the base
library they can simply download their own. That is the reason we
made this pluggable in the first place right? I don’t think including
draw as part of the library is going to bulk it up or anything
rediculous. I mean, most tools are going to be very small.
Does this make sense or did I lose you? Let me know B.
Anyone else want to chime in on this. I think it’s probably a good
idea.
-Donald
(Fri, Mar 09, 2007 at 08:51:14AM +0100) Benoît Jacob jacob@math.jussieu.fr:
Hi again,
I’d like to bring to libavogadro the navigation system I implemented in
Kalzium. That would be a plugin, side-by-side with selecrotate. But the
problem is, plugins are not currently in libavogadro. Is that meant to
change? How else can we share such plugins between Kalzium and other
Avo-based projects?Cheers,
Benoit
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
I tnik that plugins should be definetly of main library, lets say libavogadro
which i think sould simply load drawing engines, provide basic rendering
engines and never draw anything outside molcule on the screen,
Howeverk may be avogadro can provide a secondary library, libavogadrotools or
something like that, with more specific options and tools.
This is a very good question. First, I will say I am not opposed to
this.However, in talking with you before we had decided that the plugins
which “manipulated” the GL surface should be left to the application.
In rethinking this, I do not see why we couldn’t include these in the
library too. In this cause the GLWidget would be responsible for
loading the tools which are available to it.The reason we said we were not going to include this was because not
everyone will want the “draw” tool. However, the other option we have is
that when an application needs a tool which is not included in the base
library they can simply download their own. That is the reason we
made this pluggable in the first place right? I don’t think including
draw as part of the library is going to bulk it up or anything
rediculous. I mean, most tools are going to be very small.Does this make sense or did I lose you? Let me know B.
Anyone else want to chime in on this. I think it’s probably a good
idea.-Donald
(Fri, Mar 09, 2007 at 08:51:14AM +0100) Benoît Jacob
jacob@math.jussieu.fr:Hi again,
I’d like to bring to libavogadro the navigation system I implemented in
Kalzium. That would be a plugin, side-by-side with selecrotate. But the
problem is, plugins are not currently in libavogadro. Is that meant to
change? How else can we share such plugins between Kalzium and other
Avo-based projects?Cheers,
Benoit
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
–
Dr. Armando Navarro-Vázquez
RIAIDT. Univdade de Resonancia Magnetica
Universidade de Santiago de Compostela
http://desoft03.usc.es/armando/index.html
On Mar 9, 2007, at 6:39 AM, Armando Navarro Vázquez wrote:
Howeverk may be avogadro can provide a secondary library,
libavogadrotools or
something like that, with more specific options and tools.
I think this is a great approach. My vision has been that Avogadro
(and other programs) need some level of basic rendering and viewing
tools. Then “added functions” are separate loadable plugins for
rendering, tools, etc. These will likely be through different API
classes.
This way, programs (and users) can pick the tools which work for
them. We provide an API for a “mouse tool” and Kalzium can provide a
different navigation tool than Avogadro, if they like.
What’s Linus’ mantra? “Let the Best Code Win.” If we all share a
clean API, it becomes trivial to pick the best tools and rendering
engines from each project and improve them.
Just my $0.02,
-Geoff
Hi Armando,
On Friday 09 March 2007 12:39:58 Armando Navarro Vázquez wrote:
I tnik that plugins should be definetly of main library, lets say
libavogadro which i think sould simply load drawing engines, provide basic
rendering engines and never draw anything outside molcule on the screen,
Howeverk may be avogadro can provide a secondary library, libavogadrotools
or something like that, with more specific options and tools.
Yes, I totally agree with that! Like, GAMESS could be in the secondary library
in order to make the main library smaller.
Benoit
forgot to reply-to-all… sorry Donald, you receive this twice.
On Friday 09 March 2007 12:26:29 you wrote:
This is a very good question. First, I will say I am not opposed to
this.However, in talking with you before we had decided that the plugins
which “manipulated” the GL surface should be left to the application.
Aha, yes, I remember. But at that time I didn’t know much about Avo. Now that
I see how it works, I’m fine with its plugins-based design
The reason we said we were not going to include this was because not
everyone will want the “draw” tool. However, the other option we have is
that when an application needs a tool which is not included in the base
library they can simply download their own. That is the reason we
made this pluggable in the first place right? I don’t think including
draw as part of the library is going to bulk it up or anything
rediculous. I mean, most tools are going to be very small.
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 whole
avogadro project. One could then release into a separate package the larger,
more advanced plugins like libgamess.so.
Anyway this depends on OpenBabel, which takes 8 megabytes here (debug
version). So I think, it’ll be a while before libavogadro size becomes an
issue.
Cheers,
Benoit
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
whole
avogadro project. One could then release into a separate package
the larger,
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.
-Geoff
On Fri, 9 Mar 2007, Geoffrey Hutchison wrote:
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.
I’m not sure I understand: I was not opposing the idea of having
everything in a separate plugin, I was just saying that it would be nice
if some basic plugins were shipped together with the library.
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.)
I have no problem at all with that!
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.).
Yes, I agree with that! My initial idea was to ship these common plugins
with libavogadro itself, but if you don’t like it, I’m fine with
releasing them in a separate avogadro-common-plugins package.
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.
OK, that makes sense. But it doesn’t hurt to provide some common plugins
in a separate package as proposed by Armando.
Again, it’s just my $0.02, but I think it’s better to go for individual
plugins for almost everything.
I don’t think I said the opposite!
This is at most my $0.01 and I didn’t spend much time thinking about these
issues.
Cheers,
Benoit
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:
libavogadro
-engines
–bsengine
-tool
–benoitRotatePanScan
avogadro
-tool
–draw
-extension
–gamess
–ghemical optimization
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 geoff.hutchison@gmail.com:
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
whole
avogadro project. One could then release into a separate package
the larger,
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.
-GeoffTake 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
On Friday 09 March 2007 16:49:11 Donald Ephraim Curtis wrote:
Man, i am the king of long emails onces i get rolling.
Thanks for that, you’re clarifying a lot of things for me.
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.
This is beyond my competence, I’ll let the others decide here 
Cheers,
Benoit
On Mar 9, 2007, at 10:42 AM, Benoit Jacob wrote:
I’m not sure I understand: I was not opposing the idea of having
everything in a separate plugin, I was just saying that it would be
nice if some basic plugins were shipped together with the library.
Aha! Sorry for the miscommunication. I agree with that completely. I
think it’s good to have really basic things like rotate/translate and
measure as plugins along with the “basic package,” along with a
“mouse tool” API. The same goes for rendering engines – basic ones
should be provided.
What I thought you were saying is that they should actually be code
inside the library itself, rather than as a plugin inside one download.
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
library - core code
Brilliant. Yes, this was exactly the problem with language. Packages,
libraries… it does get confusing. I guess that’s why we’ll really
need to update the wiki and try to be as precise as possible.
So i guess in re-reading Geoff’s email my question is if you also want
to put the interface for “extensions” into libavagodro?
No, I think that’s going a bit too far for a first version. We can
obviously move interfaces in the future (v2.0), but I don’t see why
Kalzium suddenly wants to inherit GAMESS. Although I can perhaps see
a need for add/remove hydrogens.
I think I said this before, Avogadro (the main editor) will probably
have a range of different interfaces for different purposes. Some of
these are more “basic” and make sense to share via libavogadro with
other programs. Others make more sense for editing, running QM
programs, etc.
Cheers,
-Geoff
(Fri, Mar 09, 2007 at 04:58:42PM +0100) Benoît Jacob jacob@math.jussieu.fr:
On Friday 09 March 2007 16:49:11 Donald Ephraim Curtis wrote:
Man, i am the king of long emails onces i get rolling.
Thanks for that, you’re clarifying a lot of things for me.
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.This is beyond my competence, I’ll let the others decide here
Well, what i’m saying is, from libavogadro in kalzium do you want to
have the option to perform Add Hydrogens / open the GAMESS Input Deck
Generator / optimize using plugins from libavogadro?
-Donald
Am Freitag, 9. März 2007 17:00 schrieb Geoffrey Hutchison:
So i guess in re-reading Geoff’s email my question is if you also want
to put the interface for “extensions” into libavagodro?No, I think that’s going a bit too far for a first version. We can
obviously move interfaces in the future (v2.0), but I don’t see why
Kalzium suddenly wants to inherit GAMESS. Although I can perhaps see
a need for add/remove hydrogens.
That is exactly what I had in mind: add/remove H is find, GAMESS is totally
out of scope for Kalzium.
Carsten
Am Freitag, 9. März 2007 16:49 schrieb Donald Ephraim Curtis:
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.
The issue here that it is hard to tell what a certain app using libavo wants.
Today, GAMESS is not needed in Kalzium, but then, 3 years ago, I never
imagined a coopereation between me and OpenBabel!
I guess that it is a good idea to implement it like Donald suggested in this
email, port Kalzium and Avogadro to use that strucuture and the rediscuss.
Carsten
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.
Man, this is what hurts the most. Ice Cold!
But seriously, this is a good selling point. And maybe it should be our
slogan. Avogadro: If you don’t like it, do it yourself!
I’m just joking.
-Donald
In recently working with the Undo/Redo system i realize now that every
action requires that you add the command to the Undo/Redo stack. This
introduces a requirement. This requirement is that all tools return a
pointer to a QUndoCommand object. This is not a problem as long as we
agree it’s ok. There should be a way to handle this. The one way i can
think about doing this is that we just have it where if you want to use
your own QUndoStack you can pass it to the glWidget and it automatically
adds to your stack instead of it’s own internal one.
The QT Undo/Redo system works as such: for each action in your app you
create an instance of a QUndoCOmmand class and return that instance.
The instance contains information on how to perform and undo that
action. This means at some point the tool plugins would return a
subclass performing the action rather than performing the action
themselves. This is really cool in my opinion and makes debuggin and
unit testing much much better. But it would mean that if we make tools
part of the GLWidget that these QUndoCOmmands would have to make it back
to the main application (if the application chooses). But my method
above would solve this problem. Meaning if Kalzium doesn’t need that
functionality it doesn’t need to worry about it.
-Donald
(Fri, Mar 09, 2007 at 05:16:22PM +0100) Benoît Jacob jacob@math.jussieu.fr:
On Friday 09 March 2007 17:01:10 you wrote:
Well, what i’m saying is, from libavogadro in kalzium do you want to
have the option to perform Add Hydrogens / open the GAMESS Input Deck
Generator / optimize using plugins fromThat’s a question for Carsten
I don’t really have an opinion here, I’m
restricting myself to the math and opengl part (don’t have time for more, and
lack chemical background).Cheers,
Benoit