Subject: Re: [linux-audio-dev] Re: MVC
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Sun May 11 2003 - 06:03:13 EEST
>So for every "set-function" you would like to have a
>"set-internal-function " that doesn't emit signals for the changes
>that were done?
exactly.
>What about if the view wants to disable some widgets when the record button
>gets pressed. If the view would be using such a function for setting the
>value when the model changes it would have to manually handle it.
the view always handles changes from the model "manually". thats the
whole point of the view: to map the state of the model into some
visual representation. when it chooses to show a button depressed (or
insensitive, or whatever), it is doing something absolutely different
from the user pressing buttons. i think it should be able to use a
different set of methods, or the same methods under different semantic
conditions.
in your example, you had no sign of any model at all, and that's where
the problem arises. the View has to respond to changes in the Model
that it did not initiate, and for most GUI programming, this is
completely backwards: the toolkit expects that the vast majority of
changes to the visual appearance of widgets will be caused by
keyboard/mouse interaction. Add a MIDI controller to a DAW, and this
assumption completely breaks down. View::set_record(bool) now becomes
irrelevant: the user never clicks on the on-screen button, and this
method is never called. instead, in Qt terms, you've got:
class View
{
public:
View (Model&);
public slots:
void handle_model_record_enable_change ();
private:
Model& model;
};
View::View (Model& m)
: model (m)
{
connect (&model, SIGNAL(record_enable_changed(void)),
this, SLOT (handle_model_record_enable_change(void)));
}
>duplication). Now if you don't let the widgets block but just block
>the whole notifications from the View (not single widgets) you can
>simply update the view and don't get feedback loops. You might want
>to create those "set-internal" functions for the View, so that you
>don't have to explicitly block and unblock the View's signals,
>though.
Views don't send notifications. Their internal structure (which
widgets they use, etc.) is not public knowledge. A View does just one
thing: maps the state of the Model into a visual representation.
Now, what gets a bit complicated is that in most real-world MVC
programming, you rarely have pure Views and pure Controllers. The most
obvious example is a button: it acts as both a View (indicating
whether or not some aspect of the Model is on or off) and as a Control
(allowing the user to turn that same aspect of the Model on or off).
A Control operates directly on the Model using methods provided by the
Model. When the user presses a button acting as a Control, the GUI
code will end up calling some method of the Model to change the
Model's state; the Model will (probably) send a notification of the
change, and any Views that care about it will update themselves.
This ends up creating a completely vision of how a GUI should work:
the mouse click on the button is merely a request to change the Model
state, and nothing happens to the visual appearance of the button
until (and if) the Model does actually change.
--p
This archive was generated by hypermail 2b28 : Sun May 11 2003 - 06:06:37 EEST