En fait, ça marche de manière un peu différente de ce que tu pourrais penser :
G'MIC définit son propre langage de script pour l'implémentation de filtres et d'effets, et je n'utilise donc que très peu l'API de GIMP en réalité (juste pour les entrées-sorties entre le plug-in et GIMP).
Tous les filtres et commandes G'MIC existants sont implémentés dans ce langage de script G'MIC.
Ca me permet de proposer exactement les mêmes fonctionnalités sur plusieurs interfaces différentes sans dépendre des langages/bibliothèques propres à chaque interface, et surtout sans avoir à refaire tout le travail pour chaque interface (ça serait impossible à maintenir !). De même, si j'implémente de nouveaux filtres, il est très facile pour moi de les rendre disponible tout de suite sur chaque interface.
Le plug-in GIMP n'est qu'une interface G'MIC parmi d'autre.
Par contre, c'est la réalisation de cette interface proprement dite a quand même demandé beaucoup de boulot, notamment du côté du GUI (c'est du GTK2).
En théorie, on n'aurait pas à utiliser vraiment beaucoup de fonctionnalités de GEGL si on veut 'porter' le plug-in G'MIC existant pour les prochaines versions de GIMP, excepté les fonctions d'entrées sorties de GEGL pour passer les données images et les paramètres des filtres à G'MIC (et vice-versa).
Mais d'après ce que j'ai compris de GEGL, c'est qu'il va falloir idéalement créer des "noeuds" correspondants à des opérateurs différents, et c'est là que le bât blesse. Car cette approche n'est pas du tout adaptée pour l'interfaçage avec des bibliothèques (comme G'MIC) qui proposent elles-même plusieurs filtres différents (des centaines ici!): on pourrait créer des centaines de noeuds différents pour chaque fonctionnalité, mais c'est pas très pratique, probablement pas optimisé en occupation mémoire, et on perd l'intérêt du plug-in actuel qui est de pouvoir se mettre à jour de manière automatique, en permettant par exemple l'ajout de nouveaux filtres automatiquement via le réseau, sans avoir à réinstaller quoique ce soit). Bref, le plug-in G'MIC c'est une sorte de 'meta-plug-in' et c'est un peu dommage d'être obligé de le "casser" pour le porter pour GEGL (on va rien gagner, et on perd la centralisation des filtres). Je pense que 'Mathmap', qui est un autre 'meta-plug-in' pour GIMP est un peu dans le même cas.
Et puis de mon point de vue, ça veut dire qu'il faut de toute façon redévelopper toute une interface GEGL pour G'MIC en repartant de zéro (pas les filtres, mais tout le reste !). Vraiment pas très sexy comme perspective, surtout qu'on gagnera pas grand chose.
J'avais discuté un peu avec les dev GIMP sur IRC, et ils m'avaient pas du tout assuré que les plug-ins actuels pourraient continuer à fonctionner (ce que je traduis par 'ça va probablement pêter'). Notamment le dev de GEGL, qui m'a pas semblé du tout aimable malgré ma politesse légendaire (il m'a bien fait comprendre assez vite qu'il exécrait le C++, et que CImg c'était de la merde, fin de la discussion).
[^] # Re: GEGL
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Traitement d'image : Sortie de G'MIC 1.5.5.1. Évalué à 6.
En fait, ça marche de manière un peu différente de ce que tu pourrais penser :
G'MIC définit son propre langage de script pour l'implémentation de filtres et d'effets, et je n'utilise donc que très peu l'API de GIMP en réalité (juste pour les entrées-sorties entre le plug-in et GIMP).
Tous les filtres et commandes G'MIC existants sont implémentés dans ce langage de script G'MIC.
Ca me permet de proposer exactement les mêmes fonctionnalités sur plusieurs interfaces différentes sans dépendre des langages/bibliothèques propres à chaque interface, et surtout sans avoir à refaire tout le travail pour chaque interface (ça serait impossible à maintenir !). De même, si j'implémente de nouveaux filtres, il est très facile pour moi de les rendre disponible tout de suite sur chaque interface.
Le plug-in GIMP n'est qu'une interface G'MIC parmi d'autre.
Par contre, c'est la réalisation de cette interface proprement dite a quand même demandé beaucoup de boulot, notamment du côté du GUI (c'est du GTK2).
En théorie, on n'aurait pas à utiliser vraiment beaucoup de fonctionnalités de GEGL si on veut 'porter' le plug-in G'MIC existant pour les prochaines versions de GIMP, excepté les fonctions d'entrées sorties de GEGL pour passer les données images et les paramètres des filtres à G'MIC (et vice-versa).
Mais d'après ce que j'ai compris de GEGL, c'est qu'il va falloir idéalement créer des "noeuds" correspondants à des opérateurs différents, et c'est là que le bât blesse. Car cette approche n'est pas du tout adaptée pour l'interfaçage avec des bibliothèques (comme G'MIC) qui proposent elles-même plusieurs filtres différents (des centaines ici!): on pourrait créer des centaines de noeuds différents pour chaque fonctionnalité, mais c'est pas très pratique, probablement pas optimisé en occupation mémoire, et on perd l'intérêt du plug-in actuel qui est de pouvoir se mettre à jour de manière automatique, en permettant par exemple l'ajout de nouveaux filtres automatiquement via le réseau, sans avoir à réinstaller quoique ce soit). Bref, le plug-in G'MIC c'est une sorte de 'meta-plug-in' et c'est un peu dommage d'être obligé de le "casser" pour le porter pour GEGL (on va rien gagner, et on perd la centralisation des filtres). Je pense que 'Mathmap', qui est un autre 'meta-plug-in' pour GIMP est un peu dans le même cas.
Et puis de mon point de vue, ça veut dire qu'il faut de toute façon redévelopper toute une interface GEGL pour G'MIC en repartant de zéro (pas les filtres, mais tout le reste !). Vraiment pas très sexy comme perspective, surtout qu'on gagnera pas grand chose.
J'avais discuté un peu avec les dev GIMP sur IRC, et ils m'avaient pas du tout assuré que les plug-ins actuels pourraient continuer à fonctionner (ce que je traduis par 'ça va probablement pêter'). Notamment le dev de GEGL, qui m'a pas semblé du tout aimable malgré ma politesse légendaire (il m'a bien fait comprendre assez vite qu'il exécrait le C++, et que CImg c'était de la merde, fin de la discussion).