Structure traditionnelle d'un code wxPerl

Une application en wxPerl se compose au minimum des packages suivants :

Le package main, qui contient l'appel à la boucle de traitement des événements $app->MainLoop ;
Le package Application, qui contient l'appel au constructeur de la Frame principale ;
Le package Frame, qui décrit toute la structure statique de la fenêtre principale de l'application, et contient toutes les méthodes de callback qui décrivent son comportement dynamique ;
Éventuellement, tout autre package de Frame ou de Dialog, décrivant chacun une fenêtre de dialogue supplémentaire.

Penchons-nous sur ces différents packages.

Le package `main`

Le package main est le point d'entrée du programme. Traditionnellement localisé à la fin du fichier .pl dans le cas d'un script mono-fichier, de telle sorte que l'interpréteur Perl ait déjà lu et compilé le reste du code au moment de l'appel à MyApp->new. Il est bien sûr possible de l'isoler dans son propre fichier .pm pour des applications plus conséquentes.

Voyons ce à quoi cela peut ressembler :

    # Exemple de package "main" minimal
    package main;
    my ($app) =
      MonAppli->new();  # création de l'objet application et de tous ses enfants
    $app->MainLoop();   # début d'attente & traitement des événements

    # Exemple de package "main" plus complet
    package main;

    # import d'un module métier
    use ObjetMetier qw( fonction_metier );

    use MLDBM 'DB_File';    # autre exemple, import d'un module Core de Perl
    tie( my %CONFDB, 'MLDBM', 'config.db' )
      or die "Erreur de tie: $!";

    # appel à une fonction métier d'initialisation
    &ObjetMetier::fonction_metier();
    my ($app) =
      MonAppli->new();  # création de l'objet application et de tous ses enfants
    $app->MainLoop();   # début d'attente & traitement des événements
    untie %CONFDB;      # action post-MainLoop de nettoyage avant clôture

Voyons tout ça plus en détails :

Les inclusions (use) des modules externes nécessaires à l'application, fonctionnalités métier développées par vous-même ou modules standard du CPAN ;
Les initialisations diverses qui doivent avoir lieu avant l'ouverture de l'IHM ;
La création d'un objet Application dérivé de la classe Wx::App, qui va entraîner la création en cascade de tout le reste de l'IHM, fenêtre principale, widgets, dialogues, etc. ;
L'appel à la méthode MainLoop() sur cet objet va lancer la boucle d'attente et de traitement des événements. L'occurrence d'un événement provoque l'exécution du callback qui lui est associé. Il va dérouler son code, lancer les éventuels appels aux actions métier de l'application à travers son API, provoquer éventuellement le déclenchement d'autres événements qui vont s'insérer dans une file d'attente. Enfin, il rend la main à la boucle principale qui va reprendre son cycle et vérifier la présence éventuelle d'autres événements à traiter dans la file d'attente.

Et ainsi de suite...

Généralement, on quitte la boucle MainLoop() en détruisant la fenêtre principale via la méthode Destroy(), ce qui détruit en cascade toutes les fenêtres filles et leurs widgets associés ;
Enfin, les appels postérieurs à MainLoop(), à des fonctions métier à exécuter avant clôture de l'application (par exemple pour fermer proprement une connexion à une base de données).

Le package `Application`

Le package Application décrit une classe dérivée de Wx::App, et qui représente l'application au sens wxPerl du terme. Souvent on l'appelle MyApp mais n'importe quel nom peut faire l'affaire.

Voici un exemple de code d'un package Application :

    package MyApp;

    use strict;
    use vars qw(@ISA);
    @ISA = qw(Wx::App);    # déclaration de l'héritage

    sub OnInit {
        my $this = shift;
        Wx::InitAllImageHandlers();    # exemple de fonction d'init globale
        my ($dialog) =
          Mon_Dialogue->new(           # création d'une fenêtre de type "Dialog"
            undef,                     # fenêtre principale de l'application,
                                       # donc pas de parent
            -1,                        # ID attribué dynamiquement
            "Joli dialogue",           # Titre de la fenêtre
            [ 20,  20 ],               # Dimension & position
            [ 500, 340 ]
          );
        $dialog->Show(1);              # affichage de la fenêtre à l'écran
        1;                             # doit retourner "true" pour continuer,
                                       # ou "false" pour quitter l'appli
    }

