Paul Barton-Davis wrote:
> 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.
>
> At the very least, we need ways to inhibit the emission of signals
> from widgets so that they can be adjusted "silently" when notification
> is received that things have changed (e.g. as a result of action in
> another view) and they need to be updated to reflect that.
The "toggled" signal is frustrating. The call to gtk_signal_connect
returns a "handler ID" that you can use in subsequent calls to
gtk_signal_handler_block() and gtk_signal_handler_unblock() to
temporarily disable a specific signal.
In practice, keeping track of individual handler IDs is tedious, so the
SDPGTK library provides BlockAllEvents() and UnblockAllEvents() methods
at its container level, which works out well.
Regards,
Timothy M. Shead
[EMAIL PROTECTED]
_______________________________________________
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
