Re: [sigc] conditions in libsigc

[Paul Pogonyshev <pogonyshev gmx net>]

Chris Vine wrote:
> On Tuesday 04 July 2006 18:10, Paul Pogonyshev wrote:
> > I wrote:
> > > > This is getting pretty pointless.  Lets end it here, as an ounce of
> > > > code is worth a pound of words.
> > >
> > > OK.  I'll try to write something.
> >
> > Here is `something'.
> >
> > I didn't write anything complete, therefore things are not properly
> > optimized, application doesn't terminate when both windows are closed etc.
> >
> > Condition creation is ugly because there is no support from Gtkmm.
> >
> > Probably there should be functions like `Gtk::Widget::set_sensitive
> > (sigc::condition)' instead of all this `SensitivityController' stuff.
> 
> I understand now what you are doing and it's an interesting way of 
> encapsulating combined states to arrive at a composite one, or to acquire a 
> further level of indirection or mediation, which might on occasion be useful.
> 
> There are a few minor points of implementation about the code which are not a 
> criticism (your code was just to convey the idea) - Glib::RefPtr is not used 
> correctly

Why (though it is not important for conditions)?

> and conjuction::update(condition, condition) calls a non-existent  
> method (conjunction::set_state()),

This method is defined in `condition_impl' and `conjunction' inherits that
class.  So it is not non-existent.

> but the intention is clear enough and the  
> absent conjuction::set_state() method was probably just a result of a 
> cut-and-paste - I can see what it would do.
> 
> However, your code does the updating of the Gtk::Button twice, which 
> illustrates what would have been my point.

No, it doesn't.  Maybe I should have used different variables, but one
window's button is only condition-driven, while the other's is `traditional'.
You can make sure by deleting the second window from the code.  Only
conditions are left and the first button is still working.

> It does it once via  
> Windows::controller (a SensitivityController object) employing the condition 
> object approach which you propose.  It does it again the "normal" 
> gtkmm/libsigc++ way, via the following lines in Windows::Windows():
> 
>   entry->signal_changed ().connect (sigc::mem_fun (*this,
>                              &Windows::update_sensitivity));
>   check_button->signal_toggled ().connect (sigc::mem_fun (*this,
>                              &Windows::update_sensitivity));
> 
> The Windows::update_sensitivity() slot just does this:
> 
>   button->set_sensitive (entry->get_text_length () > 0 &&
>                          check_button->get_active ());

As I mentioned above, different methods of sensivity controlling are applied
to different buttons in different windows.

> This slot tests and employs the state information retained by the gtkmm 
> object, rather than by the SensitivityController object.  In other words, all 
> your code for condition objects can be replaced by these lines of 
> "traditional" code.

I'm not sure I understand you, but will try to answer.  Yes, conditions are
nothing new.  They are merely wrappings around currently possible code, which
make life easier.  More code is moved to the libraries and less is left for
you to write.  Instead of writing new callback, connecting it and maybe setting
the initial state you are done with combining standard conditions and creating
Gtk::SensibilityController (or calling Gtk::Widget::set_sensitive (sigc::condition)
if that is implemented.)

> In its place, to implement the condition feature it is  
> necessary to write implementation classes for each condition on a 
> case-by-case basis (in this case, the ToggleButtonActiveCondition and 
> EntryNotEmptyCondition classes).

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 do therefore wonder if it is worth it.   

Not really if they are not implemented in the libraries, because then
implementing conditions costs more than they save.  If, however, conditions
are implemented in the libraries, I'm sure it is worth it, saves coding for
library users and makes error probability smaller.

> Your approach is also rather inflexible - it can only synthesise from two 
> states.

Yes, conditions cannot solve all problems.  If you need some advanced checking,
you should use traditional scheme, which doesn't go away.  However, I'm sure
that 75% of appropriate tasks are solvable with `standard' conditions.

Paul