[Biojava-l] viewsequence is unchangeable?

[Kalle Näslund]

Maximilian Haussler wrote:

> Thanks for your extensive reply. I did exactly that, but (hack hack) 
> did not use changeable but standard java change support. Anyways, it's 
> no use.
> I'm using a sequence panel, but something that has to redraw sometimes 
> when there are new features. It is a sequence panel with many 
> different tracks (lines) and when there is a new feature added, 
> sometimes a new line has to be added. BJ design isn't made for this, 
> of course, so  I cannot re-build the multilinerenderers each time a 
> change is made (to expensive) and I cannot call revalidate of the 
> sequencepanel either, as it will not add new lines by itself.
> Oh geez, so i simply do a repaint of my sequencepanel anytime I'm 
> finished doing some modification. This is a nuisance but it works.
>
> I have no good design for my problem... I would perhaps need a 
> sequencepanel with dynamically updating lines, but I don't know how to 
> write that... or where to build upon, as it would not be an extension 
> of sequencepanel, but rather something new...
>
> Thanks nevertheless!
> Max
>
As i dont fully understand what it is you are trying to do, im not sure 
these suggestions are helpfull, anyway.

Im assuming that you have a MultilineRenderer setup, where each line 
renders a certain feature type. I dont know of the type of Feature data 
you connect to your Sequences, but i would assume that most changes to 
the Features, will not completely remove a certain Feature type from the 
Sequence, or add a new type. Most will just change the count of the 
different Feature types. So there is no need to rebuild the 
MultilineRenderer unless you remove or add a new type of Feature to the 
Sequence.
You could implement this by a ChangeListener setup, that listens for 
changes on the Sequence, and takes appropriate action, if a new type is 
added, or the last of a certain type is removed, and if so, rebuild the 
MultiLineRenderer.

Also, if most of your changes do not occur one and one, but in sets, you 
could do some uggly hacking, and just emit one ChangeEvent for the whole 
set of changes, and not one Event for each. This has the potential to be 
pretty uggly i guess but if you know what you are doing, it might be 
used to speed up your app, as a last measure.


mvh Kalle





> Kalle Näslund wrote:
>
>> Maximilian Haussler wrote:
>>
>>> Hi everyone,
>>>
>>> why is ViewSequence an implementation of the Unchangeable interface? 
>>> Isn't a view (among others) meant for adding features to an 
>>> otherwise unchangeable sequence?
>>
>>
>>
>> Exactly what a view is for, is a question you can argue a lot about i 
>> guess =). But, just from reading the javadocs of the class, it seems 
>> this one, is to be used to add data "on top" of another sequence. One 
>> example would indeed be to use it to add Features to an otherwise 
>> Unchangeable Sequence.
>>
>>> I have a class derived from the view, but I don't get it to notify 
>>> the GUI when changes occur, as I don't find the getChangeSupport() 
>>> in ViewSequence...
>>
>>
>>
>> ViewSequence extends Unchangeable, this is a minimal implementation 
>> of the Changeable Interface, that basicly just refuses any changes. 
>> The getChangeSupport() method belongs to the AbstractChangeable 
>> class. Most classes extend AbstractChangeable, so that is why you are 
>> used to always having getchangeSupport() around.
>>
>> As ViewSequence will never change, it will never emit any change 
>> events, and that is what the SWING gui widgets listen for, as a 
>> trigger to redraw, just as you say.
>>
>> I think that the correct way to fix this problem, is to have 
>> ViewSequence to emit change events, i guess alter it to extend 
>> AbstractChangeable, and then listen for Changes to the underlying 
>> sequence, and take appropriate action when change events are caught, 
>> aswell as emitting ChangeEvents when Features are added to the view 
>> itself.
>>
>>> [Well, simply adding standard java change support instead of this 
>>> overly complicated biojava system would also do the trick... :-) ]
>>
>>
>>
>> The biojava Changeability thingy, isnt realy that much more complex, 
>> atleast not from the view of the programmer, that just wants to make 
>> his class implement Changeable , and the added complexity has its 
>> uses. I wont claim that the  current BJ way is the greatest way 
>> though =)
>>
>> So, my suggestion would be to make your own ViewSequene class, that 
>> does listen for changes on the underlying Sequence, aswell as emiting 
>> changes. You would start by taking the ViewSequence class, make it 
>> extend AbstractChangeable instead of Unchanging, then add a 
>> ChangeListener to the underlying Sequence, and hammer togheter some 
>> code that does the right thing[tm] when the listener notices the 
>> underlying sequence have changed ( most likely, check if the change 
>> affects the features in the view, if so, take some action) and then 
>> have a change forwarder that also forwards the changes.
>>
>> Im not sure i have the time at hand, or the mental capability right 
>> now, to fix this for you, but if you try something like this, and get 
>> into problems, feel free to mail the ml again, and i will try to help 
>> as much as i can.
>>
>> mvh Kalle Näslund
>>
>>> Thanks
>>> Max
>>>
>>> _______________________________________________
>>> Biojava-l mailing list  -  Biojava-l at biojava.org
>>> http://biojava.org/mailman/listinfo/biojava-l
>>
>>
>>
>>
>>
>
>