Editing, viewing, and making things more fluid again

Hi,

So I slacked off a lot over the Christmas break, but have been working
on a few patches and thinking about the overall data architecture in
the Avogadro 2 application. We spent quite a while thinking about the
design, and I looked at a lot of what went well and not so well in
Avogadro 1. I thought now might be a good time to explain some of
those decisions (after a little prompting from Geoff), and
improvements I am working on to improve the (unfortunately)
non-intuitive interaction in the current application.

Overly general mega-classes were a source of many
bugs/crashes/inefficiencies in Avogadro. Several design decisions work
to improve that situation in Avogadro 2, including the use of
copy-on-write arrays, storing most molecular data in these arrays, use
of proxy classes for atom/bond/other lightweight objects, and
specializing an editable molecule with scalable undo/redo support,
signals, slots, etc.

If we have a specialized editable molecule we can focus on only the
things that can/should be editable. We can add the necessary
infrastructure to support scalable undo/redo - i.e. record
addition/removal of an atom rather than make many copies of the entire
molecule before and after an edit. The signals fired for each change,
along with the undo/redo objects created, do not scale when adding
millions of atoms though, and so having a view-focused molecule offers
a more scalable option for I/O.

Using copy-on-write arrays also offers very efficient copying from
each molecule type - these arrays do not copy any underlying data
unless a non-const method is called. So reading into a view molecule,
copying to an editable molecule, deleting the view molecule, and
editing the editable actually only ever creates one copy of the bulk
of the data - the array will only be duplicated if a non-const method
is called and its internal reference count is greater than 1.

What doesn’t work at all well is the edit/view GL widget, and the
tough/hard line between editing a molecule/viewing it. I am working on
merging the two widgets together, and reflecting the fluidity of
moving between the two types in the interface so that it will be far
less/barely noticeable that you went from viewing to editing a
structure. I had hoped to get this merged sooner, I think I am pretty
close to having it resolved now.

I have also been experimenting with templating more of the algorithms,
like hydrogen addition/removal, bond perception, etc. This would make
it easy to use a command-line version with no undo/redo support (or Qt
dependency), and build the same algorithm using the editable molecule.
An added benefit would be the potential reuse by any other
library/application using its own molecule class if they implement an
adaptor that offers the expected API. I would love to avoid forcing
everyone into virtuals and using the same base class/API.

For the render widgets I was also hoping to move to the new OpenGL
classes added in Qt 5.4 soon. This email got very long, and I haven’t
necessarily covered everything but would be happy to talk more on
IRC/Skype/Hangouts/on this thread. If this generates a lot of
additional work we should talk, and one thing I was never all that
sold on was not having a common base class for the view/edit molecule

  • I have been weighing up if that would make things simpler/easier.

I was hoping to start posting more details/discussions as things have
become very quiet. I really want to get a new release out, but have
been delaying until the edit/view problems are resolved, and apologize
for the delays in getting this sorted - last year was pretty tough and
featured very little spare time. This year is looking much better, and
I really want to get this right while maintaining the speed and
efficiency improvements made.

Sincerely,

Marcus

On Tue, Jan 06, 2015 at 11:05:15AM -0500, Marcus D. Hanwell wrote:

What doesn’t work at all well is the edit/view GL widget, and the
tough/hard line between editing a molecule/viewing it. I am working on
merging the two widgets together, and reflecting the fluidity of
moving between the two types in the interface so that it will be far
less/barely noticeable that you went from viewing to editing a
structure. I had hoped to get this merged sooner, I think I am pretty
close to having it resolved now.

Are you talking about how the user should do this with respect to mouse
button-drag and modifier keys? If so, it would be interesting to this
disucss this, but I have no idea how it does (not) work currently, how
it was supposed to work, and how you plan to fix it, based on your
information above.

For the render widgets I was also hoping to move to the new OpenGL
classes added in Qt 5.4 soon.

Any good reason for doing this? Is any major distribution shipping Qt
5.4 already?

Michael

On Tue, Jan 6, 2015 at 12:03 PM, Michael Banck mbanck@gmx.net wrote:

On Tue, Jan 06, 2015 at 11:05:15AM -0500, Marcus D. Hanwell wrote:

What doesn’t work at all well is the edit/view GL widget, and the
tough/hard line between editing a molecule/viewing it. I am working on
merging the two widgets together, and reflecting the fluidity of
moving between the two types in the interface so that it will be far
less/barely noticeable that you went from viewing to editing a
structure. I had hoped to get this merged sooner, I think I am pretty
close to having it resolved now.

