Re: MVC and GTK

[Owen Taylor <otaylor redhat com>]

Paul Barton-Davis <pbd op net> writes:

> I'd like to once again mention that it would be nice to see a roadmap
> entry for GTK that includes making the toolkit much more
> Model-View-Controller friendly. I would be quite willing to help with
> the design and/or part of the implementation of this.
> 
> I've just spent several hours having to hack together solutions for a
> system in which there are 3 different windows all displaying
> "Controllers" for the same "Model", and its really ugly doing this in
> GTK. 
> 
> The typical solution that I have to adopt is to use a flag that tells
> the handler for (e.g) "toggled" to do nothing, so that I can 
> safely call button.set_active (TRUE) without creating an infinite
> loop. This is not very friendly, and given the apparently widespread
> acceptance that MVC is the "correct" way to write GUI's of moderate or
> greater complexity, it would be very nice to see GTK+ support this
> internally. 

Here's how to do it, cleanly, with existing GTK+:

void
my_toggled_handler (GtkWidget *button, gpointer data)
{
  MyData *my_data = data;
  gboolean new_state = gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (button));
 
  if (my_data->state != new_state)
    set_state (my_data, new_state);
}

void
set_state (MyData *my_data, gboolean new_state)
{
  my_data->state = new_state;
  gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (button), new_state);
  [ Do something with the new state ]
}

The point is, don't consider ::toggled as "my state toggled" but as
"my state may have changed". 

I struggled quite a bit with blocking signals, setting flags, etc,
before I came to the realization that it's all easy, as long as
retrieve the current state of the button in the ::toggled handler
instead of treating it as a command to toggle your existing state..

(Perhaps we should rename the signal to ::changed just to encourage
people to program in this way...)

Regards,
                                        Owen