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
_______________________________________________
libsigc-list mailing list
libsigc-list@gnome.org
http://mail.gnome.org/mailman/listinfo/libsigc-list
