On May 11, 2007, at 2:17 PM, Marcus D. Hanwell wrote:
We should decide on one or the other (doesn’t matter to me, just
want us to decide) and then
design the code around that.
As we discussed earlier on IRC I favour having the view maintain a
list of
selected elements. I think that this is the most intuitive approach
- each
view has its own perspective, list of selected atoms, rendering
engine etc.
Here’s the big catch. Right now, we mainly deal with selecting atoms.
Now let’s think about our design in the future. We’ll have surfaces
and planes and rendered residues…
Imagine I have this nice protein with a ribbon representing the
residue alpha helix. And I have some atoms representing the H2O
solvent molecules. And maybe there’s some sort of surface. Worse,
let’s imagine the user had selected a few atoms in one residue
individually. Now imagine they switch to select a few residues. How
should this work?
Right now, the code keeps a list of selected atoms in the widget. I
tend to agree with Marcus that the selection should be a function of
the widget (view). There’s also likely to be a small number of
selected atoms, so it’s faster to deal with that short list.
When I deal with residues, right now I check the Residue::isSelected
() method, and go through all the member atoms and select them. This
keeps life consistent if the user picks a few atoms, then decides to
select or unselect a residue (or molecule).
So the code works, but it’s clunky. It uses both model and view to
track selection (e.g., view for atoms, model for larger groups of
atoms). I think the best solution for the future will be to keep
everything in the view, but keep separate lists for each primitive
type. For example, having separate lists for atoms, residues, bonds,
and surfaces.
Thoughts? Complaints? Suggestions?
-Geoff
P.S. And to throw another wrinkle – we need to copy sets of selected
atoms/residues/whatever. So we need some method which creates a new
molecule from a list of atoms, but keeps atom and bond information!
