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

[Kalle Näslund]

Keith James wrote:

>>>>>>"Kalle" == Kalle Näslund <Kalle.Naslund@genpat.uu.se> writes:
>>>>>>
>
>[..]
>
>    Kalle> To be a bit more precise, the changes would be the
>    Kalle> following:
>
>    Kalle> 1. Move all methods from SequenceRenderContext to an inner
>    Kalle> class 2. Make SequencePanel accept SymbolLists by chaning
>    Kalle> void setSequence( Sequence s ); 3. Change of the method
>    Kalle> Sequence getSequence(); to return SymbolList instead, as
>    Kalle> one no longer can be sure that we are rendering a
>    Kalle> Sequence. ( i assume this can break things )
>
>So SequencePanel would have get/setSymbolList and the inner
>SequenceRenderContext would still have get/setSequence and the
>SequencePanel would do the necessary cast or wrapping of the
>SymbolList?
>
>As both Sequence and Alignment inherit from SymbolList I like the
>idea as long as the SequenceRenderContext interface does not change.
>
The SequenceRenderContext interface is not changed in any way, the only
change is that the the two following methods in the SequencePanel class

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

are replaced with

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

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

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

>
>However, not all implementations will benefit from having the
>SequenceRenderContext methods hidden. E.g. we have an application
>which uses the graphicsToSequence and sequenceToGraphics methods in a
>listener to implement middle-button-drag scrolling via
>SequenceViewerEvents; if you can't convert the symbol coordinate (from
>getPos method) to a graphics coordinate then the usefulness of a
>SequenceViewerEvent is greatly reduced. The methods to do this are in
>SequenceRenderContext.
>
I have to admit i totaly missed out on this kind of use for the 
SequenceRendercontext,
my appologies.

>
>The graphicsToSequence and sequenceToGraphics methods in
>TranslatedSequencePanel and PairwiseSequencePanel need to remain. I
>suppose these could chain through to an inner class too. The same goes
>for getRange, getDirection and getScale. But then, that accounts for
>most of the methods in SequenceRenderContext, so why move them if you
>then have to reimplement them by chaining ?
>
>
>
>As I said, I like the idea of moving from Sequence to
>SymbolList. However, most of the panels require the majority of the
>SequenceRenderContext methods to be useful in a dynamic application. I
>don't think we should fragment the behaviour of the various panels too
>much, unless it is very clearly documented.
>
I totaly agree on that. The more similar the api is, the easier to use, 
and from
that everyone benefit.

>
>
>I don't mean to be too negative - I'm in favour of the change in
>theory.
>
>
>Keith
>
No worries, this was just a proposal, and if you find the ideas bad, you 
should
be negative =).

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

mvh Kalle