[Biojava-l] Proposal for some changes in the SequencePanel class.

[Keith James]

>>>>> "Kalle" == Kalle Näslund <Kalle.Naslund@genpat.uu.se> writes:

[...]
 
    Kalle> The SequenceRenderContext interface is not changed in any
    Kalle> way, the only change is that the the two following methods
    Kalle> in the SequencePanel class

    Kalle> Sequence getSequence(); void setSequence( Sequence s );

    Kalle> are replaced with

    Kalle> SymbolList getSymbolList(); void setSymbolList( SymbolList
    Kalle> sList );

    Kalle> And its then upp to the SequenceRenderContext to make sure
    Kalle> the that the correct casts and wrapping are made, so the
    Kalle> return values of the SequenceRenderContext methods are
    Kalle> sane. Just as you describe it.

    Kalle> This makes it possible to just take a
    Kalle> SequenceRenderContext, assing an Alignment to it, and then
    Kalle> connect the appropriate MultiLineRenderer/
    Kalle> AlignmentRenderer/SymbolRenderer/FeatureRenderer etc and
    Kalle> you have a very nice visualisation of your alignment.

This sounds good. The changes required to achieve the extra benefits
are small.

[...]

    Kalle> To summarise this, am i correct if i from this draw the
    Kalle> conclusion that you are against moving the
    Kalle> SequenceRenderContext implementation from the SequencePanel
    Kalle> into an inner class, because this would make several nice
    Kalle> things impossible to do ( i didnt knew that it would break
    Kalle> the things you mention ).  But that changing the
    Kalle> SequencePanel so it accepts SymbolLists instead of
    Kalle> Sequences might be acceptable, if it doesnt mess upp other
    Kalle> things ?

That's right. I am against moving SequenceRenderContext for two
reasons:

1. sequenceToGraphics, graphicsToSequence, getScale, getRange and
   getDirection are very useful (or essential under some circumstances)

2. Implementing these by chaining to an inner class implementation
   would be possible, but the application programmer would no longer
   be certain that all (or any) of them would be present as they would
   no longer be constrained by an interface. This could lead to
   fragmentation of the panel API for these methods.

I'm in favour of the change to get/setSymbolList instead of
get/setSequence. I think there should be standard behaviour for Panels
which can only render a single biosequence (e.g. a SimpleSymbolList)
and are passed several (e.g. a SimpleAlignment).

I'll be able to modify TranslatedSequencePanel and
PairwiseSequencePanel to the new methods if we can reach an
agreement. (By the way, did you know that TranslatedSequencePanel
renders 8x faster than SequencePanel ;)

I'd really like to see an Alignment renderer. Once we have one we will
get PostScript and SVG alignment rendering and imagemap generation for
free.

Mmmmm... beer^H^H^H^H sequence alignments.

Keith

-- 

-= Keith James - kdj@sanger.ac.uk - http://www.sanger.ac.uk/Users/kdj =-
Pathogen Sequencing Unit, Wellcome Trust Sanger Institute, Cambridge, UK