L'objet instancié à partir de ce package est l'objet parent de tous les autres.

On ne déclare pas de méthode constructeur new pour ce package car la méthode par défaut implémentée dans la classe mère Wx::App est suffisante et ne nécessite pas de surcharge.

Au contraire, le code d'initialisation de l'objet devra être localisé dans la méthode OnInit() qui est appelée automatiquement juste après la création de l'objet Application.

Un certain nombre de directives globales peuvent être appelées à ce niveau pour initialiser certaines choses, ou pour contrôler le comportement de MainLoop(). Par exemple, Wx::InitAllImageHandlers() initialise les gestionnaires internes de formats de fichier images, permettant par la suite d'utiliser des fichiers .jpg ou .png pour ajouter des icônes ou des bitmaps.

C'est dans OnInit() qu'on va créer et afficher la fenêtre principale, qui pourra être de type Frame (dérivation de Wx::Frame) ou de type Dialog (dérivation de Wx::Dialog).

Une Frame est une fenêtre dont la taille et la position peuvent être modifiées par l'utilisateur (habituellement car il est possible de spécifier une taille et une position figées). Une Frame possède (habituellement aussi) des bords épais et une barre de titre, et peut contenir une barre de menus (menubar), une barre d'outils (toolbar) et une barre d'état (statusbar).

Un Dialog est une fenêtre avec une barre de titre, et éventuellement un menu système, mais pas de barre de menus, de barre d'outils ni de barre d'état. Un Dialog peut être déplacé sur l'écran mais pas redimensionné. Il peut contenir toute sorte de widgets de contrôle (boutons, sliders, zone de texte, etc.), et est généralement utilisé pour permettre à l'utilisateur de faire des choix, d'interagir avec l'application. De plus, il offre par défaut une navigation entre les contrôles par appuis successifs sur la touche Tabulation.

Il y a deux sortes de Dialogs, modal ou non-modal (modeless en anglais). Un Dialog de type modal bloque l'exécution du programme principal et interdit les actions sur les autres fenêtres de l'application jusqu'à ce que l'utilisateur valide une action et referme le Dialog. Un Dialog non-modal se comporte plus comme une Frame, autorisant le programme principal à continuer son exécution, et l'utilisateur à agir sur les autres fenêtres. Un Dialog est appelé en mode modal avec la méthode ShowModal(), sinon c'est la méthode Show() qui est utilisée, et qui provoque son affichage en mode non-modal, comme pour une Frame.

Notons enfin l'existence et l'utilité des Panels (dérivation de Wx::Panel), pas indispensables en théorie, mais qui apportent aux Frames les fonctionnalités des Dialog. Ils permettent de les considérer comme des groupes de contrôles, plus faciles à réutiliser ailleurs, dans une autre fenêtre ou même une autre application.

Les packages `Frame`

Les packages Frame ou Dialog décrivent une classe dérivée de Wx::Frame ou de Wx::Dialog respectivement, et représente les fenêtres de l'application. C'est en général, la fenêtre principale qui s'affiche la première, mais pas toujours car on peut commencer par afficher un « splashscreen » pendant quelques secondes par exemple.

La fenêtre principale est l'objet parent des autres fenêtres et widgets, et sa fermeture ou sa destruction provoque la sortie de MainLoop() et la destruction en cascade de tous ses widgets enfants.

Typiquement, son code est scindé en deux parties :

Une partie statique, qui décrit toute la constitution du squelette de l'IHM, c'est à dire la création et le positionnement des widgets les uns par rapport aux autres dans la Frame ;
Une partie dynamique, qui rassemble le code des callbacks, et réalise concrètement le comportement de la Frame en réponse aux sollicitations de l'utilisateur.

Commençons par la partie statique du package, découpé comme suit :

L'import des constantes ;
L'énumération des identifiants de widgets ;
Le constructeur de Frame.

L'import des constantes

On importe une sélection de constantes diverses et variées exportées par le module Wx, qui seront utilisées plus loin, lors de la création des widgets. Par exemple :

    use Wx qw( wxDefaultSize wxDefaultPosition wxID_OK wxID_CANCEL wxID_YES );
    use Wx qw( wxVERTICAL wxHORIZONTAL wxALL wxLEFT
      wxRIGHT wxTOP wxBOTTOM wxCENTRE wxGROW );

