Re: [rgui-dev] binding only to exposure

[Massimiliano Mirra]

On Tue, Aug 20, 2002 at 02:44:48PM -0600, Tom Sawyer wrote:
> > 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

> > 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?

Sorry, no.  I am still struggling with getting a mixed LAN
authenticate from a single source, and whenever I get a spare hour I
try to work on rpkg.  That barely leaves me time for sleeping, so I'm
afraid I won't be of much help on the actual coding side here. :-(((

> "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."

True.  Either one effectively binds *all* widgets to *each* getter,
with watch_methods and the single block performing the whole update
[*], or binds selected widgets to selected variables.  Both are
problematic with larger applications (well, the first one still works
with compiled languages, but we're not using one).

[*] It occurs to me that some update policy could be implemented for
the widgets, such as `update only if value is different' or `update if
no other update occurred in the last half second'.

> 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?

Well, you know my take on that. ;-) But it's ok to experiment, in any
case we'll get better acquainted with the domain.


Massimiliano