Re: [sigc] conditions in libsigc

[Paul Pogonyshev <pogonyshev gmx net>]

Chris Vine wrote:

> > Yes, it is useful, but I was thinking of something like this
> >
> >   sigc::condition  condition = entry.is_not_empty_trimmed () &
> > check_box.is_selected (); Gtk::SensivityController  controller (condition,
> > some_widget);
> >
> > You hardly need anything other than boolean variables for this kind of
> > stuff.  (Pointer vs. reference stuff etc. is not thought off yet, I'm
> > basing on a Java implementation.)
> >
> > Any type of variable might be useful, but standard operators for
> > boolean variables (and, or, not) are _very_ convenient to have.
> 
> You refer to Gtk, so are you confusing libsigc with the glib event loop?  
> Firstly, libsigc of itself knows nothing of Gtk/Gdk events: it is just a 
> callback mechanism.  Secondly, gtkmm classes already have signals 
> (implemented with libsigc) which you can connect to, which indicate whether 
> the state of a widget has changed.  For example, classes derived from 
> Gtk::Widget emit state events if a widget is maximised or iconised, as well 
> as visibility, style and size events (and many others).  As you refer to a 
> "check_box", Gtk::CheckButton emits activate, clicked and toggle events.

I'm not confusing anything.  If there is no condition class, Gtkmm cannot
return conditions.  They have to be implemented first and I think sigc++ is
a better place for it than Glibmm since they are not wrappers over Glib.

I'm not controlling neither sigc++ nor Gtkmm development, but I think that
it is very good to eventually have first to implement `condition' class and
second to return a set of ``standard'' conditions.  E.g. a condition that
an entry is not empty or a check button is selected.  The user (of the
libraries) can then combine conditions as they wish to produce ``advanced
conditions'', combinations of simple ones.

Currently this is typically done (AFAIK) by calculating condition ``by
hands'' and tracking its state.  For a complicated condition you need to
watch the state of several widgets (say, two entries and a check button)
manually.  If you forget just one of those, you get errors where a widget
is erroneously sensitized/desensitized or shown/hidden.  Besides, there
is a separate case of initial state which, ideally, should be computed
using the same rules.

Currently all is done separately.  I propose to aggregate everything in
one object of type `sigc::condition'.

Compare (probably there are errorsk, I haven't coded with Gtkmm for a
while):

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

    // To ensure initial state.
    set_widget_sensitivity ();

    ...

    void
    Class::set_widget_sensitivity () const
    {
       some_widget->set_sensitive (!entry->get_text ().empty () && check_button->get_active ());
    }

and

    sigc::condition  condition = entry->get_non_empty_condition () & check_button->get_is_active_condition ();
    Gtk::SensitivityController  controller (some_widget, condition);

The code is approximate, but should illustrate what I mean.

Paul