10 May
2003
10 May
'03
7:11 p.m.
On Saturday May 10 2003 23:57, Paul Davis wrote:
take a simple example: someone is using a MIDI control
surface, and
they press a button that causes a track in ardour to become
rec-enabled. we want the GUI to show that, just as if they had pressed
it in the GUI. when you change the appearance of the view to match the
model, it can be hard to do this in a way that doesn't make it appear
to the GUI toolkit that the user has in fact pressed the GUI
button. this then causes an entire cycle of state change code in the
model, since presumably, when the GUI button is pressed, something is
supposed to happen in the model.
consequently, with GTK+ 1.2 (at least), you end up having to have lots
of checks to see if (a) the new model state is the same as the
existing model state (and do nothing to the model if so) and (b) the new
model state matches the current view state already (and do nothing to the
view if so).
it would be much nicer to be able to have methods for setting the view
state that are explicitly acknowledged as coming "from" the
program, and are not related to keyboard/mouse events driven by the
toolkit. i don't know of any toolkit that does this (which is not to
say they don't exist).
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?
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.
consider this example if Qt would have those functions:
class View
{
public:
View();
public slots:
void setRecord( bool );
private:
QPushButton *_button;
QFrame *_frame;
}
View::View()
{
connect( _button, SIGNAL( toggled( bool ) ),
_frame, SLOT( setEnabled( bool ) ) );
}
void View::setRecord( bool on )
{
_button->setOnInternal( on ); // does not emit signals
_frame->setEnabled( !on );
}
Effectively you have to duplicate the setEnabled call (I hate code
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.
--
C'ya
Matthias
________________________________________________________
Matthias Kretz (Germany) <><
http://Vir.homeip.net/
MatthiasKretz(a)gmx.net, kretz(a)kde.org,
Matthias.Kretz(a)urz.uni-heidelberg.de