In article <8cal08$g23$1 at pegasus.csx.cam.ac.uk>,
James Bonfield <jkb at mrc-lmb.cam.ac.uk> wrote:
>>Following on from a few comments at a recent course, I am looking at a
>few cosmetic changes to the contig editor. Some (but not all) of these
>can easily be made user-configurable, so they shouldn't cause too many
>problems. I am posting here in order to obtain user feedback. Please
>speak up now, or suffer in silence whatever changes we decide!
>1. Consensus at the top. This has the great advantage of allowing
>quickly scrolling along without the consensus consistently moving up
>and down.
I'd like to generalise that and have the program allow you to select
certain reads to stay within view at all times. This would be
enormously useful to us. I have no preference as to where the consensus
goes.
>One person suggested that we make the editor window user resizable and
>that it should stay fixed at that size. However I'm unsure of exactly
>what this gains (and I think that the request was based more on
>annoyance of a continuously moving consensus). Any comments?
What it gets you is the ability to maintain your contig editor and some
other program side by side on the desktop without having to overlap one
another. I frequently want to compare a Gap4 assembly with an ACeDB
F-MAP display. The F-MAP display needs to be large, and it would be
nice if I could force the contig editor to a particular size so I don't
have to keep moving windows around, or raising and lowering them.
Window size should, in my opinion, always be under the control of the
user, and not the program. That's what window managers and scrollbars
are for.
>2. The status lines, when the consensus is displayed at the top,
>should be above the consensus. When the consensus is displayed at the
>bottom they'll be below the consensus. This has some vague symmetry,
>but realistically it is designed to make sure that the consensus is
>close to the sequences.
Fair enough, but most people expect a status line to be at the bottom of
the windows, don't they?
>3. Where do we put the ruler when the consensus is displayed at the
>top? I think it looks best between the consensus and individual
>sequences. An alternative is between the consensus and status lines,
>or finally at the top where it's always been. Unless we take the last
>option then this has implications for the names display as the very
>top line in the "DNA sequences" window does not have a corresponding
>line in the "sequence name" window.
Does that really matter? Seems fine to me. Of course, you can solve
this by putting the consensus read in a separate panel, wiuth the
scrolling tied together, of course. This separate panel could then of
course also be used for including the nominated reads that a user might
want on screen at all times, as I requested above, so it kills two birds
with one stone. It also means that you need to make very few coding
changes to the current sequence alignment code (if anything, I imagine
it would make it simpler, since it no longer needs to manage the
consensus sequence as a special case)
Does this make any sense?
>4. In order to cure the problem in (3), we could remove the C: and Q:
>values from the main display and put the << < > >> buttons in their
>place. (The C: and Q: values would be adjustable from a dialogue
>brought up using the settings menu). How often do people adjust these
>values during editing?
On a daily basis. Please don't remove those text boxes!
>Alternatively we could remove the << < > >>
>buttons as they duplicate functionality of the scrollbar, but
>personally I prefer having these scroll buttons next to one another
>rather than spread out over a large X distance (making fine scroll
>movement a laborious mouse-moving task).
>>Most of these issues are fairly simple to code, but we do not wish to
>support all possible combinations. So at present we propose to move
>the C: and Q: value boxes into a Settings menu dialogue and put the <<
>< > >> buttons in their place. This would be done regardless of where
>the consensus is and so would not be user-adjustable. The positioning
>of the consensus however will be user adjustable.
This change will make gap4 extremely awkward to use for my users.
Having to go into a menu, adjust a dialog box contents, and close it,
when all they have to do now is modify a value in a text box they can
see...
They never use the << < > >> buttons, in fact, but always just
juse the scroll bar to move around the sequence. You have functional
redundancy in the contig editor there; why not remove that first?
Tim.
