Talk track filtering

[conseo]

Michael Allan wrote:
> conseo said:
> > Ok, I need to look into how I react on a new difference staged. I
> > guess I should:
> > 1. Light all messages related to that difference, (will implement
> > later)
> > 2. deselect the message item in the talk track and set a default
> > EMPTY message on stage if the message still fits the talk-track
> > selection. (this is not very clean) (?) Maybe we should model the
> > state changes of the stage and define how each track responds to
> > each stage state transition?
> 
> That wouldn't easily scale, too brittle.  It was a deliberate design
> choice to make the stage blind to the tracks.  Some suggestions:
I haven't meant to code anything, let alone exposing state of the tracks. 
Rather I have a state table in mind, which shows how a track is supposed to 
react. We can then easily track whether tracks miss some stage state 
transitions. See also below...

Example:

Page + Selection		Transition		Track-Reaction...
-------------------------------------------------------------------------
on-Bridge: nothing ---difference staged--> Highlight all messages of \
difference + deselect previous message...

This can be done in a state diagram as well, but a (large) table would be 
compacter.

While the stage does not know about the tracks, as far as I have understood 
you, the talk-track should know on which page it is staged (part of the stage 
state to me).

> 
> First, don't do anything unless you must.  For example, what do you
> mean by an EMPTY message?  Why is it necessary to stage it?

An element of the talk-track, a diff-message, is a tupel and selected together 
by the track. If the difference is deselected the message will no longer 
correspond to the difference and should be deselected imo.
> 
> Second, to be sure, the stage is your selection model (I think you
> agree).  "Selected" means "staged".  So just ensure the view obeys the
> model and never shows something as being staged when it is not.  If in
> doubt, it's always OK to show nothing as staged.  No great harm can
> come of that.
Agreed, but when the staged page is also relevant we have a lot of states, not 
only for the change in each property, but combinations thereof. You said that 
the difference should have a selectand dependant on the staged page, e.g. 
bridge or default...
> 
> You migh release it at that point.  If there are problems, we can
> point to them and discuss what to do.  (I'm keen to see it
> running. :-)
I am fiddeling with mailman to make it send messages through postfix. I have 
created Mann/p/sandkasten with vosim-40k already, but got stuck at mailman for 
a german Votorola list.

> 
> Earlier you said:
> > Wouldn't it be easier to handle all this [selectand twiddling] when
> > I call Stage.i().setDifference(someKey)? I feel a bit lost how this
> > belongs in the TalkTrack. ...
> 
> Probably the link track should swallow that bit of complexity.  (Maybe
> it should swallow the whole selectand business, period... not sure.)
> Let's wait though, and see how ugly it looks.
Ok. I would like to have clear state definitions though, where we already know 
them and mark all other state transitions as none for now.

conseo