Are you talking about how the user should do this with respect to mouse
button-drag and modifier keys? If so, it would be interesting to this
disucss this, but I have no idea how it does (not) work currently, how
it was supposed to work, and how you plan to fix it, based on your
information above.

Referring to the need to close the edit widget, open the view widget,
or vice-versa. That will go away, and the switch between the two modes
will be pretty seamless. It is currently quite painful, but should be
fixed up soon.

For the render widgets I was also hoping to move to the new OpenGL
classes added in Qt 5.4 soon.

Any good reason for doing this? Is any major distribution shipping Qt
5.4 already?

Yes, that is where I was hesitating… I may see if the API is close
enough that we can detect the version and use the latest when
available. I know how irritating it can be to require the latest
release of a major library. QGLWidget is deprecated, the OpenGL
variants already have more features and will be supported going
forward.

Marcus

Are you talking about how the user should do this with respect to mouse
button-drag and modifier keys? If so, it would be interesting to this

information above.

Right now in Avogadro v2 (git master) you have to pick an edit or view widget with a button, then open the file, etc. Compared to Avogadro v1, this is a big hiccup for the user.

For the render widgets I was also hoping to move to the new OpenGL
classes added in Qt 5.4 soon.
Any good reason for doing this?

For one, we can request OpenGL features (e.g., anti-aliasing, shaders, etc.) in the widget rather than in main.cpp. It also ensures there’s always a frame buffer (e.g., for saving bitmap graphics) and that multiple views of the same molecule can share OpenGL contexts.

http://blog.qt.digia.com/blog/2014/09/10/qt-weekly-19-qopenglwidget/

No, I don’t think the transition is critical, but I also don’t imagine Avogadro 2.0.0 will be released until late summer or early fall, so the timing should still work with distributions, right?

Thanks,
-Geoff

On Tue, Jan 06, 2015 at 01:06:15PM -0500, Geoffrey Hutchison wrote:

Are you talking about how the user should do this with respect to mouse
button-drag and modifier keys? If so, it would be interesting to this

information above.

Right now in Avogadro v2 (git master) you have to pick an edit or view
widget with a button, then open the file, etc. Compared to Avogadro
v1, this is a big hiccup for the user.

Oh I see.

For the render widgets I was also hoping to move to the new OpenGL
classes added in Qt 5.4 soon.
Any good reason for doing this?

For one, we can request OpenGL features (e.g., anti-aliasing, shaders,
etc.) in the widget rather than in main.cpp. It also ensures there’s
always a frame buffer (e.g., for saving bitmap graphics) and that
multiple views of the same molecule can share OpenGL contexts.

http://blog.qt.digia.com/blog/2014/09/10/qt-weekly-19-qopenglwidget/

Hrm, ok.

No, I don’t think the transition is critical, but I also don’t imagine
Avogadro 2.0.0 will be released until late summer or early fall, so
the timing should still work with distributions, right?

Well, Debian 8 will ship sometime early next year with 5.3, and there
won’t be an Ubuntu LTS until 2016 (which will ship 5.4 I guess). I
tried to see whether RHEL7/Scientific Linux 7 ship Qt5 at all and if so
which version, but couldn’t find anything off-hand.

So the development versions of Debian/Ubuntu will include it by the time
2.0 ships I guess, but if you look for people to run it on a stable
distro once it’s out (either self-compiled or via 3rd-party packages or
backports), that might be more difficult.

Michael

Arch Linux ships at 5.4.

Regards,
Mark

-----Original Message-----
From: “Michael Banck” mbanck@gmx.net
Sent: ‎1/‎6/‎2015 1:48 PM
To: "avogadro-devel@lists.sourceforge.net" avogadro-devel@lists.sourceforge.net
Subject: Re: [Avogadro-devel] Editing, viewing, and making things more fluidagain

On Tue, Jan 06, 2015 at 01:06:15PM -0500, Geoffrey Hutchison wrote:

Are you talking about how the user should do this with respect to mouse
button-drag and modifier keys? If so, it would be interesting to this

information above.

Right now in Avogadro v2 (git master) you have to pick an edit or view
widget with a button, then open the file, etc. Compared to Avogadro
v1, this is a big hiccup for the user.

Oh I see.

For the render widgets I was also hoping to move to the new OpenGL
classes added in Qt 5.4 soon.
Any good reason for doing this?

For one, we can request OpenGL features (e.g., anti-aliasing, shaders,
etc.) in the widget rather than in main.cpp. It also ensures there’s
always a frame buffer (e.g., for saving bitmap graphics) and that
multiple views of the same molecule can share OpenGL contexts.

http://blog.qt.digia.com/blog/2014/09/10/qt-weekly-19-qopenglwidget/

