Tout d'abord il y a au moins une autre application non liée à Mozilla qui s'en sert : Songbird
Oui, mais non. Songbird n'était pas une application qui embarquait gecko, mais qui reposait sur gecko, ou plus exactement XulRunner. Comme la majeure partie d'application XUL de cette époque. Songbird était loin d'être la seule, il y a en a eu plein d'autres : Thunderbird, Nvu, Komodo Ide, Chatzilla et j'en passe.
Il y a une différence entre embarquer Gecko, le moteur de rendu et utiliser XulRunner comme runtime. Le second, c'est en gros Firefox sans son interface : on a donc Gecko, mais aussi tout un framework et des composants XUL ou techniques prêt à l'emploi.
Gecko, c'était vraiment que la partie moteur de rendu et XPCOM (système de composants binaire ou JS).
Il fut un temps où il y avait la possibilité d'embarquer Gecko, c'est à dire d'avoir un lib avec une API, permettant d'instancier un moteur de rendu, de le manipuler (charger une page etc).
Camino, mais aussi d'autres navigateurs de l'époque, utilisaient cette lib. (donc ce n'était pas des applis XUL).
XulRunner, plus simple à utiliser pour développer une application, avait pris le dessus, entre autre parce que Thunderbird l'utilisait et que donc Mozilla le maintenait, et Mozilla du coup mettait moins de moyen sur la partie "embeddable" de Gecko.
L'API embed fut donc de moins en moins maintenue. Et quand Mozilla decida d'abandonner XulRunner puis le XUL, c'était trop tard pour relancer le projet embed. Presque plus personne n'utilisait cette API (Camino était mort...).
Ensuite, il y avait peu de contributeurs sur cette api embed.
En clair, contrairement à ce qui s'est dit, ce n'est pas une vraie volonté de Mozilla de ne pas rendre Gecko embarquable, c'est juste que les moyens manquaient, et qu'il y avait d'autres priorités à l'époque.
Il y a bien eu quelques workshops (il y a de cela 10 ans) pour tenter de relancer le projet de cette API, (j'avais assisté à l'un d'entre eux), mais la mayonnaise n'a pas pris.
Depuis, ils se sont un peu rattrapés : Servo, le moteur 100% en rust de mozilla est fait depuis le début pour être embarqué. Et il y a une lib embarquant gecko pour les navigateurs pour Android, geckoView, qu'utilise Firefox pour Android (ou d'autres variantes, je n'ai pas trop suivi).
Je ne sais pas ce qu'il en est aujourd'hui de cette API embed de Gecko.
[^] # Re: La fondation mozilla partage une lourde part de responsabilité dans le fait que blink
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox...). Évalué à 5.
Oui, mais non. Songbird n'était pas une application qui embarquait gecko, mais qui reposait sur gecko, ou plus exactement XulRunner. Comme la majeure partie d'application XUL de cette époque. Songbird était loin d'être la seule, il y a en a eu plein d'autres : Thunderbird, Nvu, Komodo Ide, Chatzilla et j'en passe.
Il y a une différence entre embarquer Gecko, le moteur de rendu et utiliser XulRunner comme runtime. Le second, c'est en gros Firefox sans son interface : on a donc Gecko, mais aussi tout un framework et des composants XUL ou techniques prêt à l'emploi.
Gecko, c'était vraiment que la partie moteur de rendu et XPCOM (système de composants binaire ou JS).
Il fut un temps où il y avait la possibilité d'embarquer Gecko, c'est à dire d'avoir un lib avec une API, permettant d'instancier un moteur de rendu, de le manipuler (charger une page etc).
Camino, mais aussi d'autres navigateurs de l'époque, utilisaient cette lib. (donc ce n'était pas des applis XUL).
XulRunner, plus simple à utiliser pour développer une application, avait pris le dessus, entre autre parce que Thunderbird l'utilisait et que donc Mozilla le maintenait, et Mozilla du coup mettait moins de moyen sur la partie "embeddable" de Gecko.
L'API embed fut donc de moins en moins maintenue. Et quand Mozilla decida d'abandonner XulRunner puis le XUL, c'était trop tard pour relancer le projet embed. Presque plus personne n'utilisait cette API (Camino était mort...).
Ensuite, il y avait peu de contributeurs sur cette api embed.
En clair, contrairement à ce qui s'est dit, ce n'est pas une vraie volonté de Mozilla de ne pas rendre Gecko embarquable, c'est juste que les moyens manquaient, et qu'il y avait d'autres priorités à l'époque.
Il y a bien eu quelques workshops (il y a de cela 10 ans) pour tenter de relancer le projet de cette API, (j'avais assisté à l'un d'entre eux), mais la mayonnaise n'a pas pris.
Depuis, ils se sont un peu rattrapés : Servo, le moteur 100% en rust de mozilla est fait depuis le début pour être embarqué. Et il y a une lib embarquant gecko pour les navigateurs pour Android, geckoView, qu'utilise Firefox pour Android (ou d'autres variantes, je n'ai pas trop suivi).
Je ne sais pas ce qu'il en est aujourd'hui de cette API embed de Gecko.