Pour l'organisation d'un projet en C pour GNOME, le mieux est d'analyser l'architecture d'un logiciel existant (gedit par exemple), et de s'en inspirer. Généralement on crée une sous-classe de GtkApplication pour la gestion générale de l'application, surtout au démarrage et à l'arrêt. On peut avoir quelques singletons par-ci par-là pour stocker certaines données, sous forme de fichier XML par exemple. Quand l'instance du singleton est créée, les données sont extraites et stockées dans des structures de données (en mémoire), et quand l'application quitte, les données sont sauvegardées. Ce n'est qu'un exemple bien sûr, il peut y avoir d'autres classes interagissant avec une base de données, etc. Il y a aussi généralement une sous-classe de GtkApplicationWindow, qui permet de coller les différents composants de la fenêtre principale ensemble. On peut imaginer une classe SidePanel, avec une instance stockée dans un attribut de la fenêtre principale.
Toutes les bonnes pratiques de l'orienté objets s'appliquent. Certains n'aiment pas les singletons, donc rien n'empêche d'utiliser d'autres design patterns. Il vaut mieux faire attention à ne pas créer des « God Classes », qui en savent un peu trop. Et éviter si possible trop de dépendances entre les différentes classes. La sous-classe de GtkApplicationWindow aura sans doute des attributs vers beaucoup d'autres classes, mais la dépendance ne va que dans un sens.
Enfin, pour apprendre GObject, il y a beaucoup d'explications dans la documentation officielle. La partie « I. Concepts » est très importante. Mais ça peut être assez difficile à comprendre au début. Il y a quelques livres sur GLib/GObject/GTK+, mais aucun n'est vraiment récent. C'est un reproche que je fais aux développeurs de GTK+, il faudrait qu'un des développeurs mette à jour un des livres...
Pour finir, j'ai écris récemment une page getting started pour gedit, ça peut toujours être utile pour d'autres projets. Mais comme je l'ai dit dans un commentaire plus haut, il vaut mieux contribuer à un projet existant.
[^] # Re: Organisation d'un projet écrit en C ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Quelques langages de programmation pour GNOME. Évalué à 1.
Le lien fonctionne bien ici.
Pour l'organisation d'un projet en C pour GNOME, le mieux est d'analyser l'architecture d'un logiciel existant (gedit par exemple), et de s'en inspirer. Généralement on crée une sous-classe de GtkApplication pour la gestion générale de l'application, surtout au démarrage et à l'arrêt. On peut avoir quelques singletons par-ci par-là pour stocker certaines données, sous forme de fichier XML par exemple. Quand l'instance du singleton est créée, les données sont extraites et stockées dans des structures de données (en mémoire), et quand l'application quitte, les données sont sauvegardées. Ce n'est qu'un exemple bien sûr, il peut y avoir d'autres classes interagissant avec une base de données, etc. Il y a aussi généralement une sous-classe de GtkApplicationWindow, qui permet de coller les différents composants de la fenêtre principale ensemble. On peut imaginer une classe SidePanel, avec une instance stockée dans un attribut de la fenêtre principale.
Toutes les bonnes pratiques de l'orienté objets s'appliquent. Certains n'aiment pas les singletons, donc rien n'empêche d'utiliser d'autres design patterns. Il vaut mieux faire attention à ne pas créer des « God Classes », qui en savent un peu trop. Et éviter si possible trop de dépendances entre les différentes classes. La sous-classe de GtkApplicationWindow aura sans doute des attributs vers beaucoup d'autres classes, mais la dépendance ne va que dans un sens.
Enfin, pour apprendre GObject, il y a beaucoup d'explications dans la documentation officielle. La partie « I. Concepts » est très importante. Mais ça peut être assez difficile à comprendre au début. Il y a quelques livres sur GLib/GObject/GTK+, mais aucun n'est vraiment récent. C'est un reproche que je fais aux développeurs de GTK+, il faudrait qu'un des développeurs mette à jour un des livres...
Pour finir, j'ai écris récemment une page getting started pour gedit, ça peut toujours être utile pour d'autres projets. Mais comme je l'ai dit dans un commentaire plus haut, il vaut mieux contribuer à un projet existant.