 |
Samedi 28 juin 2025 - 05:03 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Note : traduction par Cédric Saïller.
Voici l'entrevue de Robert Norris à propos du développement de son nouveau navigateur Internet sur AROS.
Quand prévoyez-vous de dévoiler le nom de votre
navigateur ?Ici même, tout de suite ! Le navigateur s'appellera "Traveller" (c'est l'orthographe britannique avec deux "L"). J'avais déjà pensé à ce nom avant de demander des idées et lorsque deux personnes l'ont également suggéré j'ai alors su que c'était le bon.
Les raisons pour lesquelles je l'apprécie sont triples :
- C'est un bon compagnon pour Wanderer.
- Il poursuit la tradition de donner des noms relatifs à la recherche de l'inconnu aux navigateurs : Navigator, Explorer, Konqueror, Safari, etc.
- Cela fait référence à une blague parmi les membres de mon équipe au travail, donc c'est aussi un peu personnel.
Avez-vous été surpris des réponses que vous avez
reçues sur l'appellation de ce nouveau navigateur ?Je dois vous avouer que la raison de demander des idées de noms était, en partie, de faire un petit battage médiatique, mais les réponses étaient totalement inattendues. Les gens ont afflué de partout pour offrir une opinion et j'ai noté que de gros sites Amiga en parlaient aussi, ce qui m'a surpris car je ne me suis jamais considéré comme étant un amigaïste. Peut-être le suis-je, juste un peu. ;)
Avez-vous un projet global à propos de la création
de ce nouveau navigateur ou êtes-vous uniquement concentré sur les contraintes lié à la cagnotte ?J'ai scindé le travail en deux parties. La première est le portage de WebKit. Cela implique d'effectuer le portage des deux composants de WebKit, JavaScriptCore et WebCore, et d'écrire un "lanceur" minimal qui va ouvrir une fenêtre du navigateur pour tester le moteur. Cette partie requiert également de faire le portage des différentes bibliothèques dont WebKit dépend et de combler les lacunes d'AROS lui-même.
La seconde partie est l'intégration du moteur d'AROS lui-même. Cela induit de créer un objet Zune qui enveloppe WebKit et qui permettra à toutes les applications Zune d'utiliser le moteur s'il est choisi. Et une fois le développement de Traveller fini, le navigateur basé sur Zune pourra démarrer.
Envisagez-vous d'ajouter des choses comme les onglets
ou les favoris ?Pas initialement. Mon but pour la réalisation de la cagnotte est juste un navigateur avec une interface basique : barre d'adresse, boutons de retour arrière, d'arrêt et de page d'accueil. Les fonctionnalités comme les onglets, les favoris et autres pourront être ajoutées plus tard.
Je ne sais pas encore si ce sera moi qui ferai cela ou quelqu'un d'autre. Mon espoir est qu'arrivé à ce stade, d'autres personnes soient intéressées pour travailler sur Traveller. Je ne veux vraiment pas travailler sur un navigateur indéfiniment ! Il y a beaucoup d'autres choses dans AROS qui nécessitent du travail et je tends à m'ennuyer si je fais la même chose trop longtemps.
Comment avez-vous décidé que WebKit serait la voie
pour apporter un moteur de navigateur à AROS ?Une grosse partie de mon expérience en programmation a été de la programmation Web, donc je sais que le HTML est d'une incroyable complexité et qu'il faut une sérieuse quantité de code pour créer un navigateur qui peut en gérer une petite quantité convenablement.
Le Web est également connu pour ses problèmes de compatibilité entre navigateurs. Nous sommes tous familiers avec la situation d'avoir un site qui ne fonctionne pas avec tel ou tel navigateur.
Ces deux facteurs expliquent que pour écrire un navigateur pour une plate-forme niche telle qu'AROS, où vous n'avez pas les ressources pour développer proprement et maintenir beaucoup de code, vous choisissez un navigateur phare qui pourra prendre en compte, à votre place, ces difficultés relatives au Web.
Une fois établi cela, je devais regarder quels types de navigateurs libres existaient et lesquels je pouvais utiliser. Pendant longtemps, il n'y avait quasiment qu'une seule possibilité, et c'était bien sûr Gecko, le moteur de Firefox. Cela faisait un moment que je n'avais pas regardé son code, mais je me rappelais que c'était quasiment impossible à pénétrer, et encore moins de le modifier. Je n'y ai pas prêté beaucoup d'attention récemment, mais j'ai entendu dire que cela n'avait pas beaucoup changé. Les auteurs sont également de plus en plus axés sur Firefox, donc il est difficile de trouver du soutien pour le portage de Gecko lui-même.
WebKit est un projet plus récent (bien que ses racines proviennent de KJS et de KHTML, les composants qui pilotent le navigateur Konqueror de KDE), donc vous pourriez dire que sa gestion des sites Web n'est pas très étendu mais Apple à déjà fait pas mal de choses satisfaisantes avec ça. Ils ont gardé les sources libres, ont activement encouragé les contributions de tout le monde et ont travaillé dur pour le garder léger, rapide et portable. Cela a été payant ; WebKit pilote bien sûr Safari le navigateur de MaxOS X (et bientôt Windows) mais aussi une large part du marché des mobiles, soutenu par Nokia. Quand est arrivé l'iPhone, nous avons vu des sites Web réclamer d'être compatible avec lui. Et Google vient juste d'annoncer leur projet de téléphone, Android, qui utilise également WebKit.
Nous avons donc là un moteur de navigateur qui ne demande qu'à être porté sur toutes les plates-formes et dont le soutien sera de plus en plus large. Pour moi c'était un choix évident.
Depuis que Webkit est porté sur AROS, que vous
reste-t-il à faire pour produire un navigateur Internet que nous pourrions utiliser ? Plus précisément, quelle est la différence
entre avoir un moteur de navigateur et avoir un navigateur ?Eh bien en premier, WebKit n'est pas encore porté - je n'en suis qu'au début. Le moteur JavaScript fonctionne mais le moteur Internet nécessite beaucoup plus de travail.
La meilleure façon de voir ce qu'un moteur de navigateur fait est de regarder votre navigateur actuel. Il y a d'un côté toutes les fonctionnalités annexes - menus, boutons suivant/précédent/accueil, barre d'adresse, onglets, favoris, barre de statut, etc. - et de l'autre la partie principale de la fenêtre où les pages Web apparaissent. WebKit (ou Gecko peu importe) est ainsi responsable de la partie page Web. Toutes les autres fonctionnalités qui font d'un moteur un navigateur proprement dit sont connues sous le nom de "chrome", et son principal souci est l'intégration du moteur avec le reste du bureau.
Ce "chrome" est ce qui est requis pour convertir WebKit en un navigateur. C'est ce qu'est Traveller.
Est-ce plus facile que d'écrire un navigateur à partir
de rien ?Absolument. Bien que faire que WebKit utilise les bibliothèques d'AROS (par exemple gérer l'affichage et les entrées) soit difficile, c'est un jeu d'enfant comparé à l'horreur qu'est de développer toutes les fonctionnalités Web.
J'ai noté que les gens demandent s'ils peuvent avoir
Firefox sur AROS maintenant que WebKit est là. Mais Firefox n'utilise pas le moteur de WebKit, il utilise Gecko. Le navigateur
Mac Safari utilise WebKit. Est-ce correct ? Quel est votre point de vue là-dessus ?C'est exact. Firefox n'a rien à voir avec WebKit, et porter WebKit n'aidera pas un portage de Firefox (excepté peut-être dans les cas où j'ai eu à améliorer la bibliothèque C de AROS, ou mettre à jour nos compilateurs, etc, ce dont un portage de Firefox pourrait éventuellement avoir besoin).
Pour être honnête, je ne vois pas beaucoup d'intérêt à porter Firefox sur AROS. Il pourrait être intéressant de porter Gecko (bien que je doute que nous soyons assez gros pour les deux), mais Firefox serait naze - il ne ressemble en rien à une application AROS.
Comment pensez-vous que ce nouveau navigateur AROS
sera comparativement aux autres navigateurs sur Amiga et MorphOS ? Par exemple, Sputnik, le navigateur basé sur KHTML qui a été
porté sur MorphOS ? IBrowse ou AWeb qui sont disponibles sur Amiga ?Je n'ai jamais utilisé ces navigateurs, juste lu quelques trucs à propos d'eux et vu des captures d'écrans. Je peux être très loin de la vérité (et je m'attends à être poliment corrigé dans ce cas) mais je pense que la comparaison sera très favorable à Traveller.
IBrowse et AWeb semblent trop loin derrière dans leur gestion des options modernes pour être réellement pertinents. Comme je l'ai dit précédemment, je ne vois pas l'intérêt de navigateurs Web qui ne peuvent pas travailler avec les grands et lourds sites utilisant JavaScript. Je parle de GMail par exemple.
Et pour Sputnik, il est actuellement basé sur S60 WebKit, qui est une branche de WebKit faite pas Nokia pour leurs téléphones mobiles. Je suppose que Traveller sera plus similaire à celui-ci, mais la banche S60 n'est pas maintenue à jour avec les développements concentrés sur WebKit. Cela signifie sans doute que Traveller pourra avoir de nouvelles fonctionnalités plus rapidement.
Quelles sortes de défis devez-vous relever avec ce
projet ?Il y a deux principales choses qui l'ont rendu et continuent à le rendre difficile.
La première est les lacunes et bogues dans AROS. Par exemple, porter le moteur JavaScriptCore requiert un système appelé posix_memalign(), qui alloue de la mémoire d'une manière différente qu'à l'habitude. AROS n'en dispose pas, donc je dois rechercher comment les appels fonctionnent et comment AROS effectue les allocations mémoires avant de les implémenter. JavaScriptCore nécessite également des fonctions que notre système de bibliothèques mathématiques n'a pas. Pour les avoir j'ai fini par devoir mettre à jour les bibliothèques mathématiques à partir des sources (FreeBSD). Cela a pris une semaine. En ce moment, je lutte avec nos bibliothèques réseau parce qu'elles ne sont pas complètement intégrées au coeur du système, ce qui rend difficile de travailler avec.
Ce genre de choses demande habituellement beaucoup de temps à être réglé, mais cela vaut la peine car l'ensemble d'AROS en bénéficie.
L'autre défi est le portage de WebCore en lui-même. Il faudra beaucoup d'effort pour le connecter à AROS, en raison de tout le travail qu'il y a à faire. Il faut, par exemple, dessiner des choses à l'écran, accepter les entrées, afficher les polices et les images, etc. Je connais une partie de ces fonctionnalités du côté de AROS, mais rien concernant d'autres parties, donc je dois en apprendre plus. On m'a dit qu'il y a pas mal de choses à mettre en oeuvre du côté de WebCore (quelque chose comme 70 fichiers) pour n'obtenir qu'un minimum de fonctionnalités. Je n'ai même pas encore vraiment regardé, mais je sais que ça ne sera pas facile, même si AROS fournit tout ce dont j'ai besoin et que mes connaissances en C++ sont assez robustes.
Apprendre de nouvelles choses est exactement la raison pour laquelle je passe tant de mon temps libre sur les ordinateurs, donc rien de tout ceci n'est un problème. Cela prendra juste du temps.
J'ai lu sur votre blog la présence du moteur
JavaScriptCore dans WebKit. Avez-vous eu quelque chose de spécial à faire pour gérer JavaScript pendant le portage ?
Avez-vous pu le compiler en utilisant GCC ou comment cela a-t-il été pris en charge ?Le JavaScriptCore est un interpréteur de JavaScript, il fait tourner du code JavaScript. Il n'a pas besoin de JavaScript pour être compilé ; c'est écrit intégralement en C++.
Le processus de portage a été intéressant. Premièrement, j'avais besoin d'un compilateur. WebKit nécessite d'être compilé avec GCC version 4 et est écrit en C++. Nous avons ajouté des correctifs pour que GCC puisse construire des programmes pour AROS, mais la dernière version qui intégrait une gestion C++ était la version 3. Nous avons donc ajouté un correctif pour la version 4, mais ce n'était que pour le C, pas le C++. La première chose que j'ai faite fut ainsi de prendre une copie récente du dernier GCC (4.2.2), et faire fonctionner C++.
Une fois que j'ai eu un compilateur, j'ai modifié le système de compilation (system build) de WebKit pour l'utiliser et j'ai ainsi pu commencer. A chaque fois que la compilation échouait, je corrigeais le problème et réessayais. Certaines choses ont eu besoin de l'ajout d'un peu de code dans WebKit afin de l'aider à savoir quoi faire dans AROS. D'autres choses ont nécessité des changements sur AROS, par exemple les bibliothèques mathématiques citées précédemment.
Finalement, la compilation a crée testkjs, le programme de test JavaScriptCore. Je l'ai placé, lui et la suite de test JavaScript, dans mon installation AROS, j'ai lancé tout ça et j'ai pu commencer les tests.
Le programme de test a retourné quelques problèmes inhabituels, j'ai donc eu à revoir le code pour faire de petites modifications. Les gens sur le canal IRC #webkit m'ont beaucoup aidé, en m'apprenant, par exemple, comment différents aspects du code fonctionnent.
Tout cela est d'ailleurs quasiment le processus standard pour porter n'importe quelle application ou bibliothèque : apprendre au système de compilation comment utiliser les compilateurs AROS, modifier le code jusqu'à ce qu'il compile, et enfin tester et corriger les bogues.
Ceci est un projet très excitant ! Je suis passionné par
votre travail. Je suis content que vous ayez décidé de travailler sur ce projet et vous souhaite bonne chance.Merci ! Je suis également exalté par ce projet. Et merci pour ces questions intéressantes, elles vont réellement m'aider à savoir pourquoi je suis ici, sur AROS.
|
