[Urwid] detecting when an edit box has changed

[Eric S. Johansson]

Derek Peschel wrote:
> 	  So for something like edit.py (which Eric was probably not asking
> 	  about) my best plan is to modify the list-to-edit-widget interface,
> 	  so that keypres() returns a tuple instead of a single element.
> 	  The first element of the tuple is the key or None, as before.
> 	  The second element is a Boolean indicating whether the text has
> 	  changed from this keypress.  The first change to any line sets a
> 	  global flag for the set of lines.
> 
> 	  Normally the user can reset the flag with a key that runs a
> 	  command.  Some commands may need to set the flag, i.e., the list
> 	  widget may need public make_clean and make_dirty methods.;
> 
> 	  I'm still writing code so details above may be wrong.
> 

we are in the same space but I'm thinking of the problem slightly 
differently.

Each edit widget should have a reference value and a displayed value. 
The Boolean resulting from a difference test is the changed flag.  This 
also implies that an edit widget can go back to unchanged state and that 
there is probably a new method which sets the displayed value to the 
reference value (reset_display?).  It also implies that there may be a 
need to read the reference value.

For a singleton or even a small number of edit widgets, one can test 
them individually or invoke an individual callback.  callbacks make 
detecting change in a list of widgets relatively simple.  Logically, the 
aggregation of a series of tests is a multi-input or gate.  the initial 
common naïve implementation for a multi-input or gate can be difficult 
to implement in software but in this case, it's relatively easy.

If each edit widget has a callback function for it's changed state, the 
state aggregation widget is a simple counter.  Every time a widget has 
changed, you increment a counter.  Every time a widget goes back to 
unchanged, you decrement.  If the counter equal zero, nothing has 
changed.  Nonzero, something has changed.  No long lists to scan and 
it's relatively simple to implement (modulo locking).

you could even implement a change callback for the state aggregation 
class but that might be getting a bit abstract for some folks.

so to summarize, each edit widget has a callback invoked every time the 
state has changed from changed to unchanged or the reverse.  A state 
change aggregation class summarizes change via a counter.  If there is 
an asymmetrical number of counts, one of the widgets referring to that 
instance of the class is still in a changed state.  The state change 
aggregation class can also have a callback invoked on transition between 
changed and unchanged in either direction.

clear as mud?

--- eric