Re: [sigc] conditions in libsigc

[Paul Pogonyshev <pogonyshev gmx net>]

Murray Cumming wrote:
> On Thu, 2006-07-06 at 23:07 +0300, Paul Pogonyshev wrote:
> > Yes, but this should be done in the library.  All this classes should belong
> > to Gtkmm and you don't write them yourselves.  Tracking sensitivity or
> > visibility is a common task and any non-trivial application does that.  Why
> > not transfer this common task to the GUI library (Gtkmm)?
> 
> I have not read this whole thread, and I'm not going to - it's far too
> verbose. But I might read a short summary that shows me clearly 
> a) What people apparently have to do repeatedly now with gtkmm..

It is a very common task to change sensitivity of a widget.  Less so to
change its visibility.

> b) What people would do instead with this new thing.

Currently, you have to 1) set sensitivity (some state) to a computed value;
2) track when that computed value changes its state, by connecting to the
appropriate callbacks; if the rules change, you have to not forget to keep
the computation and state tracking in sync; and 3) set the initial state
(sometimes).  Note that the initial state should also be in sync with
points 1) and 2).

I propose to do all the steps at once, using `condition's.  This roughly
corresponds to step 1), while all the rest is done automatically.

Using conditions (doesn't work currently, of course; how it should look
like):

    button->set_sensitive (entry->get_not_empty_condition () & check_button->get_active_condition ());

Traditional method:

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

    // Set initial state.
    update_sensitivity ();  

    ...

    void
    update_sensitivity ()
    {
      button->set_sensitive (entry->get_text_length () > 0 && check_button->get_active ());
    }

> Note also that you can already get notification of property changes from
> gtkmm objects, like so:
> widget.property_something().signal_changed().connect( ... )

Yes.  I propose to simplify it (writing less code) and make less error-
prone (all is done only once and in one place.)  This is at a small
cost to efficiency, which is not important in GUI.

Paul