fy59/labfy-investigation

Fork 0

Notifier l’application lorsque l’initialisation des outils est terminée #44

New issue

Closed

opened 2026-07-18 12:17:23 +02:00 by fy59 · 0 comments

fy59 commented

2026-07-18 12:17:23 +02:00

Owner

Notifier l’application lorsque l’initialisation des outils est terminée

Contexte

ToolInitializer détecte maintenant les outils externes en arrière-plan au démarrage de l’application.

Le composant sait déjà :

enregistrer les outils du catalogue ;
détecter leur présence ;
récupérer leur version ;
produire un résumé ;
gérer l’annulation ;
autoriser un nouveau lancement après une fin ou une annulation.

Cependant, Application n’est pas encore informée directement de la fin de l’initialisation. Elle ne peut donc pas réagir proprement pour mettre à jour l’interface ou afficher un bilan.

Objectif

Ajouter un mécanisme de notification permettant à Application d’être appelée lorsque ToolInitializer termine son travail.

La notification devra transmettre :

l’état final de la tâche ;
le résumé d’initialisation lorsqu’il est valide ;
l’erreur lorsque l’initialisation échoue ;
une référence sûre vers le registre des outils déjà mis à jour.

Périmètre

À faire

Ajouter une API publique permettant d’enregistrer un callback de fin.
Exécuter le callback dans le contexte principal GLib.
Garantir que le callback n’est appelé qu’une fois par lancement.
Transmettre un résumé uniquement lorsque la tâche est terminée avec succès.
Permettre de distinguer :
- réussite ;
- annulation ;
- échec.
Garantir que les données restent valides pendant l’exécution du callback.
Ajouter les tests unitaires correspondants.
Intégrer les nouveaux tests au Makefile.

Hors périmètre

Création d’une nouvelle vue GTK.
Affichage graphique de la liste des outils.
Installation automatique des outils manquants.
Lancement d’un outil OSINT.
Modification du catalogue d’outils.

Contraintes techniques

C17 uniquement.
Aucun accès GTK depuis le worker.
Le callback doit être exécuté sur le thread principal.
ToolInitializer reste propriétaire de son ToolRegistry.
Application ne doit recevoir qu’un accès emprunté au registre.
Le callback ne doit pas prolonger artificiellement la durée de vie de Application.
La destruction pendant une initialisation doit rester sûre.
Une annulation ne doit pas produire de résumé valide.
Un nouveau lancement doit pouvoir réutiliser le même callback.

API attendue

L’API exacte pourra être ajustée pendant l’implémentation, mais elle devra couvrir les besoins suivants :

typedef void (*ToolInitializerCompletedCallback)(
    ToolInitializer *tool_initializer,
    BackgroundTaskState final_state,
    const ToolInitializationSummary *summary,
    const GError *error,
    gpointer user_data
);

Une fonction publique devra permettre d’enregistrer le callback et ses données :

void tool_initializer_set_completed_callback(
    ToolInitializer *tool_initializer,
    ToolInitializerCompletedCallback callback,
    gpointer user_data,
    GDestroyNotify destroy_notify
);

Comportement attendu

Réussite

Le registre contient les informations mises à jour.
Le résumé est non nul.
L’état final vaut BACKGROUND_TASK_STATE_COMPLETED.
L’erreur est nulle.

Annulation

Le résumé est nul.
L’état final vaut BACKGROUND_TASK_STATE_CANCELLED.
Le callback est appelé une seule fois.

Échec

Le résumé est nul.
L’état final vaut BACKGROUND_TASK_STATE_FAILED.
Une erreur lisible est transmise lorsque disponible.

Tests attendus

Ajouter au minimum les cas suivants :

enregistrement d’un callback valide ;
remplacement d’un callback existant ;
appel après une réussite ;
résumé transmis après une réussite ;
registre déjà mis à jour au moment du callback ;
appel après une annulation ;
absence de résumé après une annulation ;
appel après un échec ;
callback exécuté sur le contexte principal ;
callback appelé une seule fois ;
nouveau lancement utilisant le même callback ;
destruction correcte des données utilisateur via GDestroyNotify.

Critères d’acceptation

Tous les tests existants restent valides.
Les nouveaux tests passent avec -Werror.
Valgrind ne détecte aucune perte directe ou indirecte dans le test ciblé.
Aucun callback GTK n’est exécuté depuis le worker.
Le mécanisme fonctionne après une réussite, une annulation et un redémarrage.
Application peut recevoir la notification sans lire en boucle l’état de la tâche.
git diff --check ne remonte aucune erreur.

Validation finale

make clean
make
make test
git diff --check

Puis test ciblé :

G_DEBUG=gc-friendly \
G_SLICE=always-malloc \
valgrind \
    --leak-check=full \
    --show-leak-kinds=definite,indirect \
    --errors-for-leak-kinds=definite,indirect \
    --track-origins=yes \
    --error-exitcode=1 \
    ./tests/test_tool_initializer

