[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rgui-dev] binding only to exposure
From: |
Tom Sawyer |
Subject: |
Re: [rgui-dev] binding only to exposure |
Date: |
20 Aug 2002 14:44:48 -0600 |
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