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