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 and conjuction::update(condition, condition) calls a non-existent
method (conjunction::set_state()), 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. 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 ());
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. 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). I do therefore wonder if it is worth it.
Your approach is also rather inflexible - it can only synthesise from two
states.
Anyway, it is quite interesting.
Chris
_______________________________________________
libsigc-list mailing list
libsigc-list@gnome.org
http://mail.gnome.org/mailman/listinfo/libsigc-list
