Opened 5 years ago

Last modified 5 years ago

#4370 assigned defect

coordset slider increment

Reported by: pett Owned by: Tom Goddard
Priority: minor Milestone:
Component: MD/Ensemble Analysis Version:
Keywords: Cc:
Blocked By: Blocking:
Notify when closed: Platform: all
Project: ChimeraX

Description

The up/down buttons on the coordset slider increment by one, even when the next coordset is more than one away. They should just move on to the next coordset regardless of numbering.

Change History (3)

in reply to:  1 ; comment:1 by goddard@…, 5 years ago

I am really wondering whether we want to go down this road where the MD trajectories can have arbitrary frame numbering with arbitrary gaps.  Of course we can handle it and the code already does, but for the user it seems like a nightmare of extra complexity versus the loaded frames always being 1,2,3,....  Take this Fraser class for example.  The students have no idea the files have only every 50th frame.  So if you try "coordset  #1  1,100" because 100  frames  were read you are likely to be disappointed and confused to see only 2 frames play.  My gut feeling is that the extra capability allowed by arbitrary numbering is not nearly worth the confusion and it will cause.

That said, if we are sure we want that design I guess every method (commands, GUI, Python) should be based on the arbitrary frame numbering instead of just an index 1,2,3....


comment:2 by pett, 5 years ago

I see your point, but after some thought I think I do want to keep the current behavior. With the change to the PDB reading it won't be encountered in day to day use very often now. A couple of the reasons for keeping it are:

1) I don't like the auto-compaction after coordset deletion that the alternative implies. Good chance of blindsiding developers, and hard to do efficiently for multiple deletion.
2) Allows reading every Nth frame of a large trajectory naturally, and possibly reading in more intermediate frames later.

Anyway, that's why this ticket prioritized as minor.

in reply to:  3 ; comment:3 by goddard@…, 5 years ago

Ok, seems reasonable.  The trouble is it creates complicated code to handle rare cases, and that code ends up not working.  In this case the QSpinBox probably has callbacks for you to do whatever you want up uparrow or downarrow but it is hard to find time to do that when no one is going to benefit, and a naive implementation that for instance scans the entire set of trajectory frame ids is likely to hurt performance for many people.  So I suspect this enhancement will remain undone.

Note: See TracTickets for help on using tickets.