Le widget Gtk::DrawingArea de la bibliothèque Gtkmm

Cette classe est un conteneur. Son objectif est de grouper les éléments qui lui sont associés pour les disposer dans les meilleures conditions possibles. Dans le schéma ci-dessus, le Gtk::Box total regroupe tous les objets de l’application, dont le Gtk::Box « zone bouton », contenant lui-même le Gtk::Box « bouton centre ».

Pour utiliser cette classe, nous créerons une classe enfant AireDeDessin qui sera son héritière. Cette classe supportera la gestion des signaux de la souris lorsque celle-ci circulera dans sa surface :

• GestureClick pour gérer l’action sur les boutons ;
• EventControllerMotion pour gérer le déplacement de la souris durant l’appui sur un bouton.

Elle sera aussi chargée, par l’entremise de la bibliothèque Cairomm, d’afficher les graphiques que nous invoquerons.

À noter : les graphes attachés à un objet de la classe DrawingArea n’ont pas de limites positionnelles, excepté la limite du type numérique de stockage. Ces dessins ne seront visibles que dans la surface accordée par l’interface à l’objet de DrawingArea.

Nous utiliserons la bibliothèque 2D Cairomm pour représenter les objets dans la zone graphique. Elle est issue de la bibliothèque Cairo pour être utilisée dans l’environnement objet C++. Nous la solliciterons via Gtk::DrawingArea pour définir le contexte d’affichage des graphiques.

La classe Gtk::make_managed a été créée pour gérer la mémoire de façon « propre » lors de la sortie d’une application utilisant Gtk.

Gtk::Button *ptrbouton = Gtk::make_managed<Gtk::Button>(GUILLEMET-KITOOODVPboutonGUILLEMET-KITOOODVP);

Le pointeur initialisé avec cette méthode sera effacé sans que le programmeur n’ait à utiliser delete pour libérer son occupation mémoire ni new pour sa création. Cette méthode, à l’intérieur d’une fonction, ne permet pas d’utiliser ptrbouton hors de celle-ci. Il est alors plus judicieux de créer dans le fichier d’entête l’instance du bouton Gtk::Button *ptrbouton; et de préférence en private. Puis dans le constructeur du fichier source qui en dépend, nous initialisons le pointeur à nullptr. ptrbouton = nullptr;. Dans la description de l’interface, l’instanciation sera alors ptrbouton = Gtk::make_managed<Gtk::Button>(GUILLEMET-KITOOODVPboutonGUILLEMET-KITOOODVP);accessible dans toutes les méthodes de la classe, et bénéficiant de la libération sécurisée due à make_managed.

Comme cette application n’est utilisée que comme support pour un apprentissage, la fenêtre de l’application sera réduite au plus simple et nous éviterons les menus déroulants standards. Le visuel montre :

• sur le dessus, une zone de boutons pour les commandes générales ;
• en dessous, une zone destinée à recevoir les dessins graphiques.

La classe Fenetre contient les objets :

• Gtk::DrawingArea, zone graphique où se dessineront les objets graphiques ;

• des boutons :

  • les boutons GUILLEMET-KITOOODVPcarréGUILLEMET-KITOOODVP, GUILLEMET-KITOOODVPrectangleGUILLEMET-KITOOODVP et GUILLEMET-KITOOODVProndGUILLEMET-KITOOODVP, destinés à créer les objets graphiques,
  • le bouton GUILLEMET-KITOOODVPgrouperGUILLEMET-KITOOODVP qui rassemble tous les objets au centre de la zone graphique,
  • le bouton GUILLEMET-KITOOODVPsupprimerGUILLEMET-KITOOODVP pour effacer un des éléments de la zone.

Dans la philosophie de la bibliothèque graphique Gtk, la structure de la composition de la fenêtre contenant les graphiques de commandes est étudiée pour répondre à la diversité des langues. Elle est basée sur l’assemblage de conteneurs dont les dimensions et positions seront définies, entre autres choses, suivant la langue utilisée.

