The aRts Handbook
Prev | Chapter 6. MCOP: Object Model and Streaming | Next

# 6.3. Attribute change notifications

Attribute change notifications are a way to know when an attribute changed. They are a bit comparable with Qt™'s or Gtk's signals and slots. For instance, if you have a GUI element, a slider, which configures a number between 0 and 100, you will usually have an object that does something with that number (for instance, it might be controlling the volume of some audio signal). So you would like that whenever the slider is moved, the object which scales the volume gets notified. A connection between a sender and a receiver.

MCOP deals with that by being able to providing notifications when attributes change. Whatever is declared as "attribute" in the IDL, can emit such change notifications, and should do so, whenever it is modified. Whatever is declared as "attribute" can also receive such change notifications. So for instance if you had two IDL interfaces, like these:

       1  interface Slider {
       2          attribute long min,max;
       3          attribute long position;
       4  };
       5  interface VolumeControl : Arts::StereoEffect {
       6      attribute long volume; // 0..100
       7  };

You can connect them using change notifications. It works using the normal flowsystem connect operation. In this case, the C++ code to connect two objects would look like this

       1
       2 #include <connect.h>
       3 using namespace Arts;
       4 [...]
       5 connect(slider,"position_changed",volumeControl,"volume");

As you see, each attribute offers two different streams, one for sending the change notifications, called ``attributename`_changed`, and one for receiving change notifications, called `attributename`.

It is important to know that change notifications and asynchronous streams are compatible. They are also network transparent. So you can connect a change notification of a float attribute of a GUI widget has to an asynchronous stream of a synthesis module running on another computer. This of course also implies that change notifications are not synchronous, this means, that after you have sent the change notification, it may take some time until it really gets received.

## 6.3.1. Sending change notifications

When implementing objects that have attributes, you need to send change notifications whereever an attribute changes. The code for doing this looks like this:

       1  void KPoti_impl::value(float newValue)
       2  {
       3      if(newValue != _value)
       4      {
       5          _value = newValue;
       6          value_changed(newValue); // <- send change notification
       7      }
       8  }

It is strongly recommended to use code like this for all objects you implement, so that change notifications can be used by other people. You should however void sending notifications too often, so if you are doing signal processing, it is probably the best if you keep track when you sent your last notification, so that you don't send one with every sample you process.

## 6.3.2. Applications for change notifications

It will be especially useful to use change notifications in conjunction with scopes (things that visualize audio data for instance), gui elements, control widgets, and monitoring. Code using this is in kdelibs/arts/tests, and in the experimental artsgui implementation, which you can find under `kdemultimedia/arts/gui`.

Prev | Home | Next
Interfaces and IDL | Up | aRts Application Programming Interfaces