Re: [sigc] conditions in libsigc

[Chris Vine <chris cvine freeserve co uk>]

On Monday 03 July 2006 21:48, Paul Pogonyshev wrote:
> Chris Vine wrote:
[snip]
> > 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.

libsigc++ couldn't possibly have "standard" conditions relating to whether an 
entry widget is empty or a check button is selected.  It is relevant to a 
particular GUI implementation.  libsigc++ could have a generic "observed" 
class which I now see that Ulrich Eckhardt has mentioned, which is a 
templated version of the accessor/mutator class I mentioned.  He is the 
maintainer so it is up to him whether that it is included in libsigc++ (it 
seems a bit trivial to me), but it will not do what you want.

gtkmm could implement your proposal, but first it does not require any changes 
to libsigc++, and secondly it seems pointless since you can aggregate gtkmm 
signals yourself if you want.

> Currently this is typically done (AFAIK) by calculating condition ``by
> hands'' and tracking its state.

It is done through glibmm signal proxies via the gobject signal/slot 
mechanism.  Gtk+ tracks the 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'.

See above.

[snip]

Chris