Re: conditions

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]