Utilise libpeas pour les plugins, c'est ce qui est utilisé dans gedit et d'autres applications de GNOME (libpeas provient du code de gedit à la base).
Mais, avoir un système de plugin rajoute beaucoup d'emmerdes pour le développement d'une application. Il faut que l'application définisse une API que les plugins pourront utiliser. Et, si possible, cette API ne doit pas être cassée à chaque version... Comme pour le développement d'une librairie, en gros. Avec l'age, n'importe quel code a besoin d'être restructuré un jour ou l'autre, et maintenir la compatibilité des plugins est parfois difficile et demande en tout cas plus de boulot.
De plus les plugins rajoutent de l'incertitude dans la stabilité de l'application. Toi, étant développeur de l'éditeur de texte, tu veux être certain que l'application soit stable, qu'il n'y ait pas de bugs. Avec des plugins, il peut y avoir plein de bugs imprévus. Les plugins sont généralement moins bien écrit et contiennent plus de bugs que le cœur de l'application (pcq développé par des gens moins expérimenté). Un cassage de l'API ne fait qu’aggraver les choses. Et les bugs ne sont pas forcément isolé à la fonctionnalité qu'un plugin fourni, un plugin peut faire apparaitre des bugs dans d'autres fonctionnalités. Et quand un utilisateur a plein de bugs et qu'il n'en connait pas vraiment la cause, il se dit que l'application est pourrie et va voir ailleurs.
Donc... je ne recommande pas vraiment les systèmes de plugins. En tout cas certainement pas pour une jeune application dont l'architecture du code doit encore évoluer.
Ceci dit, pour en revenir à libpeas, ça utilise sous le capot dlopen(), pour charger des shared libraries au runtime. Un plugin est donc une sorte de librairie.
[^] # Re: Merci pour vos réponses et le futur de IT-Edit.
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche IT-edit, un éditeur de texte avec terminaux intégrés. Évalué à 1.
Utilise libpeas pour les plugins, c'est ce qui est utilisé dans gedit et d'autres applications de GNOME (libpeas provient du code de gedit à la base).
Mais, avoir un système de plugin rajoute beaucoup d'emmerdes pour le développement d'une application. Il faut que l'application définisse une API que les plugins pourront utiliser. Et, si possible, cette API ne doit pas être cassée à chaque version... Comme pour le développement d'une librairie, en gros. Avec l'age, n'importe quel code a besoin d'être restructuré un jour ou l'autre, et maintenir la compatibilité des plugins est parfois difficile et demande en tout cas plus de boulot.
De plus les plugins rajoutent de l'incertitude dans la stabilité de l'application. Toi, étant développeur de l'éditeur de texte, tu veux être certain que l'application soit stable, qu'il n'y ait pas de bugs. Avec des plugins, il peut y avoir plein de bugs imprévus. Les plugins sont généralement moins bien écrit et contiennent plus de bugs que le cœur de l'application (pcq développé par des gens moins expérimenté). Un cassage de l'API ne fait qu’aggraver les choses. Et les bugs ne sont pas forcément isolé à la fonctionnalité qu'un plugin fourni, un plugin peut faire apparaitre des bugs dans d'autres fonctionnalités. Et quand un utilisateur a plein de bugs et qu'il n'en connait pas vraiment la cause, il se dit que l'application est pourrie et va voir ailleurs.
Donc... je ne recommande pas vraiment les systèmes de plugins. En tout cas certainement pas pour une jeune application dont l'architecture du code doit encore évoluer.
Ceci dit, pour en revenir à libpeas, ça utilise sous le capot dlopen(), pour charger des shared libraries au runtime. Un plugin est donc une sorte de librairie.