Avogadro2 Edit/View Molecule - Code and Interface

Development
1

Hi Marcus,

I wanted to follow-up about an off-list discussion with Avogadro v2. Between v0.7, and the current git master (0.8?) there’s now a clear UI division between “edit” and “view” molecules.

Can you outline some of the real reasons for this behind the scenes, particularly on the UI side? I think this is currently a usability nightmare and I’d like to make sure we can work past this or write up conversion code that allows tools, extensions, etc. to convert back and forth.

My big use-case concern is the Auto Optimize tool, which I’m trying to design for Avogadro v2’s very different architecture. For example, let’s say a user wants to set a measurement between two atoms (view). Then they switch to the Auto Optimize tool (edit) and start pushing atoms around.

In Avogadro v1, this wasn’t a problem. The measurements would update while the optimization occurred in a different thread.

How can this work in Avogadro v2?

Thanks,
-Geoff

2

Hi Geoff,

Sorry, crazy travel schedule, so didn’t get this finished as soon as I
had hoped. I am working on some changes to make the conversion much
simpler, and to alleviate the UI issue. As I said at the time -
totally agree, and not pushing to keep the current UI. I think it was
a necessary step as I fleshed it out, but hope to make this much
smoother.

I think any of the edit functionality can convert to an editable
molecule, they use implicitly shared arrays and so the copy cost is
minimal with only the coordinates triggering a real copy when the
forcefield kicks in. I would love to see what you are thinking for the
auto-optimize, I just spent a few days at Daresbury Lab last week
talking about some of these features (along with QMMM, how we might
define regions, residues, etc).

Let me see what I can get done on the weekend to make it clearer, and
sketch out what I thought would work. Happy to iterate on this, and
yes it is better to put more of these discussions on the mailing list.
Measurement is a tool that I think we make work with edit and view
molecules to be honest - so no need to switch at all.

Marcus

On Wed, Sep 3, 2014 at 10:44 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

Hi Marcus,

I wanted to follow-up about an off-list discussion with Avogadro v2. Between v0.7, and the current git master (0.8?) there’s now a clear UI division between “edit” and “view” molecules.

Can you outline some of the real reasons for this behind the scenes, particularly on the UI side? I think this is currently a usability nightmare and I’d like to make sure we can work past this or write up conversion code that allows tools, extensions, etc. to convert back and forth.

My big use-case concern is the Auto Optimize tool, which I’m trying to design for Avogadro v2’s very different architecture. For example, let’s say a user wants to set a measurement between two atoms (view). Then they switch to the Auto Optimize tool (edit) and start pushing atoms around.

In Avogadro v1, this wasn’t a problem. The measurements would update while the optimization occurred in a different thread.

How can this work in Avogadro v2?

Thanks,
-Geoff

3

So the weekend resulted in no code being written, mostly ended up
having to fix some stuff in the house I was behind on due to all the
travel :-/ I did manage to get Windows reinstalled on the machine I
was using to create binaries (it suffered a hard drive failure a month
or two back - new, bigger hard drive too). I will have some time to
actually work on this in the coming days though, apologies on the
delay - I hadn’t factored in spending so much time on real life
stuff…

Marcus

On Thu, Sep 4, 2014 at 9:31 PM, Marcus D. Hanwell
mhanwell@gmail.com wrote:

Hi Geoff,

Sorry, crazy travel schedule, so didn’t get this finished as soon as I
had hoped. I am working on some changes to make the conversion much
simpler, and to alleviate the UI issue. As I said at the time -
totally agree, and not pushing to keep the current UI. I think it was
a necessary step as I fleshed it out, but hope to make this much
smoother.

I think any of the edit functionality can convert to an editable
molecule, they use implicitly shared arrays and so the copy cost is
minimal with only the coordinates triggering a real copy when the
forcefield kicks in. I would love to see what you are thinking for the
auto-optimize, I just spent a few days at Daresbury Lab last week
talking about some of these features (along with QMMM, how we might
define regions, residues, etc).

