Le manuel de aRts
Précédent | Chapitre 7. MCOP : modèle object et streaming | Suivant

# 7.3. notifications de changement d'attribut

Les notifications de changement d'attribut sont un moyen de savoir lorsqu'un attribut a changé. C'est un peu semblable aux signaux et slots de Qt™'s ou Gtk. Par exemple, si vous avez un élément d'interface graphique, une glissière, qui sélectionne un nombre entre 0 et 100, vous avez certainement un objet qui fait quelque chose avec ce nombre (par exemple, ce peut être contrôler le volume d'un signal audio). Donc vous voudrez que chaque fois que la glissière change de position, l'objet qui gère le volume soit mis au courant. Une connexion entre un émetteur et un récepteur.

MCOP gère cela en fournissant des notifications lorsque des attributs changent. Tout ce qui est déclaré comme "attribut" dans l'IDL peut émettre de telles notifications de changement, et devrait le faire chaque fois qu'il est modifié. Tout ce qui est déclaré comme "attribut" peut aussi reçevoir de telles notifications de changement. Donc par exemple si vous avez deux interfaces IDL, comme celles-ci :

       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  };

Vous pouvez les connecter en utilisant les notifications de changement. Il utilise les opérations habituelles de connexion d'événements" . Dans ce cas, le code C++ pour connecter deux objets ressemblerait à ceci :

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

Comme vous pouvez le voir, chaque attribut offre deux flux, un pour envoyer cette notification de changement, appelé ``attributename`_changed`, et un pour reçevoir les notifications de changement, appelé `attributename`.

Il est important de savoir que ces notifications de changement et flux asynchrones sont compatibles. Ils sont aussi transparents vis-à-vis du réseau. Vous pouvez donc connecter une notification de changement d'un attribut de type flottant d'un widget de l'interface à un flux asynchrone d'un module de synthèse exécuté sur un autre ordinateur. Ceci implique bien sûr que les notifications de changement ne soient pas synchrones, ceci signifie qu'après avoir envoyé une notification de changement, il faut un certain temps avant qu'elle soit réellement reçue.

## 7.3.1. Envoi de notifications de changement

Lorsque vous implantez des objets qui ont des attributs, vous devez envoyer des notifications de changement chaque fois qu'un attribut est modifié. Le code correspondant ressemble à ceci :

       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  }

Il est fortement recommandé d'utiliser ce genre de code pour tous les objets que vous implantez, de façon à ce que les notifications de changement puissent être réutilisées par d'autres personnes. Il est préférable d'éviter d'envoyer des notifications trop fréquemment. Ainsi, si vous faites du traitement du signal, il est surement mieux de mémoriser les dernières notifications envoyées, afin de ne pas en envoyer une avec chaque échantillon traité.

## 7.3.2. Applications pour les notifications de changement

Il est tout particulièrement intéressant d'utiliser les notifications de changement en conjonction avec des oscilloscopes (pour visualiser les données audio par exemple), éléments de l'interface, widgets de contrôle, et monitoring. Le code pour utiliser ceci se trouve dans kdelibs/arts/tests, et dans l'implantation expérimentale de artsgui, que vous pouvez trouver dans `kdemultimedia/arts/gui`.

Précédent | Sommaire | Suivant
Interfaces et IDL | Niveau supérieur | aRts Application Programming Interfaces