Selection, Modes, and GLWidget

OK, I’ve added support for “selection modes” – you can now load a
PDB file, and select a residue at a time, an atom, or a molecule.
There are some performance problems, but I hope to solve those after
the beta.

The scheme I’ve used currently stores a selection list in the
GLWidget. If you want to select or deselect an atom, you should go
through these methods. I check whether a residue should be selected
by the Residue::isSelected() method, but it never goes in the
GLWidget list. (This solves a whole bunch of strange problems if you
select a few atoms, switch to residue-selection mode, then select a
residue.)

I need to add some documentation to the methods, I’ll do that tonight.

Thoughts? Complaints? Writing the code felt messy at times, so
there’s probably a cleaner way to do this.

If not, I’ll try to get Cut and Copy selected atoms working too.

Cheers,
-Geoff

P.S. Donald – when on Friday, May 11th will we call the freeze?

On May 10, 2007, at 9:10 PM, Donald Ephraim Curtis wrote:

way. Selection is more a property of the view than of anything else.
It just means we need to cleanup any old methods in the old primitive
classes.

Please don’t do this quite yet. I spent a while over the last few
days sorting out something which “just works.” As I said, it doesn’t
feel “clean” yet (e.g., right now, the widget list just reflects
residues) and does involve selection types.

On the plus side, having a list of selected atoms makes it much
easier to add a renderSelected call to the engines. We just pass that
list from the widget. :slight_smile:

What i’m not sure about is this though, what are residues? Do they
exist automatically?

A residue is a protein/DNA concept – it’s an amino acid or a nucleic
acid, so it’s a set of a few atoms. So an atom can be in only one
residue, but one residue includes multiple atoms. (A protein ribbon
view uses one cylinder to reflect an entire residue.)

Many molecules don’t really have a residue (e.g., benzene). So Open
Babel will get a “OBFragment” class sometime.

I’m not sure, maybe midnight? I’ll probably be out for the night, i
could also just do it on saturday morning when i wake up.

I think that’s fine. We should also have some sort of release notes
and user guide. For example, we want feedback. What works, what
doesn’t. Bugs, etc. But we also need to make clear that this is a
very early alpha/beta app and so they shouldn’t decide something like
"oh, it only does GAMESS input, it’s not for Gaussian" or “it doesn’t
do proteins.”

Cheers,
-Geoff