Let me see what I can get done on the weekend to make it clearer, and
sketch out what I thought would work. Happy to iterate on this, and
yes it is better to put more of these discussions on the mailing list.
Measurement is a tool that I think we make work with edit and view
molecules to be honest - so no need to switch at all.

Marcus

On Wed, Sep 3, 2014 at 10:44 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

Hi Marcus,

I wanted to follow-up about an off-list discussion with Avogadro v2. Between v0.7, and the current git master (0.8?) there’s now a clear UI division between “edit” and “view” molecules.

Can you outline some of the real reasons for this behind the scenes, particularly on the UI side? I think this is currently a usability nightmare and I’d like to make sure we can work past this or write up conversion code that allows tools, extensions, etc. to convert back and forth.

My big use-case concern is the Auto Optimize tool, which I’m trying to design for Avogadro v2’s very different architecture. For example, let’s say a user wants to set a measurement between two atoms (view). Then they switch to the Auto Optimize tool (edit) and start pushing atoms around.

In Avogadro v1, this wasn’t a problem. The measurements would update while the optimization occurred in a different thread.

How can this work in Avogadro v2?

Thanks,
-Geoff

4

Good morning,

Let me add a bit to this discussion as well. I’ve been working on the crystallography extension in Avogadro2 and I find it exceeding difficult to use the CrystalTools while editing or creating molecules.

  1. It takes several clicks in and out of view mode along with renaming the “molecule” before the Crystal QT plugin recognizes that there is even a molecule present. From what I can tell in edit mode the following check returns false for a new molecule.

crystal.cpp:
if (m_molecule)

  1. Once a unit cell has been added it is not visible in edit mode. The following appears to return false.

  2. Crystal operations, like filling a unit cell, show nothing in edit mode. They appear to work and the output is present once the user changes to view mode.

All of these operations just worked in the 0.7 release and it didn’t care if the user had selected an edit tool or a view tool. One of the great features of Avogadro is that the molecule was always editable and the programmer didn’t have to make many, or even any, special considerations when writing tools.

Albert

5

On Mon, Sep 8, 2014 at 10:14 AM, Defusco III, Albert A defusco@pitt.edu wrote:

Good morning,

Let me add a bit to this discussion as well. I’ve been working on the crystallography extension in Avogadro2 and I find it exceeding difficult to use the CrystalTools while editing or creating molecules.

  1. It takes several clicks in and out of view mode along with renaming the “molecule” before the Crystal QT plugin recognizes that there is even a molecule present. From what I can tell in edit mode the following check returns false for a new molecule.

crystal.cpp:
if (m_molecule)

  1. Once a unit cell has been added it is not visible in edit mode. The following appears to return false.

  2. Crystal operations, like filling a unit cell, show nothing in edit mode. They appear to work and the output is present once the user changes to view mode.

All of these operations just worked in the 0.7 release and it didn’t care if the user had selected an edit tool or a view tool. One of the great features of Avogadro is that the molecule was always editable and the programmer didn’t have to make many, or even any, special considerations when writing tools.

Like I said, please give me a little time to finish it up, perhaps I
committed the feature too soon. Many of these issues are rendering
artifacts, along with some issues around certain editing features not
being ported to use the right structure. I am not pushing to keep it
this way, but like I said when I was over in Pittsburgh this can be
made intuitive with a little more work - I will see if I can get that
finished up soon so that things are easier, and we can make a release.

Thanks for your patience, I am thankfully done with travel for a
while, and should be able to focus on finishing this up. Major
advantages are a scalable undo/redo (with some rough edges
admittedly), and I honestly think it will be worth it to reduce
confusion about properties that are simply no longer valid after
editing. In the UI the difference between editing and viewing should
be fluid, but I hope to create a much clearer model in the API so that
we focus on doing one or the other well in most cases.

If by some chance it doesn’t work out I can back out some of the changes.

Marcus