III-A-1-a. Remarques sur le fichier fenetre.h de la classe Fenetre▲

protected:
             Glib::RefPtr<Gtk::CssProvider> styledecor;

private: 
       AireDeDessin *zonegraphique;

Dans le constructeur, l’instruction set_default_size(x,y); donne les dimensions minimales de la fenêtre. Ce paramétrage n’est pas obligatoire puisque les dimensions finales dépendent du calcul par Gtk de la dimension de la fenêtre suivant les éléments la constituant. Par contre, il sera nécessaire d’initialiser les dimensions de la zone graphique par des valeurs minimales de façon à obtenir, au démarrage, un espace reconnu.

La plus grande partie du constructeur contient la définition des boutons et de la zone graphique de la fenêtre de l’application. Ces créations sont déjà expliquées dans des articles bien documentés.

Le plus important pour nous est d’étudier la façon de contrôler cette zone avec la souris pour :

• « cliquer/maintenir » un objet et le déplacer ;
• « sélectionner » un objet puis le supprimer.

Pour ce faire, nous utiliserons la classe GestureClick afin de créer une première instance destinée au déplacement de l’objet.

L’instruction auto controle = Gtk::GestureClick::create(); crée une instance de contrôle que nous déterminons à « capturer » un objet controle->set_propagation_phase(Gtk::PropagationPhase::CAPTURE); et nous lui affectons la touche gauche de la souris controle->set_button(1); pour activer deux actions qui nous connecteront chacune à une méthode :

La première action consiste à signaler que la touche est appuyée en continu :

controle->signal_pressed().connect(sigc::mem_fun(*this, &Fenetre::AppuyerSouris));

et la seconde consiste à prévenir si la touche est relâchée :

controle->signal_released().connect(sigc::mem_fun(*this, &Fenetre::LacherSouris),true);

La première instance est réalisée, passons à la deuxième, qui nous permettra de sélectionner un objet :

auto controledroit = Gtk::GestureClick::create();
controledroit->set_propagation_phase(Gtk::PropagationPhase::CAPTURE);
controledroit->set_button(3);
controledroit->signal_pressed().connect(
                   sigc::mem_fun(*this, &Fenetre::ChoisirObjet));

Cette salve d’instructions est identique à la première instance sauf le numéro du bouton pour définir le clic droit et que la connexion vers signal_released() est inutile.

Grâce à l’instance controle, nous pouvons sélectionner l’objet, puis le fixer en place au relâchement du bouton. Dans les faits, nous ne pourrions pas suivre le déplacement de l’objet, il resterait à sa position initiale jusqu’à ce que nous relâchions le bouton, en ce cas il se dessinerait à cette nouvelle position. Pour visualiser ce déplacement, il nous faut créer un contrôle du mouvement de la souris, ce qui est possible avec la classe EventControllerMotion, dont l’instanciation du contrôle et l’instruction pour la capture du signal sont simples :

auto controlebouge = Gtk::EventControllerMotion::create();
controlebouge->signal_motion().connect(sigc::mem_fun(*this, &Fenetre::SourisBouge));

Dans la conception Gtkmm, il nous faut maintenant relier ces trois contrôles à l’objet auquel ils sont destinés :

zonegraphique->add_controller(controle);
zonegraphique->add_controller(controledroit);
zonegraphique->add_controller(controlebouge);

À la fin du constructeur, nous pouvons placer les lignes pour connecter le fichier css aux objets :