(Thu, May 10, 2007 at 02:55:13PM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:

OK, I’ve added support for “selection modes” – you can now load a
PDB file, and select a residue at a time, an atom, or a molecule.
There are some performance problems, but I hope to solve those after
the beta.

Tried it out! Really cool. I always like this stuff but it was
unbelievably hard to use in ghemical.

The scheme I’ve used currently stores a selection list in the
GLWidget. If you want to select or deselect an atom, you should go
through these methods. I check whether a residue should be selected
by the Residue::isSelected() method, but it never goes in the
GLWidget list. (This solves a whole bunch of strange problems if you
select a few atoms, switch to residue-selection mode, then select a
residue.)

I’m not really sure what you are doing with like, the selection stuff.
I have roughly looked at the code and I see what you did but there is
already selection stuff built into the Primitives. I understand where
the differences are coming from.

The selection stuff as was previously implement was as a property of the
primitives themselves, not the GLWidget, meaning if you select something
in one widget they also get selected in a difference widget (i don’t
know if this is right or not). The way you implemented it is to have
each widget with their own selection information, meaning a selection in
one widget will not be a selection in another. But i actually like this
way. Selection is more a property of the view than of anything else.
It just means we need to cleanup any old methods in the old primitive
classes.

What i’m not sure about is this though, what are residues? Do they
exist automatically? Does each atom have it’s own residue in a 1-1
correlation or can one atom have more than one residue? Selecting
residues will probably be easier when we can actually see them.

I need to add some documentation to the methods, I’ll do that tonight.

Thoughts? Complaints? Writing the code felt messy at times, so
there’s probably a cleaner way to do this.

If not, I’ll try to get Cut and Copy selected atoms working too.

Cheers,
-Geoff

P.S. Donald – when on Friday, May 11th will we call the freeze?

I’m not sure, maybe midnight? I’ll probably be out for the night, i
could also just do it on saturday morning when i wake up. If you think
we’re not ready thats fine but after friday we should at least freeze
functionality for sure, no new features.


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/


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

Oh, i see one thing. This “selectionList” member of GLWidget, the
problem that’s going to get us into trouble later on is that it’s
relying on Primitive::setSelected and also maintaining a list of
Primitives that have or have not been selected. 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.

  1. if we want selection to be a property of the primitives, then the
    selectionList should be a part of the Molecule code and not the
    GLWidget. Also, functions shouldn’t be based around the
    Molecule::selectionList. The reason i think you want “selectionList” is
    so that you have a list of selected atoms at your fingertips, rather
    than having to go through all atoms and test them. But it would be bad
    design to make the interface for selection based on this list. In this
    case each primitive should still have it’s own ::setSelected,
    ::toggleSelected function. If you want to do massive select/unselect
    these functions should go in Molecule (like in the GLWidget). When an
    atom gets selected it should emit a signal or let it’s parent know it’s
    selected. In short, we should add functionality to the already existing
    model to maintain a virtual selection list, not redesign around this
    list.

  2. if we want selection to be a property of each GLWidget then GLWidget
    should maintain a list of all the primitives which are selected, not
    those which “have been” selected. Then the list that GLWidget maintains
    is all primitives that are selected, if it’s not in the list it’s not
    selected.

We can’t have both for this simple reason, Molecule (and it’s sub
primitives) are a model, GLWIdget is a view (presenting / interacting
with the model). We can’t have GLWidget A with a selection different
from GLWidget B and expect that the shared molecule knows about them. I
shouldn’t say we “can’t” cause we can, but it would be bad software
design and is going to cause more problems in the future.


Donald

(Thu, May 10, 2007 at 07:10:34PM -0600) Donald Ephraim Curtis d@milkbox.net:

(Thu, May 10, 2007 at 02:55:13PM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:

OK, I’ve added support for “selection modes” – you can now load a
PDB file, and select a residue at a time, an atom, or a molecule.
There are some performance problems, but I hope to solve those after
the beta.

Tried it out! Really cool. I always like this stuff but it was
unbelievably hard to use in ghemical.

The scheme I’ve used currently stores a selection list in the
GLWidget. If you want to select or deselect an atom, you should go
through these methods. I check whether a residue should be selected
by the Residue::isSelected() method, but it never goes in the
GLWidget list. (This solves a whole bunch of strange problems if you
select a few atoms, switch to residue-selection mode, then select a
residue.)

I’m not really sure what you are doing with like, the selection stuff.
I have roughly looked at the code and I see what you did but there is
already selection stuff built into the Primitives. I understand where
the differences are coming from.

The selection stuff as was previously implement was as a property of the
primitives themselves, not the GLWidget, meaning if you select something
in one widget they also get selected in a difference widget (i don’t
know if this is right or not). The way you implemented it is to have
each widget with their own selection information, meaning a selection in
one widget will not be a selection in another. But i actually like this
way. Selection is more a property of the view than of anything else.
It just means we need to cleanup any old methods in the old primitive
classes.

What i’m not sure about is this though, what are residues? Do they
exist automatically? Does each atom have it’s own residue in a 1-1
correlation or can one atom have more than one residue? Selecting
residues will probably be easier when we can actually see them.

I need to add some documentation to the methods, I’ll do that tonight.

Thoughts? Complaints? Writing the code felt messy at times, so
there’s probably a cleaner way to do this.

If not, I’ll try to get Cut and Copy selected atoms working too.

Cheers,
-Geoff

P.S. Donald – when on Friday, May 11th will we call the freeze?

I’m not sure, maybe midnight? I’ll probably be out for the night, i
could also just do it on saturday morning when i wake up. If you think
we’re not ready thats fine but after friday we should at least freeze
functionality for sure, no new features.


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/


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


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/


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

On Friday 11 May 2007 02:25:51 Donald Ephraim Curtis wrote:

Oh, i see one thing. This “selectionList” member of GLWidget, the
problem that’s going to get us into trouble later on is that it’s
relying on Primitive::setSelected and also maintaining a list of
Primitives that have or have not been selected. 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.

As you also pointed out if in the future views can hide things then a view
could also contain “hidden” selections that are being manipulated/changed
despite not being visible which would not be very intuitive at all.

We can’t have both for this simple reason, Molecule (and it’s sub
primitives) are a model, GLWIdget is a view (presenting / interacting
with the model). We can’t have GLWidget A with a selection different
from GLWidget B and expect that the shared molecule knows about them. I
shouldn’t say we “can’t” cause we can, but it would be bad software
design and is going to cause more problems in the future.

These are my own thoughts after working with ghemical in the past and avogadro
a lot recently. Both approaches work but as Donald points out we do need to
make a decision and be consistent.

Marcus

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!