[linux-audio-dev] Re: MVC

[Matthias Kretz]

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 at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20030510/106bdd03/attachment.pgp>