Re: [sigc] conditions in libsigc

[Chris Vine <chris cvine freeserve co uk>]

On Thursday 06 July 2006 21:07, Paul Pogonyshev wrote:
> Chris Vine wrote:
> > 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)?

Glib::RefPtr is designed to reference objects derived from GObject (sorry, I 
can't remember their glibmm class designation, probably Glib::Object) but not 
from GtkObject (Gtk::Object).  Classes derived from Gtk::Object are owned by 
the container in which they are placed, if you provide they are to be managed 
(as you did).  If you assign them to a Glib::RefPtr you will need to 
increment the reference count when doing so in order to pass ownership to the 
Glib::RefPtr smart pointer.  If you don't have them as managed objects, you 
don't need to increment the reference count (but you may have to call 
gtk_object_sink() on them to eliminate the floating reference - I am not sure 
whether you need to do this in gtkmm because I either use the raw C objects 
or, with gtkmm, have them managed by the container).

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

Yes I missed that.

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

OK, I see - I was misled by the fact that you had the window pointer as a 
class member, when it is only local to the constructor and used twice (and 
the same with the other members, other than the pointer to the Gtk::Button 
object).  I had missed on reading through the code that you had done 
everything twice with two equivalent windows implemented in the two different 
ways.

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

My comments assumed it was implemented in the library.  The choice is between 
three lines of code and, as I said and you agree, writing implementation 
classes for each condition derived from condition_impl.

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

With a certain sense of deja vu, this would be relevant to gtkmm rather than 
the libsigc++ library (yes, I know you want the substructure in libsigc++, 
but I am talking about the condition implementation classes here, which is 
what is relevant to any "standard" conditions you propose).  Furthermore, in 
my opinion (I accept not in yours) I doubt that there are sufficient 
synthesised conditions not already in gtkmm which are suitable as a standard.

Chris