On pourrait comparer cette situation avec l'exemple (ouhouh, l'appeau à troll) des projets Mozilla
Non, je ne pense pas :-)
Si la plupart des projets d'applis basés sur XulRunner, sont livrées avec leur propre xulrunner, c'est pour d'autres raisons :
utilisation d'une version de XulRunner plus récente que celle proposée par le paquet officiel de la distrib. Et si l'appli a besoin d'une version plus récente, c'est bien souvent pour profiter des dernières API de Gecko etc..
utilisation d'une version patchée de XulRunner ou buildée différement. Par exemple, BlueGriffon, en plus d'utiliser une version plus récente de XulRunner pour permettre aux utilisateurs d'utiliser les dernières nouveautés HTML5 / CSS3 dans la création de leur page web, contient aussi des patchs, qui ne sont pas encore intégrés en upstream (mais peut-être ce n'est plus le cas aujourd'hui, je crois que Glazou a fait le maximum pour pouvoir utiliser une version non patchée).
Autre exemple, l'éditeur Komodo, qui utilise lui aussi XulRunner, a besoin du support python dans les XPCOM. Le flag de build pour cette fonctionnalité n'est pas activée par défaut dans XulRunner.
etc..
Bref, le paquet XulRunner officiel de Debian n'est pas très utile pour pas mal de projets xulrunner, à cause de son ancienneté notamment. Cela peut convenir pour des petits projets 100% XUL, mais dés que l'on veut faire une appli complexe, on a souvent besoin d'un XulRunner spécifique en version ou patché.
D'ailleurs, pour ioQuake3, tu as souligné un peu le même souci : divers projets de jeux utilisent une version patchée différente de ioQuake3. L'utilisation d'un libioquake3 commun n'est donc pas possible, non pas parce que les développeurs ils ont la culture windows, mais parce que techniquement ce n'est pas possible. Une solution serait de porter les patchs upstream. mais il y en a probablement qui ne sont pas intéressants pour ioQuake3 et tout les jeux basés dessus.
# à propos de XulRunner
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Une histoire de fork. Évalué à 8.
Non, je ne pense pas :-)
Si la plupart des projets d'applis basés sur XulRunner, sont livrées avec leur propre xulrunner, c'est pour d'autres raisons :
Bref, le paquet XulRunner officiel de Debian n'est pas très utile pour pas mal de projets xulrunner, à cause de son ancienneté notamment. Cela peut convenir pour des petits projets 100% XUL, mais dés que l'on veut faire une appli complexe, on a souvent besoin d'un XulRunner spécifique en version ou patché.
D'ailleurs, pour ioQuake3, tu as souligné un peu le même souci : divers projets de jeux utilisent une version patchée différente de ioQuake3. L'utilisation d'un libioquake3 commun n'est donc pas possible, non pas parce que les développeurs ils ont la culture windows, mais parce que techniquement ce n'est pas possible. Une solution serait de porter les patchs upstream. mais il y en a probablement qui ne sont pas intéressants pour ioQuake3 et tout les jeux basés dessus.