styledecor = Gtk::CssProvider::create();
Gtk::StyleContext::add_provider_for_display(
     get_display(),
     styledecor,
     GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
m_styledecor->load_from_path(GUILLEMET-KITOOODVPobjetactif01.cssGUILLEMET-KITOOODVP);

À noter : le fichier CSS est de plus en plus utilisé pour les propriétés de formes et couleurs, de même que la définition des zones de l’interface peuvent être générée par l’intermédiaire de leur description dans un fichier type XML.

Cette classe fournit les instructions nécessaires pour dessiner en 2D dans la zone de dessin. Dans le constructeur de la classe AireDeDessin, un premier appel pour initialiser la zone de graphique définit ce contexte :

AireDeDessin::AireDeDessin()
...
    set_draw_func(sigc::mem_fun(*this, &AireDeDessin::Dessiner));
...

L’utilisation de set_draw_func implique de prévoir pour la déclaration de la fonction AireDeDessin::Dessiner, des paramètres comme indiqué ci-dessous :

void AireDeDessin::Dessiner(const Cairo::RefPtr<Cairo::Context>& cr,int width, int height)

Ctte fonction retourne le contexte par le paramètre cr et les limites de la zone actuelle de dessin. Ces limites dépendent des actions exercées par l’utilisateur sur la fenêtre de l’application, dans notre cas : agrandir ou rétrécir la fenêtre.

La récupération du pointeur cr, nous autorise à créer le dessin dans la zone :

• nous créons un rectangle suivant les valeurs cr->rectangle(xg,yh,xd-xg,yb-yh); ;
• et nous remplissons ce rectangle avec une couleur cr->fill();.

À noter : consulter la documentation pour découvrir toutes les autres instructions qui permettent la création des dessins.

Dans le but d’afficher des objets graphiques indépendants dans une zone et de pouvoir en sélectionner un pour le traiter, il faut que chacun de ces objets ait ses propres instructions de représentation et que la classe chargée de redessiner les graphiques, ici, AireDeDessin héritière de Gtk::DrawingArea, collecte ces données pour les afficher dans sa zone. N’oublions pas que, suivant le principe de Gtk::DrawingArea après avoir affiché les objets une première fois, à chaque modification de son contenu ou de ses propres propriétés, elle redessine toute sa zone.

Pour mettre en place cette solution, nous créons des classes d’éléments graphiques qui seront héritières d’une classe de base appelée ElementGraphique contenant des valeurs de base communes à chaque objet.

III-C-2-a. Classe ElementGraphique▲

protected:
...
    double xg,xd,yh,yb;
    double xctr,yctr;
...

void ElementGraphique::ReDessiner( const Cairo::RefPtr<Cairo::Context>& cr)
{
   tmpcr = cr;
   Dessiner();
}

bool ElementGraphique::ContientPoint( const double x, const double y )
{
   return (
           ((x>xg)&&(x<xd))
            &&
           ((y>yh)&&(y<yb))
          );
}

III-C-2-b. Classe Rectangle▲

Rectangle::Rectangle( const double xc, const double yc,
                      const double largeur, const double hauteur)
{
   xctr = xc;
   yctr = yc;
   xg = xc-largeur/2.0;
   xd = xc+largeur/2.0;
   yh = yc-hauteur/2.0;
   yb = yc+hauteur/2.0;
}

void Rectangle::Dessiner()
{
   tmpcr->rectangle(xg,yh,xd-xg,yb-yh);
   tmpcr->fill();
}

III-C-2-c. Classe Carre▲

Carre::Carre( const double xc, const double yc,const double valcote)
{
   xctr = xc;
   yctr = yc;
   double demicote = valcote/2.0;
   xg = xc-demicote;
   xd = xc+demicote;
   yh = yc-demicote;
   yb = yc+demicote;
}

III-C-2-d. Classe Rond▲

Rond::Rond( const double xc, const double yc, const double rayon )
{
    xctr = xc;
    yctr = yc;
    rx = rayon;
    xg = xctr - rx;
    xd = xctr + rx;
    yh = yctr - rx;
    yb = yctr + rx;
}

tmpcr→arc( xctr, yctr, rx, 0.0, 2.0*M_PI );
tmpcr->fill();

if(ElementGraphique::ContientPoint( x, y ))
{
   double vx = abs(xctr-x);
   double vy = abs(yctr-y);
//if(vx==0) return (vy<rx);
//if(vy==0) return (vx<rx);
   return (hypot (vx, vy)<rx);
}

Dans le constructeur de cette classe, nous définirons les dimensions de la surface graphique. Ce n’est pas une obligation, mais à l’affichage de l’interface nous ne pourrions pas augurer de la taille de cette zone. Comme de coutume en conception objet, nous initialisons les variables déclarées dans le fichier d’entête à des valeurs de base ou nulles. Et, pour finir, l’instruction set_draw_func détermine la fonction qui sera utilisée par DrawingArea pour dessiner dans sa zone.

AireDeDessin :: AireDeDessin ()
{
   set_content_width( 600 );
   set_content_height( 450 );
   stx = sty = 0.0;
   graphestocke = grapheselectionne = nullptr;
   set_draw_func( sigc::mem_fun(*this, &AireDeDessin::Dessiner ) );
}

Lorsque l’application est arrêtée, tous les destructeurs de chaque classe sont appelés afin de nettoyer la mémoire. Puisque nous avons stocké les objets en dynamique dans cette mémoire, nous devons les supprimer :

AireDeDessin ::~ AireDeDessin ()
{
   for ( unsigned i=0; i<lstgraphe.size(); i++)
      delete lstgraphe[i];
}

Un clic sur le bouton libellé carré déclenche la connexion bcarre->signal_clicked().connect qui nous envoie à la méthode &AireDeDessin::SymboleCarre, pour initialiser un objet graphique de forme carrée :

Carre *graphtmp = new Carre(30,30,40); crée une occurrence d’objet dynamique de cette classe.

lstgraphe.push_back(graphtmp); stocke le pointeur dans la table.

queue_draw(); cette dernière instruction commande l’actualisation de la surface graphique. Cette fonction de Gtk::DrawingArea appelle, entre autres méthodes, la fonction Dessiner intégrée à la classe par le set_draw_func dans le constructeur de AireDeDessin.

Au préalable, nous devons sélectionner l’élément graphique à supprimer en cliquant dessus avec la touche droite de la souris, nous avons vu plus haut comment, dans la définition de l’interface, configurer l’action sur la touche droite de la souris pour activer la méthode ChoisirObjet. Elle récupère la position du marqueur de la souris dans la surface graphique et les envoie à la fonction chargée de détecter un objet :

void Fenetre::ChoisirObjet( int n_press, double x, double y )
{
   zonegraphique->SelectionnerObjet(x,y) ;
}

les paramètres « int n_press, double x, double y » sont imposés par la fonction signal_pressed().connect.. La détection d’un objet sous le marqueur s’opère en appelant, pour chaque occurrence d’objet, leur fonction ContientPoint et retourne le premier objet trouvé, sinon nullptr :

ElementGraphique *AireDeDessin::ChercherAuPoint(const double vx, const double vy)
{
    for( unsigned i=0; i<lstgraphe.size(); i++)
    {
        if(lstgraphe[i]->ContientPoint(vx,vy)) return lstgraphe[i];
    }
    return nullptr;
}

Cette valeur sera affectée au membre grapheselectionne, jusqu’à ce que l’appui sur le bouton libellé supprimer déclenche la méthode :

void AireDeDessin::SupprimerSelection()
{
    ctmp = std::find (lstgraphe.begin(), lstgraphe.end(), grapheselectionne);
    if(ctmp != lstgraphe.end())
    {
        lstgraphe.erase(ctmp);     // retirer l’occurrence de la table
        delete grapheselectionne;  // libérer la mémoire
        NettoyerSelection();       // remise à zéro des membres
        queue_draw();              // redessiner la zone graphique
    }
}

Attention : l’itérateur ctmp est déclaré en tant que std::vector<ElementGraphique*>::iterator ctmp; dans le fichier entête et l’instruction std::find impose la déclaration #include <algorithm> dans le fichier entête ou le fichier source.

En cliquant/maintenant la touche gauche de la souris sur un objet de la zone graphique, nous provoquons la mise en œuvre de AppuyerSouris. Cette méthode, si elle trouve un objet sous le marqueur, initialise le membre graphestocke de AireDeDessin avec le pointeur de l’occurrence dynamique de l’objet, ainsi que la position du marqueur. Ensuite, tant que la touche est maintenue, le moindre mouvement de la souris est capté par le contrôle Controlebouge = Gtk::EventControllerMotion défini lors de la création de l’interface, et grâce au signal signal_motion() active la méthode :

void Fenetre::SourisBouge( double x, double y )
{
    if(zonegraphique->ElementStocke())
    {
        zonegraphique->ActualiserPositionElement(x,y);
    }
}

Dans laquelle, après la vérification de l’existence d’un objet à mouvoir, nous actualisons sa position :

void AireDeDessin::ActualiserPositionElement(const double nx, const double ny)
{
    graphestocke->BougerElement((nx-stx),(ny-sty));
    stx=nx;
    sty=ny;
    queue_draw();
}

en mettant à jour les valeurs de placement de l’objet et en le redessinant dans la zone graphique :

void ElementGraphique::BougerElement( const double dx, const double dy )
{
    xctr += dx;
    yctr += dy;
    xg += dx;
    xd += dx;
    yh += dy;
    yb += dy;
    Dessiner();
}

Comme à chaque modification de ou dans la zone graphique, l’appel à la fonction queue_draw(); rafraîchit la vue.

Tant que la touche gauche est appuyée et la souris déplacée, cette série de méthodes est appliquée, mais dès que nous relâchons la pression l’interface déclenche le signal_released() pour appeler la méthode de libération de l’acquisition de l’objet :

void Fenetre::LacherSouris(int n_press, double x, double y)
{
    if(zonegraphique->ElementStocke())
        zonegraphique->NettoyerSelection();
}

où l’instruction NettoyerSelection mettra simplement à nullptr le pointeur mémorisé, le dessin ayant été déjà actualisé par le dernier mouvement de la souris.

Comme nous l’avons constaté, lors du déplacement d’un objet, si nous ne limitons pas les valeurs de positionnement aux dimensions de la zone visible, nous pouvons nous retrouver avec des objets, « quelque part » dans la zone écran du moniteur sans pouvoir les retrouver. Et comme nous sommes dans une application test, cette situation pourrait exister.

Nous allons donc programmer une commande pour rassembler le troupeau. Son principe sera de replacer tous les éléments au centre de la zone graphique affichée.

void AireDeDessin::Grouper()
{
    if(lstgraphe.size()>0)
    {
        int tpxc    = get_content_width()/2;
        int tpyc    = get_content_height()/2;
        for (unsigned i=0; i<lstgraphe.size(); i++)
        {
            lstgraphe[i]->PlacerElement(tpxc,tpyc);
        }
        queue_draw();
    }
}

Nous avons terminé cette première étude sur le widget DrawingArea en intégrant des connexions avec le périphérique souris. Dans le chapitre suivant, nous insérerons textes et images et nous ferons un écart vers CMake et l’emploi des ressources.

Pour utiliser Cmake, plusieurs cours ont été réalisés sur ce site. Nous ne nous intéresserons donc qu’à la compilation des ressources et l’intégration des fichiers.

Dans le script ci-dessous, la commande find_program recherche l’existence du programme de création du fichier de ressources à inclure, en suivant les indications du fichier XML. En cas d’absence cmake s’interrompt en diffusant un message d’erreur.

Avec l’instruction add_custom_command nous désignons le nom des deux fichiers à créer puis la série des arguments, il y a deux lignes puisque la commande activera glib-compile-resources deux fois. Le paramètre WORKING_DIRECTORY désigne l’endroit où se trouvent tous les fichiers à traiter.

À noter : le fichier résultat « resobjetactif.cpp » DOIT se trouver dans le dossier où sera placé l’exécutable résultant de la compilation.

Pour terminer la compilation, il suffit d’indiquer à la commande add_executable les deux fichiers à intégrer.

Puisqu’à la première analyse, avant de procéder au traitement, CMake remarquerait qu’il n’y a pas les fichiers de ressources .h et .cpp créés, il interromprait son job. Nous éviterons cet inconvénient en indiquant après le add_executable la commande set_source_files_propertie de façon à mettre à true la propriété GENERATED de façon à empêcher l’interruption de la première compilation.

cmake_minimum_required(VERSION 3.5)
#…
#….
find_program(GLIB_COMPILE_RESOURCES NAMES glib-compile-resources REQUIRED)

set(FICRES_CPP resobjetactif.cpp)
set(FICRES_H resobjetactif.h)
set(FICRES_XML resobjetactif.xml)

add_custom_command(
    OUTPUT ${FICRES_CPP} ${FICRES_H}
    COMMAND ${GLIB_COMPILE_RESOURCES}
    ARGS
        --target=${CMAKE_CURRENT_BINARY_DIR}/${FICRES_CPP}
        --generate-source ${FICRES_XML}
    COMMAND ${GLIB_COMPILE_RESOURCES}
    ARGS
        --target=${CMAKE_CURRENT_SOURCE_DIR}/entete/${FICRES_H}
        --generate-header ${FICRES_XML}
    WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/ressource
    VERBATIM
    MAIN_DEPENDENCY ressource/${FICRES_XML}
    DEPENDS ressource/objetactif02.css
)
#…
#…
add_executable( objetactif02 ${SOURCE} ${ENTETE} 
                ${CMAKE_CURRENT_BINARY_DIR}/${FICRES_CPP}
                ${CMAKE_CURRENT_SOURCE_DIR}/entete/${FICRES_H} )
#…
#…
set_source_files_properties(
    ${CMAKE_CURRENT_SOURCE_DIR}/entete/${FICRES_H}
    ${CMAKE_CURRENT_BINARY_DIR}/${FICRES_CPP}
    PROPERTIES GENERATED TRUE
)

À noter : le fichier « FICRES_H resobjetactif.h » est inutile pour notre application. Je l’ai placé dans ce CMakeLists comme exemple pour utilisation de la fonction add_custom_command contenant plus d’une commande.

Dans cet exemple, nous devons tenir compte que, contrairement aux autres fichiers entête et source qui ne sont traités que s’ils ont été modifiés, les fichiers ressources cpp et h seraient à chaque fois recréés. Mais, en plaçant la directive MAIN_DEPENDENCY ressource/${FICRES_XML}, nous prescrivons que la commande ne soit exécutée que si ce fichier est modifié, ainsi que DEPENDS ressource/objetactif02.css qui provoquerait aussi cette exécution en cas de modification. Le fait d’utiliser ces directives évite une recompilation systématique de tous les fichiers ressources. L’avantage de DEPENDS est éloquent lors de la mise au point de la décoration de l’interface, puisque les fichiers de construction cpp et h seront ignorés alors que ceux de la ressource modifiée seront compilés et liés au programme ne demandant qu’un temps reconstruction du logiciel insignifiant.

Pour utiliser cette technique, il est préférable de se placer dans le dossier de resobjetactif.xml :

glib-compile-resources --target=objetactifres.cpp --generate-source objetactifres.xml

produit le fichier cpp à placer dans le répertoire de compilation de l’exécutable.

glib-compile-resources --target=objetactifres.h --generate-header objetactifres.xml

produit le fichier h à placer dans le répertoire des entêtes de compilation de l’exécutable, mais n’oublions pas qu’il nous est inutile, et seule la ligne :

add_executable( objetactif02 ${SOURCE} ${ENTETE} 
                ${CMAKE_CURRENT_BINARY_DIR}/resobjetactif.cpp
                ${CMAKE_CURRENT_SOURCE_DIR}/entete/resobjetactif.h )

sera nécessaire puisque les fichiers seront présents.

Dans le fichier CmakeLists les trois directives set(FICRES… ainsi que add_custom_command et set_source_files_properties deviennent inutiles.

Maintenant que le traitement des ressources de cette étape est éclairci, nous étudierons sa mise en œuvre dans les prochaines sections.

Dans l’entête, nous créons la table où seront stockées les données extraites des ressources et deux méthodes, ce sont les seules modifications significatives en comparaison de objetactif01.

private:
….
    std::vector<donneesymbole> lstdonnee;
….    
    void FormateCouleur( tabcoul &tabcouleur,
                           const std::string &phrasecouleur );
    void ChargerDonneeSymbole();

Dans le source, le constructeur ne subit qu’un ajout, une instruction appelant la fonction ChargerDonneeSymbole() afin d’extraire les valeurs des ressources pour initialiser la table lstdonnee. Pour lire les fichiers texte ou binaire la technique est identique :

• créer un flux d’entrée :

Glib::RefPtr<Gio::InputStream> fichierdonnees =
                  Gio::Resource::open_stream_global(GUILLEMET-KITOOODVP/fichier/donnees.txtGUILLEMET-KITOOODVP);

• créer un buffer pour stocker les données lues :

Glib::RefPtr<Gio::DataInputStream> lignedonnee =
                  Gio::DataInputStream::create(fichierdonnees);

Ensuite, il suffit de boucler une lecture de ce flux.

Commençons par lire le fichier texte à l’aide de l’instruction read_line , si la lecture est réussie la fonction renvoie true :

….    
  donneesymbole dontmp;
  bool oklecture;
  do{
    oklecture = false;
    if(lignedonnee→read_line(dontmp.txtcartouche))
….
           if(lignedonnee->read_line(phrcouleur))
           {
              FormateCouleur( dontmp.couleurcartouche, phrcouleur );
              lstdonnee.push_back(dontmp);
              oklecture = true;
           }
….
  }while(oklecture);

Après cette phase la table et partiellement remplie, et pour la finir nous devons lire le fichier binaire :

Glib::RefPtr<Gio::InputStream> fichbindonnees =
                   Gio::Resource::open_stream_global(GUILLEMET-KITOOODVP/fichbin/donnees.binGUILLEMET-KITOOODVP);
Glib::RefPtr<Gio::DataInputStream> enrgdonnee =
                   Gio::DataInputStream::create(fichbindonnees);

   dimsymbole dimdon;
   gsize      nboctet = sizeof(dimsymbole);
   int i=0;
   do{
      oklecture = false;
      if(enrgdonnee->read( &dimdon,nboctet) == nboctet)
      {
         lstdonnee[i].dimension = dimdon;
         i++;
         oklecture = true;
      }
   }while(oklecture);

Mais cette fois, nous utilisons la fonction read qui nécessite de connaître le nombre d’octets à lire, et nous initialisons le reste de la structure avec dimdon.

À noter : bien sûr, il aurait été plus judicieux de réaliser la lecture des deux fichiers dans une même boucle.

La méthode Rectangle::Dessiner est bouleversée, ses enfants Logiciel et FichierJoint n’ont pas besoin de leur propre méthode Dessiner puisque le principe de traçage est identique pour les deux héritières.

Nous dessinerons le rectangle principal avec la couleur de fond :

Couleurs ( pdonnee→couleurfond[0],  pdonnee→couleurfond[1],  pdonnee->couleurfond[2]);    
tmpcr→rectangle(xg,yh,xd-xg,yb-yh);
tmpcr->fill();

Nous utilisons une fonction « Couleurs » pour simplifier la programmation parce que la fonction set_source_rgb demande comme paramètre une valeur décimale qui représente un coefficient résultant de la valeur entre 0 et 255 écrite dans le fichier divisée par 255 :

tmpcr->set_source_rgb( (valR/255.0), (valV/255.0), (valB/255.0) );

À noter : nous pouvons aussi calculer ces valeurs lors de la lecture du fichier.

Ensuite, nous dessinons le cartouche, qui est la partie supérieure du graphisme :

Couleurs( pdonnee->couleurcartouche[0], pdonnee->couleurcartouche[1],
                    pdonnee->couleurcartouche[2] );    
tmpcr->rectangle( xg, yh, xd-xg, htcartouche );
tmpcr->fill();

Maintenant, traçons le cadre où nous utilisons d’autres fonctions de traçage de Cairo. Nous définissons un chemin pour réaliser le pourtour de l’objet, puis nous donnons l’ordre de tracer le trait en suivant le chemin :

Couleurs(0, 0, 0);       // ou tmpcr->set_source_rgb( 0,0,0 );    
   tmpcr→set_line_width(3.0); // épaisseur du trait
   tmpcr→move_to(xg,yh);      // placer le crayon
      tmpcr→line_to(xd,yh);      //
      tmpcr→line_to(xd,yb);      // tracer trois lignes
      tmpcr→line_to(xg,yb);      //
  tmpcr→close_path();            // fermer le rectangle
  tmpcr→stroke();                   // créer le trait

La bibliothèque Pangomm permet de disposer le texte dans la zone graphique. Par les instructions ci-dessous nous formatons la description du texte :

Couleurs( pdonnee->couleurpolice[0], pdonnee->couleurpolice[1],
          pdonnee->couleurpolice[2] );    
Pango::FontDescription lettrage;
  lettrage.set_family( pdonnee->policecar );
lettrage.set_weight( Pango::Weight::NORMAL );
lettrage.set_size( Pango::SCALE * Pango::SCALE_X_LARGE * pdonnee->taillepol );

Attention au calcul de l’échelle, la taille de police donnée dans le fichier doit être adaptée au périphérique moniteur. Nous devons donc utiliser Pango::SCALE qui est une constante de 1024px qui sera multipliée par un coefficient Pango::SCALE_X_LARGE. Les valeurs de ces coefficients vont de SCALE_XX_SMALL = 0.578 etc... à SCALE_XX_LARGE = 1.728et nous pouvons les trouver ici.

Lorsque la description des caractères est fixée, nous pouvons définir le contenant dans lequel le texte sera écrit et nous lui assignons la description et le texte :

Glib::RefPtr< Pango::Layout > cadrecorp = Pango::Layout::create( tmpcr );
cadrecorp->set_font_description( lettrage ) ;
cadrecorp->set_text( pdonnee→txtcorps ) ;

Et pour terminer, nous positionnons ce contenant dans le cadre du corps de l’objet :

int lgtxt, httxt;
cadrecorp->get_pixel_size( lgtxt, httxt );
tmpcr->move_to( xctr + ( lgimg*0.375 ) - lgtxt/2, yctr + htcartouche/2 – httxt/2 );

et nous l’intégrons au contexte : cadrecorp->show_in_cairo_context(tmpcr);.

Nous procéderons de la même façon pour le texte du cartouche.

Préparons maintenant l’objet image en récupérant le fichier png stocké dans les ressources, ici la variable imagecorps est égale à « /icone/edit48.png » , pour initialiser un gdk::pixbuf :

Glib::RefPtr<Gdk::Pixbuf> image = Gdk::Pixbuf::create_from_resource(
                                                                                             pdonnee->imagecorps );
int lgimg = image->get_width();
int htimg = image->get_height();

Pour terminer la préparation du dessin, attachons l’image en la positionnant dans le cadre:

Gdk::Cairo::set_source_pixbuf( tmpcr, image,
                   xg – image->get_width()*0.25,
                   yh + htcartouche + image->get_height()*0.25 );

et nous terminerons par l’instruction tmpcr->paint(); qui incorpore dans la zone graphique toutes les occurrences de dessins définies ci-dessus.

Après compilation, nous pouvons tester cette application.

Cette dernière section clôt l’étude sur les bibliothèques Gtkmm Cairomm et Pangomm, avec un petit écart vers CMake et sur l’usage des ressources.