Is it also possible to make plugins with submenus? Like:
Ghemical
The choice between steepest descent or conjugate gradients could off course
be offered in a dialog box together with the number of steps, convergence
criteria, …
Attached is a small patch to specify the number of steps for the optimize
geometry action.
Tim
At this point there is no way to make plugins with submenus. We
haven’t yet fleshed out how we want to implement this. We’re open for
suggestions.
A couple options; 1) have the action names say how they should be
organized (ie Ghemical/Energy / Ghemical/Steepest Descent), 2) have the
plugins return menus and actions. 3) have the menu architecuture be
contained in the UserData part of the QAction.
(Actually this can be acomplished easy in QT by having it be a list of
QVariant rather than list of QAction. Then when loading the plugin, we
can detect which it is by a qobject_cast.)
However, the one thing i REALLY want to happen is that eventually i’d
like to allow people to take actions from plugins and place them in
their hotbar. So for instance, it’d be nice to have it so if i want
AddHydrogens on my hotbar i can. And in QT it’s nice cause you can have
one action and it can be placed in more than one thing. Such as
File->New and the New on the toolbar are exactly the same action. This
can probably be acomplished later because we don’t know how this
interface will work and now that i think about it, when we do the
customize toolbar, it will probably traverse all the menus anyways so it
doesnt’ matter if we know about the action right away. This may make no
sense but it’s good for me to think this through now. It makes sense in
my brain somehow.
Although, the yet another option was to just have each plugin be
contained in it’s own menu. The reason i didn’t initially do this was
because I think certain operations should be in the root menu for tools.
For common operations i think they shoudl be as easy as going
Tools->AddHydrogens as opposed to Tools->Hydrogens->AddHydrogens.
I guess the question is how we do this and make it the most dynamic at
the same time.
Also, rambling… gotta get to bed soon, but i think a better thing
would be to have an Action in the plugin that pops up a menu and sets
those values. Right now i have changed it a bit so that it does
ConjugateGradients(10) x 10 so that i can update the graphic while the
optimization is happening. (i.e. so you can see it happening). I
haven’t commited this yet. Ok i take that back, it’s commited now.
Take a look at that i suppose.
Thanks Tim. Keep the emails coming. Keeps me on my toes.
(Sat, Feb 24, 2007 at 02:08:53AM +0100) Tim Vandermeersch tim.vandermeersch@gmail.com:
Is it also possible to make plugins with submenus? Like:
Ghemical
- Energy
- Steepest Descent
- Conjugate Gradients
Hydrogens- Add
- Remove
The choice between steepest descent or conjugate gradients could off course
be offered in a dialog box together with the number of steps, convergence
criteria, …Attached is a small patch to specify the number of steps for the optimize
geometry action.Tim
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
On 2/24/07, Donald Ephraim Curtis d@milkbox.net wrote:
At this point there is no way to make plugins with submenus. We
haven’t yet fleshed out how we want to implement this. We’re open for
suggestions.A couple options; 1) have the action names say how they should be
organized (ie Ghemical/Energy / Ghemical/Steepest Descent), 2) have the
plugins return menus and actions. 3) have the menu architecuture be
contained in the UserData part of the QAction.(Actually this can be acomplished easy in QT by having it be a list of
QVariant rather than list of QAction. Then when loading the plugin, we
can detect which it is by a qobject_cast.)However, the one thing i REALLY want to happen is that eventually i’d
like to allow people to take actions from plugins and place them in
their hotbar. So for instance, it’d be nice to have it so if i want
AddHydrogens on my hotbar i can. And in QT it’s nice cause you can have
one action and it can be placed in more than one thing. Such as
File->New and the New on the toolbar are exactly the same action. This
can probably be acomplished later because we don’t know how this
interface will work and now that i think about it, when we do the
customize toolbar, it will probably traverse all the menus anyways so it
doesnt’ matter if we know about the action right away. This may make no
sense but it’s good for me to think this through now. It makes sense in
my brain somehow.Although, the yet another option was to just have each plugin be
contained in it’s own menu. The reason i didn’t initially do this was
because I think certain operations should be in the root menu for tools.
For common operations i think they shoudl be as easy as going
Tools->AddHydrogens as opposed to Tools->Hydrogens->AddHydrogens.I guess the question is how we do this and make it the most dynamic at
the same time.Also, rambling… gotta get to bed soon, but i think a better thing
would be to have an Action in the plugin that pops up a menu and sets
those values.
Right now i have changed it a bit so that it does
ConjugateGradients(10) x 10 so that i can update the graphic while the
optimization is happening. (i.e. so you can see it happening). I
haven’t commited this yet. Ok i take that back, it’s commited now.
Take a look at that i suppose.
Altough this works it is far from perfect. Would it help if the Conjugate
gradients was changed to:
void ConjugateGradients(int steps, void (*updatefunc)(), int mode);
The updatefunc is a function pointer which is called every step (or 10
steps…).
I tried this, but keep having problems to access the molecule and forcefield
pointer from Avogadro::Ghemical::update(). I can send you a patch for this,
but I think the following way is better.
Another way to do this would be to have:
void ConjugateGradientsInitialize(int steps, int mode);
bool ConjugateGradientsTakeNStep(int n); // return: true when convergence or
number of steps provided by ConjugateGradientsInitialize has been reached
What does “multiple render modes” mean (on the wiki)? Are these
representations such as Lines, CPK, VDW, … If yes, how do you select them?
Thanks in advance,
Tim
Right now i have changed it a bit so that it does
ConjugateGradients(10) x 10 so that i can update the graphic while the
optimization is happening. (i.e. so you can see it happening). I
haven’t commited this yet. Ok i take that back, it’s commited now.
Take a look at that i suppose.Altough this works it is far from perfect. Would it help if the Conjugate
gradients was changed to:void ConjugateGradients(int steps, void (*updatefunc)(), int mode);
The updatefunc is a function pointer which is called every step (or 10
steps…).I tried this, but keep having problems to access the molecule and forcefield
pointer from Avogadro::Ghemical::update(). I can send you a patch for this,
but I think the following way is better.Another way to do this would be to have:
void ConjugateGradientsInitialize(int steps, int mode);
bool ConjugateGradientsTakeNStep(int n); // return: true when convergence or
number of steps provided by ConjugateGradientsInitialize has been reached
Yes, this is exaclty what i would like to see. It should be up to the
app calling the optimization to handle the number of times it needs to
be called.
What does “multiple render modes” mean (on the wiki)? Are these
representations such as Lines, CPK, VDW, … If yes, how do you select them?
That is indeed what they mean, but for the time being the only rendering
engine we have built “correctly” is ball and stick. We have built a
pluggable interface for rendering. There is VDW and Lines in the
libavogadro/src/engines directory but they are not yet being compiled.
The main reason is we changed the way that engines get called from the
main interface and I never got around to updating the old ones. (also,
we may do more rewritting of the interface at some point so who knows).
Avogadro is still pretty alpha, doing design stuff still.
Thanks in advance,
Tim
On 2/24/07, Donald Ephraim Curtis d@milkbox.net wrote:
Right now i have changed it a bit so that it does
ConjugateGradients(10) x 10 so that i can update the graphic while the
optimization is happening. (i.e. so you can see it happening). I
haven’t commited this yet. Ok i take that back, it’s commited now.
Take a look at that i suppose.Altough this works it is far from perfect. Would it help if the
Conjugate
gradients was changed to:void ConjugateGradients(int steps, void (*updatefunc)(), int mode);
The updatefunc is a function pointer which is called every step (or 10
steps…).I tried this, but keep having problems to access the molecule and
forcefield
pointer from Avogadro::Ghemical::update(). I can send you a patch for
this,
but I think the following way is better.Another way to do this would be to have:
void ConjugateGradientsInitialize(int steps, int mode);
bool ConjugateGradientsTakeNStep(int n); // return: true when
convergence or
number of steps provided by ConjugateGradientsInitialize has been
reachedYes, this is exaclty what i would like to see. It should be up to the
app calling the optimization to handle the number of times it needs to
be called.What does “multiple render modes” mean (on the wiki)? Are these
representations such as Lines, CPK, VDW, … If yes, how do you select
them?That is indeed what they mean, but for the time being the only rendering
engine we have built “correctly” is ball and stick. We have built a
pluggable interface for rendering. There is VDW and Lines in the
libavogadro/src/engines directory but they are not yet being compiled.
The main reason is we changed the way that engines get called from the
main interface and I never got around to updating the old ones. (also,
we may do more rewritting of the interface at some point so who knows).
Avogadro is still pretty alpha, doing design stuff still.
In the first patch I send to you, a dialog box was used to get the number of
steps. Was there something wrong about doing it this way? because I don’t
really understand what you mean by:
but i think a better thing would be to have an Action in the plugin that
pops up a menu and sets those values
Should the plugin contain two actions? one for setting up, and one for
actually performing the action?
The reason I’m asking this is because I would like to make (or see 
) a
tool to search for SMARTS in molecules. This would make debugging the MMFF94
atom typing much easier. Is such a tool possible at the moment? I was
thinking on using the Atom::SetSelected(true) for all the matched SMARTS,
but have no Idea to implement multiple matches… An option would be to make
a popup window were you can select the different matches.
Thanks in advance,
Tim
On Feb 24, 2007, at 1:18 PM, Tim Vandermeersch wrote:
Should the plugin contain two actions? one for setting up, and one
for actually performing the action?
I think we will have a range of plugin types. Some (e.g., geometry
optimizations) would probably need to have two actions. One for
setup, and other for performing the optimization. This means that the
setup could choose the force field, number of steps, etc. (through a
dialog).
The reason I’m asking this is because I would like to make (or
see
debugging the MMFF94 atom typing much easier. Is such a tool
possible at the moment? I was thinking on using the
Atom::SetSelected(true) for all the matched SMARTS, but have no
Idea to implement multiple matches… An option would be to make a
popup window were you can select the different matches.
So I’ve been really interested in “selection plugins” that could take
user input (from mouse clicks or text) and select different parts of
the molecule. SMARTS is high on my list, but I can imagine others
might like to select all ARG (or other) residues. Or all carbon
atoms… Or take a user click and select a residue or a full molecule
rather than a set of atoms.
Next week I’ll try to flesh out what sorts of functions I imagine in
different types of plugins. I think each interface type yields a
different main menu – and then each plugin could potentially add 1
or more menu items, or even a submenu.
I think bouncing ideas like this is really helpful!
Thanks,
-Geoff
Right now it’s already possible for a plugin to have multiple actions.
See hydrogens.cpp/h as it creates multiple actions and based on the
QAction that is passed to it in the procesAction function it acts
accordingly. I do not see why you couldn’t have an Action to create a
popup menu (for setup) and then have another action to run it. See if
that works for ya. Should be easy to do what you’re saying already.
I’m working on a few widgets to kinda help with our interface. (debug
messages and such). I’ll let you know how it goes. Should be commiting
my tonite.
-Donald
(Sat, Feb 24, 2007 at 03:35:55PM -0500) Geoffrey Hutchison geoff.hutchison@gmail.com:
On Feb 24, 2007, at 1:18 PM, Tim Vandermeersch wrote:
Should the plugin contain two actions? one for setting up, and one
for actually performing the action?I think we will have a range of plugin types. Some (e.g., geometry
optimizations) would probably need to have two actions. One for
setup, and other for performing the optimization. This means that the
setup could choose the force field, number of steps, etc. (through a
dialog).The reason I’m asking this is because I would like to make (or
see
debugging the MMFF94 atom typing much easier. Is such a tool
possible at the moment? I was thinking on using the
Atom::SetSelected(true) for all the matched SMARTS, but have no
Idea to implement multiple matches… An option would be to make a
popup window were you can select the different matches.So I’ve been really interested in “selection plugins” that could take
user input (from mouse clicks or text) and select different parts of
the molecule. SMARTS is high on my list, but I can imagine others
might like to select all ARG (or other) residues. Or all carbon
atoms… Or take a user click and select a residue or a full molecule
rather than a set of atoms.Next week I’ll try to flesh out what sorts of functions I imagine in
different types of plugins. I think each interface type yields a
different main menu – and then each plugin could potentially add 1
or more menu items, or even a submenu.I think bouncing ideas like this is really helpful!
Thanks,
-Geoff