Re: [rgui-dev] binding only to exposure

[Tom Sawyer]

On Thu, 2002-08-15 at 20:43, Massimiliano Mirra wrote:
> >   la = Label.new; la.value = x.a
> >   lb = List.new; lb.items = x.b
> > 
> > okay so far so good. now we wish to bind to them such that if a or b
> > should change (by whatever means), the gui will reflect that.
> > 
> >   x.bind(:a=) { |x| la.value = x }
> >   x.bind(:b=) { |x| lb.items = x }
> 
> (As an aside and not strictly related to the subject of the post: the
> meaning in the two lines of code above might well be made implicit in
> the two lines of code below.)

a possibility, but this does give the option to set something once and
only once, if that is all that is desired. so i think it's probably best
this way.
 
> > for a simple example of what i mean just imagine trying to give a gui to
> > the an object of type Array in and of itself. you'd have to bind on <<,
> > sort!, compact!, reverse!, and on and on, for every method that altered
> > the contents of the array, so that any changes would be "automagically"
> > reflected/ this simply becomes too unweildy.
> 
> Here is a costly way (but we're implementing Observer, and Observer
> almost always trades performance for simplicity):
> 
> class GuiManager 
>   def initialize(model)
>     @model = model
>   end
> 
>   def watch_changers(*methods)
>     methods.each do |method|
>       # append code to each watched method that calls the GuiManager
>       # change_event whenever that method is called
>     end
>   end
> 
>   def set_update_proc(&block)
>     @update_proc = &block
>   end
> 
>   def change_event
>     @update_proc.call
>   end 
> end
> 
> x = X.new
> gui_manager = GuiManager.new(x)
> 
> gui_manager.watch_methods 'a=', 'b=', 'update_from_query', ...
> 
> gui_manager.set_update_proc do |model|
>   label.value = model.a
>   list.items = model.b  
> end
> 
> 
> Now, when a `changer' method is called on the model, the update
> procedure defined with set_update_proc is called immediately
> afterwards and updates the interface.  The setup is very simple.  
> 
> The performance tradeoff is clear: all interface gets refreshed, even
> though only a small part of the data has changed.  This is very likely
> to cause slowness in the bigger applications.
> 
> What workarounds can be used?  Maybe dirty/clean flags somewhere to
> tell the changed data (in need of interface update) from the
> unchanged.  Or a more precise (yet less quick) setup:
> 
> gui_manager.bind_setter_getter('a=', ['a'])
> gui_manager.bind_setter_getter('b=', ['b'])
> gui_manager.bind_setter_getter('update_from_query', ['a', 'b'])

you have given a solution to coding of the above concepts. and that
intself is great. good to see alternative approaches. fyi, we can do
this with the current gutopia code. have you had a chance to take a
look?

(aside: HEY, HAS ANYONE ACCESSED THE CVS? DOES IT WORK OKAY? ANY
PROBLEMS?)

so let me reiterate, given your solution:

"so our problem is solved, but i must ask, at what cost? this is a very
simple dummy class we are working with. think of how involved it would
be to do this for something complex. every method that modified any
pertenant variables would require a binding with a proc specifying how
each of those variables are to modify the gui. this can quickly become a
very large task."

"for a simple example of what i mean just imagine trying to give a gui
to the an object of type Array in and of itself. you'd have to bind on
<<, sort!, compact!, reverse!, and on and on, for every method that
altered the contents of the array, so that any changes would be
"automagically" reflected, this simply becomes too unweildy."

thus i have implemented not just a public method monitor, but an
instance/class variable monitor, with which these problems are skirted.
of course there is the debate as to whether this is appropriate. but i
will stand on two aspects of this: 1) you don't have to use the variable
bindings if you don't with to, and 2) if it works why knock it?

~transami



~transami