> 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 ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/avogadro-devel