# Notifier l’application lorsque l’initialisation des outils est terminée ## Contexte `ToolInitializer` détecte maintenant les outils externes en arrière-plan au démarrage de l’application. Le composant sait déjà : - enregistrer les outils du catalogue ; - détecter leur présence ; - récupérer leur version ; - produire un résumé ; - gérer l’annulation ; - autoriser un nouveau lancement après une fin ou une annulation. Cependant, `Application` n’est pas encore informée directement de la fin de l’initialisation. Elle ne peut donc pas réagir proprement pour mettre à jour l’interface ou afficher un bilan. ## Objectif Ajouter un mécanisme de notification permettant à `Application` d’être appelée lorsque `ToolInitializer` termine son travail. La notification devra transmettre : - l’état final de la tâche ; - le résumé d’initialisation lorsqu’il est valide ; - l’erreur lorsque l’initialisation échoue ; - une référence sûre vers le registre des outils déjà mis à jour. ## Périmètre ### À faire - Ajouter une API publique permettant d’enregistrer un callback de fin. - Exécuter le callback dans le contexte principal GLib. - Garantir que le callback n’est appelé qu’une fois par lancement. - Transmettre un résumé uniquement lorsque la tâche est terminée avec succès. - Permettre de distinguer : - réussite ; - annulation ; - échec. - Garantir que les données restent valides pendant l’exécution du callback. - Ajouter les tests unitaires correspondants. - Intégrer les nouveaux tests au `Makefile`. ### Hors périmètre - Création d’une nouvelle vue GTK. - Affichage graphique de la liste des outils. - Installation automatique des outils manquants. - Lancement d’un outil OSINT. - Modification du catalogue d’outils. ## Contraintes techniques - C17 uniquement. - Aucun accès GTK depuis le worker. - Le callback doit être exécuté sur le thread principal. - `ToolInitializer` reste propriétaire de son `ToolRegistry`. - `Application` ne doit recevoir qu’un accès emprunté au registre. - Le callback ne doit pas prolonger artificiellement la durée de vie de `Application`. - La destruction pendant une initialisation doit rester sûre. - Une annulation ne doit pas produire de résumé valide. - Un nouveau lancement doit pouvoir réutiliser le même callback. ## API attendue L’API exacte pourra être ajustée pendant l’implémentation, mais elle devra couvrir les besoins suivants : ```c typedef void (*ToolInitializerCompletedCallback)( ToolInitializer *tool_initializer, BackgroundTaskState final_state, const ToolInitializationSummary *summary, const GError *error, gpointer user_data ); ``` Une fonction publique devra permettre d’enregistrer le callback et ses données : ```c void tool_initializer_set_completed_callback( ToolInitializer *tool_initializer, ToolInitializerCompletedCallback callback, gpointer user_data, GDestroyNotify destroy_notify ); ``` ## Comportement attendu ### Réussite - Le registre contient les informations mises à jour. - Le résumé est non nul. - L’état final vaut `BACKGROUND_TASK_STATE_COMPLETED`. - L’erreur est nulle. ### Annulation - Le résumé est nul. - L’état final vaut `BACKGROUND_TASK_STATE_CANCELLED`. - Le callback est appelé une seule fois. ### Échec - Le résumé est nul. - L’état final vaut `BACKGROUND_TASK_STATE_FAILED`. - Une erreur lisible est transmise lorsque disponible. ## Tests attendus Ajouter au minimum les cas suivants : 1. enregistrement d’un callback valide ; 2. remplacement d’un callback existant ; 3. appel après une réussite ; 4. résumé transmis après une réussite ; 5. registre déjà mis à jour au moment du callback ; 6. appel après une annulation ; 7. absence de résumé après une annulation ; 8. appel après un échec ; 9. callback exécuté sur le contexte principal ; 10. callback appelé une seule fois ; 11. nouveau lancement utilisant le même callback ; 12. destruction correcte des données utilisateur via `GDestroyNotify`. ## Critères d’acceptation - Tous les tests existants restent valides. - Les nouveaux tests passent avec `-Werror`. - Valgrind ne détecte aucune perte directe ou indirecte dans le test ciblé. - Aucun callback GTK n’est exécuté depuis le worker. - Le mécanisme fonctionne après une réussite, une annulation et un redémarrage. - `Application` peut recevoir la notification sans lire en boucle l’état de la tâche. - `git diff --check` ne remonte aucune erreur. ## Validation finale ```bash make clean make make test git diff --check ``` Puis test ciblé : ```bash G_DEBUG=gc-friendly \ G_SLICE=always-malloc \ valgrind \ --leak-check=full \ --show-leak-kinds=definite,indirect \ --errors-for-leak-kinds=definite,indirect \ --track-origins=yes \ --error-exitcode=1 \ ./tests/test_tool_initializer

fy59 closed this issue

2026-07-18 15:44:01 +02:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fy59/labfy-investigation#44

No description provided.