Le package Wx exporte des constantes pour tout un tas de choses, et il serait trop long de tout décrire ici. Le fichier Wx_Exp.pm de la distribution de wxPerl en contient la liste exhaustive qui en dénombre plus de 2000, regroupés par thème et chaque groupe identifié par une balise que l'on peut spécifier lors d'un use. Par exemple :

    use Wx qw( :color );

permet d'importer les constantes wxNullColour, wxRED, wxGREEN, wxBLUE, wxBLACK, wxWHITE, wxCYAN, wxLIGHT_GREY.

Vous pouvez aussi décider de tout importer d'un seul coup pour ne pas risquer de subir les désagréments de messages d'erreur lors de la compilation. Gardez cependant à l'esprit que se limiter à un import sélectif des constantes effectivement utilisées permet d'optimiser la consommation en mémoire.

    use Wx qw( :everything );

Énumération des identifiants de widgets

Sous wxWidgets (et donc sous wxPerl par extension), chaque widget se voit attribuer un identifiant numérique unique, qui peut servir à identifier un élément de menu ou à informer un « callback » de l'identité du widget à l'origine d'un événement. Le programmeur peut décider d'attribuer lui-même cet identifiant, auquel cas il devra s'assurer de son unicité, ou bien laisser wxWidgets en attribuer un automatiquement en spécifiant la valeur -1 à la place. wxWidgets utilise déjà certaines valeurs entières qui doivent lui rester réservées. Aussi le programmeur qui souhaite spécifier ses propres valeurs d'identifiants devra prendre garde à les choisir en dehors de cet intervalle réservé, entre wxID_LOWEST et wxID_HIGHEST qui sont actuellement fixées à 4999 et 5999. Par exemple :

    ( $ID_OPEN, $ID_SAVE, $ID_PRINT, $ID_EXIT, $ID_ABOUT, $ID_BOUTON_TEST, ) =
      ( wxID_HIGHEST + 1 .. wxID_HIGHEST + 100 );

De la sorte, quand vous voulez ajouter un nouveau bouton à votre interface, il suffit de lui choisir un petit nom (par exemple ID_MONBOUTON) et d'ajouter un $ID_MONBOUTON en fin de liste.

Le constructeur de `Frame`

Le constructeur de l'objet Frame commence généralement par un appel au constructeur de la classe parente, à qui on fait suivre les éventuels arguments transmis (titre de la fenêtre, taille et position).

On trouve ensuite la génération de tous les widgets qui vont peupler la fenêtre, dans un ordre qui permet d'assurer une hiérarchie cohérente au niveau de l'imbrication des widgets conteneurs (les Sizers que nous verrons en détail dans l'article suivant), et de l'agencement des widgets traditionnels (boutons, cases à cocher, zones de texte, etc.). Lors de la création de chacun des widgets, on passera en argument à new, l'identifiant unique $ID_MONBOUTON qui lui a été précédemment attribué.

La création de la barre de menu et de la barre d'outils (« toolbar ») (que verrons aussi une prochaine fois) y ont également leur place, ainsi que la barre d'état qui ne nécessite qu'une ou deux lignes de code :

    # Création d'un menu
    my $help = Wx::Menu->new;                       # Création d'un menu
    $help->Append( $ID_ABOUT, '&About', 'About' );  # Insertion dans ce menu d'un élément
                                                    #  "About" avec l'ID $ID_ABOUT
    my $menu = Wx::MenuBar->new;                    # Création d'une barre de menu
    $menu->Append( $help, "&Help" );                # Insertion du menu dans la barre
                                                    #   et affectation du libellé "Help"
    $this->SetMenuBar( $menu );                     # Affectation de la barre à la fenêtre

    $this->CreateStatusBar( 2 );             # Crée une barre d'état avec 2 compartiments
    $this->SetStatusText("Hello World", 0);  # Écrit quelques mots dans le 1er compartiment

On peut également spécifier une icône qui apparaîtra dans le coin gauche de la fenêtre, ainsi que dans la barre des tâches quand l'application est réduite. La fonction Wx::GetWxPerlIcon qui retourne l'icône par défaut de wxWidgets, et qu'on peut utiliser comme suit :

    $this->SetIcon( Wx::GetWxPerlIcon() );   # Utilise l'icône de wxPerl

Les membres d'instance véhiculent des informations propres à l'application, qu'il est généralement plus simple de stocker dans l'instance de la Frame principale. Fidèles aux bonnes habitudes de la POO en Perl, nous les mémorisons en tant que clefs du hachage de l'objet Frame. Ainsi :

    # exemple pour une application réseau
    $this->{CONNECT}    = 0;
    $this->{NB_CLIENTS} = 0;

On peut également utiliser cette méthode pour accéder facilement à certains objets enfants de la Frame :

    $this->{STATUSBAR} = $this->GetStatusBar();
    $this->{LABEL} = Wx::StaticText->new( $this, $ID_TEXT, "", wxDefaultPosition, [200,20], 0 );

À noter que la classe Wx::Window qui est une superclasse de tous les Widgets, Frames et autres Dialogs implémente la méthode FindWindow($ID) qui permet de retrouver dans une Frame un widget enfant à partir de son ID. C'est cette méthode qui est employée pour coder les fonctions « d'accesseurs » (mauvaise traduction du terme technique anglais accessor), qui sont de simples fonctions Get_ceci() ou Set_cela() permettant d'accéder simplement aux widgets intéressants.

Voici ci-dessous un exemple mixant les deux façons de faire :

    package MyFrame;
    @ISA = qw(Wx::Frame);
    ($ID_BUTTON_OK) = ( wxID_HIGHEST + 1 .. wxID_HIGHEST + 100 );

    sub new {
        my ($class) = shift;
        my ($this)  = $class->SUPER::new(@_);
        $this->{BUTTONOK} =
          Wx::Button->new( $this, $ID_BUTTON_OK, "OK", wxDefaultPosition,
            wxDefaultSize, 0 );
        $this->AddWindow( $this->{BUTTONOK}, 1, wxALIGN_CENTER | wxALL, 15 );
    }

    # Fonction "accesseur" pour accéder au bouton OK
    sub GetButtonOK { $_[0]->FindWindow($ID_BUTTON_OK); }

    # Fonction quelconque qui utilise l'accesseur et/ou le membre d'instance
    sub FaireChose {
        my $this     = shift;
        my $buttonOK = $this->GetButtonOK;    # référence par l'accesseur
       #my $buttonOK = $this->{BUTTONOK};     # référence par le membre d'instance

        $buttonOK->SetDefault;    # Spécifie que le bouton est le widget par
                                  # défaut de la frame i.e. un appui sur
                                  # Enter équivaut à cliquer sur le bouton
    }

Les outils IDE/RAD optent en général pour l'utilisation des fonctions d'accesseur.

Enfin, on termine le constructeur par la mise en place des liaisons entre les événements intéressants et les callbacks (les gestionnaires d'événements) dont le code apparaît après le constructeur. Les événements qualifiés d'intéressants sont ceux que la Frame devra intercepter, afin de permettre à l'application de leur répondre par des actions appropriées. Les callbacks sont de simples méthodes de l'objet Frame qui attendent comme premier argument, une référence à l'objet Frame (comme toutes les autres méthodes d'ailleurs), et une référence à un objet événement en second argument. Les liaisons entre événement et callback sont déclarées grâce à l'usage de fonctions dédiées du package Wx::Event, spécialisées par type d'événement. Exemple :

    use Wx::Event qw(EVT_BUTTON EVT_RADIOBOX EVT_SPINCTRL EVT_TIMER EVT_CLOSE);
    EVT_BUTTON  (  $this, $main::ID_BT_START,    \&OnBtStart );
    EVT_RADIOBOX(  $this, $main::ID_RD_AUTOPOLL, \&OnRdAutoPoll );
    EVT_SPINCTRL(  $this, $main::ID_SP_SYMB,     \&OnSpSymb );
    EVT_TIMER   (  $this, 1,                     \&OnTimer );
    EVT_CLOSE   (  $this,                        \&OnClose );

Comme on peut le voir, le nombre d'arguments à fournir dépend du type d'événement. Le premier argument est toujours une référence à la Frame qui doit intercepter l'événement. Pour les événements émis par des widgets, le second argument est l'identifiant attribué au widget lors de sa création. Le dernier argument est une référence à la fonction callback. Les événements et les fonctions de liaison événement-callback feront l'objet d'une description plus détaillée dans le prochain article.

Comme tout bon constructeur qui se respecte, sa dernière ligne renvoie une référence à l'objet Frame créé à l'aide d'un simple return $this.

L'implémentation des callbacks

Passons maintenant à la partie dynamique. Une belle IHM c'est bien, mais c'est encore mieux quand elle sert à quelque chose. La partie dynamique rassemble le code qui gère le comportement de l'application. Il s'agit d'une collection de méthodes de l'objet concerné (ici, l'objet Frame). Chacune d'entre elles va répondre spécifiquement à un certain stimulus attendu (événement) parmi la liste de ceux pour lesquels une fonction de liaison événement-callback a bien été déclarée.

En d'autres termes, si le programmeur n'a pas déclaré de fonction telle que :

    Wx::Event::EVT_BUTTON ( $this, $main::ID_MONBOUTON, \&OnMonBouton );

Un clic de souris sur le bouton "MonBouton" déclenchera bien un événement correspondant, celui-ci sera bien intercepté par la Frame, mais c'est le comportement par défaut qui sera appelé, et rien ne se passera.

Le programmeur doit implémenter une fonction et une seule pour chacune des liaisons "événement-callback" déclarée dans le constructeur. En général, selon une convention établie depuis l'origine de la POO, les callbacks ont des noms du genre "OnCeci" ou "OnCela". Ils sous-entendent chez les anglophones qu'ils sont appelés lors de l'occurrence de tel événement "Ceci" ou de tel autre événement "Cela".

Ces fonctions reçoivent au moins deux arguments, dont le premier est une référence à l'objet gestionnaire de l'événement (celui qui l'a intercepté), et le deuxième est une référence à un objet wx::Event qui représente l'événement proprement dit, et qui véhicule un certain nombre d'informations sur le type d'événement, le widget qui l'a émis, etc. Il est parfois nécessaire de récupérer ces informations, comme par exemple, dans le cas d'un événement clavier dont le programmeur souhaite extraire le code ASCII de la touche pressée via la méthode Wx::Event->GetKeyCode.

Quelques exemples de callbacks :

  # Dans le constructeur
  # EVT_CLOSE est déclenché par la fermeture de la fenêtre par le window manager
    EVT_CLOSE( $this, \&OnCloseWindow );

    # callback &OnCloseWindow
    sub OnCloseWindow {
        my ( $this, $event ) = @_;

        # Vous pouvez mettre ici le code de nettoyage de l'appli avant fermeture
        &Ma_fonction_de_nettoyage();

        # Destruction "propre" de la fenêtre. Les widgets enfants sont détruits
        # récursivement et wxWidgets attend que la file d'événements soit vide
        # avant de commencer la destruction, afin d'éviter que des événements
        # ne soient envoyés à des fenêtres inexistantes.
        $this->Destroy;
    }

À noter que l'appel à la méthode Close ne détruit pas la fenêtre, mais génère un événement EVT_CLOSE pour cette fenêtre.

    # Toujours dans le constructeur.
    EVT_MENU( $this, $ID_ABOUT, \&OnAbout );

    # callback &OnAbout
    sub OnAbout {
        my( $this, $event ) = @_;

        # Affiche une petite fenêtre "pop-up" d'information
        Wx::MessageBox(
          "==  Démo  ==\nRelease Version 0.01\n(c)2003 C.Massaloux",  # Texte informatif
          "==  Démo ==",                                              # Titre de la fenêtre
          wxOK|wxICON_INFORMATION       # Affichage d'un bouton OK et d'une icône d'information
          $this );                      # Fenêtre parente
    }

Il est souvent nécessaire lors des traitements de callbacks, d'accéder à un widget enfant de la Frame, qui n'est pas le même que celui qui a généré l'événement déclencheur. C'est à ce moment-là que les fonctions d'accesseur prennent tout leur sens. Exemple : Un bouton "Clear Text" sert à effacer le contenu d'une zone de texte :

    Wx::Button->new( $this, $ID_BT_TEXTCLEAR, "Clear Text" );    # dans le constructeur
    Wx::Event::EVT_BUTTON( $this, $main::ID_BT_TEXTCLEAR, \&OnTextClear );  # dans le constructeur

    sub GetTextCtrl {    $_[0]->FindWindow( $ID_TEXTCTRL );}     # Fonction "accesseur" pour accéder à la zone de texte

    # callback &OnTextClear
    sub OnTextClear {
        my( $this, $event ) = @_;
        $this->GetTextCtrl->Clear;        # Cet accesseur efface le contenu de la zone de texte
    }

Les accesseurs et autres fonctions utilitaires

J'ai déjà expliqué plus haut ce que sont les fonctions d'accesseurs. J'ajouterai simplement qu'il est plus simple de les regrouper toutes au même endroit, soit juste après le constructeur et avant les callbacks, soit en fin de package, après les callbacks.

Enfin, vous ajouterez toutes les autres fonctions/méthodes utiles pour l'application, mais qui ne sont pas stricto sensu des callbacks.

Le cas des fonctions qui gèrent le "copier-coller" est un bon exemple : Voici trois callbacks, qui sont traditionnellement appelés par les éléments Copy/Cut/Paste du menu Edit :

    sub OnCopy {                # callback OnCopy
        my( $this, $event ) = @_;
        my $item = $this->{CUR_ITEM};        # Cible de la copie
        $this->{CLIPBOARD} =  $item;        # Mémorise une référence à l'item copié
    }

    sub OnCut {                # callback OnCut
        my( $this, $event ) = @_;
        my $item = $this->{CUR_ITEM};        # Cible de la suppression
        $this->{CLIPBOARD} =  $item;        # Mémorise une référence à l'item copié
        $this->DelItem($item);            # Suppression de l'item cible via une fonction utilitaire
    }

    sub OnPaste {                # callback OnPaste
        my( $this, $event ) = @_;
        my $item = $this->{CUR_ITEM};        # Cible du collage
        my $new_item = $this->{CLIPBOARD};    # Récupération de l'item à coller
          $this->InsItem($item, $new_item);    # Insertion via une fonction utilitaire
    }

    sub DelItem {                # Fonction utilitaire de suppression d'un item
        my ( $this, $item ) = @_;
        # Faire quelque chose pour supprimer l'item au niveau des couches métier
        #.../...
    }

    sub InsItem {                # Fonction utilitaire d'insertion d'un item
        my ( $this, $item, $new_item ) = @_;
        # Faire quelque chose au niveau des couches métier
        # pour insérer le nouvel item "sur" l'item cible
        # .../...
    }

On voit dans cet exemple que le traitement des événements par les callbacks (OnCut, OnCopy, OnPaste) et le vrai traitement au niveau des couches métier de l'application (DelItem, InsItem) sont séparés. Cela simplifiera d'autant la maintenance du logiciel. Les deux fonctions « utilitaires » DelItem et InsItem n'en sont pas moins de vrais méthodes de l'objet Frame, et sont donc incluses dans le package.

wxPerl: le mariage réussi de Perl et wxWidgets (1)

Chapeau

Introduction

Présentation de wxWidgets (ex-wxWindows)

Avantages de wxWidgets par rapport à ses concurrents

Multi plates-formes

Une boîte à outil complète

Multi-langages

L'installation sous Unix/Linux

Installation RPM

Installation à partir des sources

L'installation sous Windows

La documentation

Hello World !

Structure traditionnelle d'un code wxPerl

Le package `main`

Le package `Application`

Les packages `Frame`

L'import des constantes

Énumération des identifiants de widgets

Le constructeur de `Frame`

L'implémentation des callbacks

Les accesseurs et autres fonctions utilitaires

Dans le prochain article sur wxPerl

Auteur

Quelques liens sur le web

wxPerl: le mariage réussi de Perl et wxWidgets (1)

Chapeau

Introduction

Présentation de wxWidgets (ex-wxWindows)

Avantages de wxWidgets par rapport à ses concurrents

Multi plates-formes

Une boîte à outil complète

Multi-langages

L'installation sous Unix/Linux

Installation RPM

Installation à partir des sources

L'installation sous Windows

La documentation

Hello World !

Structure traditionnelle d'un code wxPerl

Le package main

Le package Application

Les packages Frame

L'import des constantes

Énumération des identifiants de widgets

Le constructeur de Frame

L'implémentation des callbacks

Les accesseurs et autres fonctions utilitaires

Dans le prochain article sur wxPerl

Auteur

Quelques liens sur le web

Le package `main`

Le package `Application`

Les packages `Frame`

Le constructeur de `Frame`