Re: conditions

[Paul Davis <paul linuxaudiosystems com>]

On Tue, 2006-07-11 at 19:41 +0300, Paul Pogonyshev wrote:
> Hi,
> 
> I'd like to propose the following extension to Gtkmm.
> 
> Currently, all non-trivial programs do something like this many times:
> 
>     entry->signal_changed ().connect (sigc::mem_fun (*this, &Windows::update_sensitivity));
>     check_button->signal_toggled ().connect (sigc::mem_fun (*this, &Windows::update_sensitivity));
> 
>     // Set initial state.
>     update_sensitivity ();  
> 
>     ...
> 
>     void
>     update_sensitivity ()
>     {
>       button->set_sensitive (entry->get_text_length () > 0 && check_button->get_active ());
>     }
> 
> With conditions it can be simplified to
> 
>     button->set_sensitive (entry->get_not_empty_condition () & check_button->get_active_condition ());

this is the fallacy in your argument.

as was outlined very clearly by someone yesterday, you are basically
trying to write a functional programming language. all it takes is for a
more complex relationship between various conditional values and the
widget sensitivity, and your proposal needs to be expanded dramatically
in scope. how dramatic? well, it becomes an entirely new programming
language.

> This gives two advantages: 1) less coding, and 2) less error probability
> since you don't have to keep in sync state computation and change tracking,
> it is done automatically.  (I.e. in the example above update_sensitivity()
> function must be connected to appropriate signals and if the function itself
> changes, the signal set might change too; with conditions this is done
> automatically.)
> 
> Downsides:
> 
> - Gtkmm must support Gtk::Widget::set_sensitive (condition) methods (few
>   methods, like set_sensitive(), set_visible() etc.) and, more importantly,
>   standard conditions like Gtk::ToggleButton::get_actve_conditions() (more
>   methods in various classes.)  This also involves a few fields for each
>   widget class for an efficient implementation.

your proposal is currently covering a single area of widget behaviour.
if its justified doing it for sensitivity, there are other bistate
aspects of widget behaviour that it should also be provided for. this
seems wrong.

--p