Hrm, ok.

No, I don’t think the transition is critical, but I also don’t imagine
Avogadro 2.0.0 will be released until late summer or early fall, so
the timing should still work with distributions, right?

Well, Debian 8 will ship sometime early next year with 5.3, and there
won’t be an Ubuntu LTS until 2016 (which will ship 5.4 I guess). I
tried to see whether RHEL7/Scientific Linux 7 ship Qt5 at all and if so
which version, but couldn’t find anything off-hand.

So the development versions of Debian/Ubuntu will include it by the time
2.0 ships I guess, but if you look for people to run it on a stable
distro once it’s out (either self-compiled or via 3rd-party packages or
backports), that might be more difficult.

Michael


Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

If we have a specialized editable molecule we can focus on only the
things that can/should be editable. We can add the necessary
infrastructure to support scalable undo/redo …

I think this is a great improvement, since it also means there’s less work on the side of tools and extensions to support undo/redo. (I have a side question as to why undo/redo aren’t connected to menu items in the current interface.)

My question is more on the side of the separate Molecule vs. RWMolecule classes and I think several of us are running into confusion here.

unless a non-const method is called. So reading into a view molecule,
copying to an editable molecule, deleting the view molecule, and
editing the editable actually only ever creates one copy of the bulk

OK, but what’s not clear is how to accomplish this in the current codebase. There don’t seem to be conversion methods that actually work.

Regardless, I wonder about the conceptual side - if you do this (make a copy into a read-only molecule, then come back) are you supposed to retain the undo history?

I have also been experimenting with templating more of the algorithms,

everyone into virtuals and using the same base class/API.

But the problem right now is that it’s utterly confusing. The “view-only” molecule class allows modifications. Anyone porting code from Avogadro v1 will find the Molecule class in core/ and use it. I say this because I did the same (unaware of RWMolecule) for the hydrogen addition and other bits. Albert did the same when porting the Crystallography code.

If RWMolecule was a subclass of Molecule, life would probably be OK - developers can be told “use Molecule if you’re just doing read-only access” (e.g., for an interface to an external program) or “RWMolecule if you want to modify things.”

Templating could work, but it seems like overkill. I don’t think we should always try to solve every problem. Instead, consider the key tasks for the program - interactive editing of molecules.

The copy-on-write and improvements to RWMolecule are great in that context. What I’d like to see is a way forward to simplify updating code from Avogadro v1 and to make it very easy for other developers to modify Avogadro v2. I think we did well with that on Avogadro v1 and if anything, I’d like Avogadro v2 to be even better.

So Marcus, if you’re sold that template code will make this much better, great. Personally, I’d rather go with making RWMolecule a subclass of Molecule, which seems like an easier way to go.

-Geoff

RHEL 7 ships with Qt 4.8.5-8, but EPEL7 (Extra Packages for Enterprise
Linux) and Fedora 20 and 21 have Qt 5.4 versions.

-Ian

On 6 January 2015 at 18:47, Michael Banck mbanck@gmx.net wrote:

On Tue, Jan 06, 2015 at 01:06:15PM -0500, Geoffrey Hutchison wrote:

Are you talking about how the user should do this with respect to mouse
button-drag and modifier keys? If so, it would be interesting to this

information above.

Right now in Avogadro v2 (git master) you have to pick an edit or view
widget with a button, then open the file, etc. Compared to Avogadro
v1, this is a big hiccup for the user.

Oh I see.

For the render widgets I was also hoping to move to the new OpenGL
classes added in Qt 5.4 soon.
Any good reason for doing this?

For one, we can request OpenGL features (e.g., anti-aliasing, shaders,
etc.) in the widget rather than in main.cpp. It also ensures there’s
always a frame buffer (e.g., for saving bitmap graphics) and that
multiple views of the same molecule can share OpenGL contexts.

http://blog.qt.digia.com/blog/2014/09/10/qt-weekly-19-qopenglwidget/

Hrm, ok.

No, I don’t think the transition is critical, but I also don’t imagine
Avogadro 2.0.0 will be released until late summer or early fall, so
the timing should still work with distributions, right?

Well, Debian 8 will ship sometime early next year with 5.3, and there
won’t be an Ubuntu LTS until 2016 (which will ship 5.4 I guess). I
tried to see whether RHEL7/Scientific Linux 7 ship Qt5 at all and if so
which version, but couldn’t find anything off-hand.

So the development versions of Debian/Ubuntu will include it by the time
2.0 ships I guess, but if you look for people to run it on a stable
distro once it’s out (either self-compiled or via 3rd-party packages or
backports), that might be more difficult.

Michael


Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel