Learning log – Problème de blocage de la fenêtre après la sauvegarde:

    Après avoir implémenté la fonctionnalité d’export au format PIF depuis l’interface du convertisseur, 
    j’ai rencontré un problème important : une fois que je cliquais sur le bouton d’exportation, 
    la fenêtre se figeait complètement. Elle restait visible, mais impossible à fermer ou à interagir avec. 
    Le programme semblait bloqué.

    En analysant le comportement et en utilisant des impressions de debug, j’ai constaté que le blocage n’était pas lié à l’écriture du 
    fichier ni à la logique du convertisseur, mais bien à un problème de gestion des threads dans Swing.

    Swing repose sur un fonctionnement particulier : toute l’interface graphique est gérée par un seul thread dédié, 
    appelé l’Event Dispatch Thread (EDT). Ce thread est responsable de tout ce qui concerne l’interface utilisateur : 
    la gestion des clics, le rafraîchissement de la fenêtre, la fermeture, le dessin et l’affichage en général. 
    Tant que ce thread tourne correctement, l’application reste réactive.

    L’EDT ne démarre réellement qu’après l’appel à la méthode permettant d’afficher la fenêtre. À partir de ce moment, 
    toutes les opérations qui modifient l’interface devraient strictement être exécutées sur ce thread. 
    C’est une règle fondamentale pour éviter les blocages.

    En examinant mon programme, je me suis rendu compte que le problème venait de la manière dont j’avais structuré mon point d’entrée. 
    Mon programme principal créait la fenêtre, le contrôleur, puis lançait immédiatement tout le processus de conversion, 
    qui incluait le chargement du fichier image, le calcul des fréquences, la construction des arbres de Huffman, 
    la génération des codes canoniques, et éventuellement l’écriture du fichier PIF. 
    Ce sont des opérations potentiellement longues et qui se déroulaient sur le thread principal, 
    avant même que l’EDT ne prenne le relais pour gérer l’interface.

    Cela avait deux conséquences. D'abord, la fenêtre pouvait parfois être affichée trop tard ou de manière irrégulière. 
    Ensuite, après l’export, Swing se retrouvait dans un état instable, puisque certaines opérations graphiques avaient été réalisées 
    hors du thread dédié. 
    C’est exactement ce qui provoquait le gel de l’interface : une fois le fichier enregistré, la fenêtre ne répondait plus car
    l’EDT était bloqué ou interrompu, empêchant toute interaction, y compris la fermeture de la fenêtre.

    Une fois le problème identifié, les solutions étaient claires. Il fallait s’assurer que toutes les opérations qui touchent 
    a l’interface graphique soient exécutées sur l’Event Dispatch Thread. Cela signifie que toute interaction, y compris l’ouverture 
    d’un sélecteur de fichiers, doit obligatoirement être déclenchée dans ce contexte. De plus, il fallait veiller à ne pas exécuter 
    de longues opérations synchrones avant le démarrage complet de l’EDT.

    La solution consiste donc à déléguer l’appel du processus de conversion au thread graphique, en utilisant le mécanisme fourni par 
    Swing pour garantir que le code s’exécute sur l’EDT. Une autre possibilité serait d’exécuter les opérations lourdes dans un thread en 
    arrière-plan pour éviter de bloquer l’interface, mais dans tous les cas le respect strict de la séparation entre traitements et interface 
    est essentiel.

    Grâce à cette analyse, j’ai mieux compris la manière dont Swing gère les threads et j’ai pu corriger la structure de mon programme 
    afin qu’il reste totalement réactif, même après l’export. Cette expérience m’a rappelé l’importance de maîtriser les principes fondamentaux 
    des bibliothèques graphiques et leurs contraintes en matière de multithreading.