Re: [sigc] conditions in libsigc

[Paul Pogonyshev <pogonyshev gmx net>]

Chris Vine wrote:
> 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.

Yes, but I'm not expecting sigc++ to handle all the GUI aspects.  I expect
it only to provide a basement for this, like it provides signals.

> 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.

I can do lots of stuff.  For instance, I can (in theory) reimplement all
Glibmm.  So what?

> > 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.

Did you look at my code examples?  Conditions vs. custom aggregation of signals
have two advantages: 1) less coding, and 2) less error probability, since
condition is specified only once and you don't have to synchronize condition
and state tracking manually (plus maybe setting of initial state.)

Paul