On 2/24/07, Donald Ephraim Curtis <donald-curtis@...> 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
> 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
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,