Re: [sigc] conditions in libsigc

[Chris Vine <chris cvine freeserve co uk>]

On Tuesday 04 July 2006 18:10, Paul Pogonyshev wrote:
> I wrote:
> > > This is getting pretty pointless.  Lets end it here, as an ounce of
> > > code is worth a pound of words.
> >
> > OK.  I'll try to write something.
>
> Here is `something'.
>
> I didn't write anything complete, therefore things are not properly
> optimized, application doesn't terminate when both windows are closed etc.
>
> Condition creation is ugly because there is no support from Gtkmm.
>
> Probably there should be functions like `Gtk::Widget::set_sensitive
> (sigc::condition)' instead of all this `SensitivityController' stuff.

I understand now what you are doing and it's an interesting way of 
encapsulating combined states to arrive at a composite one, or to acquire a 
further level of indirection or mediation, which might on occasion be useful.

There are a few minor points of implementation about the code which are not a 
criticism (your code was just to convey the idea) - Glib::RefPtr is not used 
correctly and conjuction::update(condition, condition) calls a non-existent 
method (conjunction::set_state()), but the intention is clear enough and the 
absent conjuction::set_state() method was probably just a result of a 
cut-and-paste - I can see what it would do.

However, your code does the updating of the Gtk::Button twice, which 
illustrates what would have been my point.  It does it once via 
Windows::controller (a SensitivityController object) employing the condition 
object approach which you propose.  It does it again the "normal" 
gtkmm/libsigc++ way, via the following lines in Windows::Windows():

  entry->signal_changed ().connect (sigc::mem_fun (*this,
                             &Windows::update_sensitivity));
  check_button->signal_toggled ().connect (sigc::mem_fun (*this,
                             &Windows::update_sensitivity));

The Windows::update_sensitivity() slot just does this:

  button->set_sensitive (entry->get_text_length () > 0 &&
                         check_button->get_active ());

This slot tests and employs the state information retained by the gtkmm 
object, rather than by the SensitivityController object.  In other words, all 
your code for condition objects can be replaced by these lines of 
"traditional" code.  In its place, to implement the condition feature it is 
necessary to write implementation classes for each condition on a 
case-by-case basis (in this case, the ToggleButtonActiveCondition and 
EntryNotEmptyCondition classes).  I do therefore wonder if it is worth it.  
Your approach is also rather inflexible - it can only synthesise from two 
states.

Anyway, it is quite interesting.

Chris