AmiZilla est toujours vivant, ROar! 🙂 Voici une mise à jour de ce que nous avons fait ces 6 derniers mois sur NSPR, XPCOM et comment se passe la compilation de l’executable. De plus, nous avons commencé une couche d’abstraction multi-plateforme GTK->MUI/Réaction (ne ratez pas les captures d’écran et les exemples en lien).
Mise à jour Amizilla du 28/06/05 :
OK, beaucoup de personnes pensaient que le projet AmiZilla était mort, et à raison, comme aucune information n’était diffusée depuis longtemps ! Je me suis donc dit qu’il était temps de faire une mise au point pour montrer que ça avance !
D’abord, le NSPR est pratiquement terminé et fonctionnel. Il s’agit d’une couche d’abstraction de base pour l’OS (pour les choses telles que le TCP/IP). XPCOM fonctionne plus ou moins (XPCOM est un Cross Platform Component Object Model). Il permet aux différents composants de Mozilla d’échanger des messages et d’accéder aux fichiers sur n’importe quelle plateforme, etc. Quelques personnes ont réussit à compiler le code avec ces couches, produisant un exécutable de 500Mo (infos de débug incluses). Cet exécutable se lance et quitte proprement mais demande un serveur X11 comme écran ! A l’heure actuelle nous somme passés d’un exécutable statique énorme à une version Bibliothèque (a2ixlibrary), mais nous n’avons pas réussi à le compiler de cette manière pour l’instant.
Nous somme en train de créer une documentation comprenant la liste des fichiers nécessaires, et la façon de compiler un exécutable, etc, ainsi que des informations essentielles pour installer un environnement de Cross-Compiling sur Linux ou Windows. C’est très important, tant que vous n’avez pas une carte accélératrice Dragon, vous ne pouvez pas compiler AmiZilla sur un amiga 68k, par manque de mémoire (il faut au moins 256-512 Mo de mémoire, et nous ne savons même pas combien de temps prendrait la compilation d’un code de 200 Mo sur un 68k) ! Mais il devrait être possible de compiler sur AmigaOne ou Pegasos.
Mais plus intéressant, c’est que des personnes travaillent sur une couche GTK->MUI(Zun)/Reaction, principalement pour le projet AmiZilla, mais elle pourra aussi être utilisée pour d’autre applications GTK. Il est tout à fait possible que l’on ait Firefox fonctionnel en premier (il s’agit juste d’adapter la compilation pour obtenir soit Firefox, soit Amizilla), et par la suite, il serait possible d’avoir la suite Mozilla complète si cela intéresse quelqu’un (j’en doute). On espère le faire tourner sur 68k/MUI en premier, l’exécutable 68k devrait pouvoir tourner tel quel sur AmigaOS4 et MorphOS.
Ensuite nous procéderons à un port natif MorphOS/AmigaOS/AROS. Il faudra peut être la dernière version de GCC (3.x) pour la version MorpOS.
La couche GTK->MUI/Reaction sera créée à part, afin de la rendre plus simplement multi OS (Amiga OS 3.x, OS4, MorphOS and AROS), mais l’objectif principal est d’avoir Firefox utilisable sur Amiga OS 3.x. Une prime AROS a été mise en place pour une couche GTK->MUI, pour qu’elle soit facilement portée sur les autres systèmes Amiga (si cela n’est pas déjà fait). De plus, une prime sur MorphZone existe également afin de commencer leur propre layerGTK->MUI, ou il sera reversé à AROS. La couche GTK sera disponible en deux bibliothèques (glib.library et gtk.library).
Jusqu’à présent, GTK->MUI avance bien, MUI étant très flexible, et est assez proche du point de vue structure de GTK (les 2 utilisent un Object Model [des objets comme Fenêtres, Boutons, etc.., mais pas comme dans la programmation orientée objet de C++/Java)], et GTK ne poke pas directement dans sa structure de données, mais utilise des fonctions pour manipuler les objets.
Nous avons créé une petit exemple utilisant des appels GTK, pour initialiser GTK (en fait, il s’agit d’un appel MUI), ouvrant une fenêtre contenant un bouton, un gadget de fermeture et coupant le système (MUI). Nous avons également compilé les exemples du kit de développement GTK, helloworld et helloworld2, sans aucune modification des sources. Le seul problème mineur est que MUI renvoie un pointeur quand il est initialisé, ce que ne fait pas GTK, il faut donc sauver ce pointeur d’un manière ou d’une autre, probablement dans les données de l’application, sauvegardées dans la structure de la bibliothèque elle-même.
Des captures d’écran de GTK->MUI sont disponibles sur le site SourceForge dédié.
Quant aux démos GTK->MUI ainsi que leur source sont également disponible sur SourceForge [Ndt : Nécessite la library ixemul.library V48]
GDK est une couche d’abstraction vidéo indépendante de l’OS pour GTK [GTK appel GDK qui appelle le système d’affichage (pour Linux, c’est X-windows)]. Nous ne nous sommes pas encore penchés complètement dessus. Mais il n’y a pas d’inquiétude à avoir à propos de GDK, tant que seul GTK y fait appel, et Firefox ne devrait pas faire d’appels directs. Et comme nous remplaçons les appels GTK par des appels MUI/Reaction, GDK ne sera pas appelé !
Le problème se pose concernant GLib. Nous cherchons actuellement comment Firefox l’utilise. Certaines parties de GLib sont très simples et demandent juste une recompilation, d’autres sont plus complexes comme les évènements, signaux et flux, et pourront être remplacées par des appels MUI/Reaction.
Nous accueillons toujours les bonnes volontés qui veulent nous rejoindre (plus on sera, plus vite cela sera terminé 🙂 ). Pour rejoindre la liste AmiZilla, vous pouvez soit envoyer un mail à [email protected], ou aller sur la page Yahoo AmiZilla (nécessite un compte Yahoo). Les donations sont toujours appréciées et encouragent les développeurs 🙂
Page de donation AmiZilla
Ants
AmiZilla Team
