Re: Update of GtkRadioMenuItems wihtout emitting any signal
- From: Paul Davis <pbd Op Net>
- To: "Mark R. Rubin" <markrubn pacbell net>
- Cc: Havoc Pennington <hp redhat com>, Ignacio Nodal <inodal teleline es>, GTK-List <gtk-list gnome org>
- Subject: Re: Update of GtkRadioMenuItems wihtout emitting any signal
- Date: Sat, 16 Feb 2002 17:56:14 -0500
> 1) object->state() is an additional requirement on the Model
> object's public interface. Conceptually, what business does a
> View widget have knowing about the Model? It should just be
> told what to display.
well, it has to have access to whatever parts of the state are
required to display the state.
> 2) Potential mismatch between Model object's internal state and
> View widget's represention of same. Example: Model keeps
> double values, GtkAdjustment uses gfloats. Or: Model keeps
> HTML/RTF/internationalized text, GtkText uses GtkText(??), some
> HTML widget uses HTML, so Model has to export multiple types of
> state (or maybe multiple overloads of operator!=()).
this can certainly become a problem.
>> Controller::do_something_to_model (Model *model)
>> {
>> model->set_state (foo, this);
>> }
>>
>> this causes "object" to emits its "StateChanged" signal.
>
>o Is "object" the Controller, or the Model?
its the Model.
>o Bigger question: Do you use libsigc++ signals for *all* your MVC
> communication (both Controller-to-Model and Model-to-View)?
yes, for everything.
>o But for Model-to-View I just directly call the gtkmm methods:
>
> Model::some_method()
> {
> _state1 = some_computation() ;
> _togglebutton1.set_active(_state1) ;
> }
that breaks the anonymity principle. a Model should have *zero*
knowledge of the View or Controllers. if you don't do this, you cannot
have multiple Views, for example, and you can't reimplement the View
without reimplementing the Model. having the Model drive the View
directly is not really MVC, and in my experience, not very good OOP either.
>o I don't write my own methods for Views and Controllers -- they're
> just gtkmm widgets, used as-is. I don't derive from them and
> extend/override (except for Gtk::DrawingArea).
I generally find that I have to connect to to button press/release
and keypress signals and so forth, but i rarely override them. the
main hack i have to do is to call gtk_signal_emit_stop_by_name()
because a button press on a widget drives a change of visual
appearance in the widget that cannot happen until the Model state
change actually takes place (and it may never take place for reasons
that the Controller doesn't know about).
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]