Posté par Renault (site web personnel) .
Évalué à 7.
Dernière modification le 28 novembre 2018 à 13:58.
Cela fait quelques mois que Fedora propose le paquet firefox-wayland dans les dépôts pour démarrer Firefox avec Wayland. C'est par ailleurs un script qui utilise une variable d'environnement spécifique pour l'activer à chaud sans changer le code de Firefox sous-jacent.
Posté par Renault (site web personnel) .
Évalué à 5.
Dernière modification le 28 novembre 2018 à 20:12.
C'est vrai, mais Firefox utilise une solution interne pour cela qui doit donc gérer Wayland également. GTK+ est utilisé uniquement pour quelques trucs, on est très loin d'une application GNOME ou pure GTK+ comme GIMP.
C'est quand même là qu'on se rend compte que le monde de l'informatique est très mal organisé et que la complexité de la plupart des logiciels n'est absolument pas nécessaire.
Si un navigateur ne peut pas se contenter d'un toolkit graphique par défaut (ça me semble douteux, mais soit), alors il doit coder le sien. Un peu à la manière dont GTK a émergé de Gimp. Ce concept de «certains trucs en GTK, et le reste avec une solution maison», ça fait froid dans le dos, en terme de portabilité, de sécurité, d'homogénéité, et d'évolutivité…
Posté par mahikeulbody .
Évalué à 1.
Dernière modification le 29 novembre 2018 à 14:18.
J'imagine qu'il faut prendre en compte l'historique du logiciel et des toolkits multi-plateforme disponibles au début du projet. Peut-être qu'en démarrant aujourd'hui ils auraient choisi un toolkit existant multi-plateforme, Qt5 par exemple, au lieu de développer une solution interne.
Ceci dit, vu qu'ils ont aussi créé Rust alors qu'il y avait très probablement d'autres langages qui auraient pu convenir, c'est peut-être l'effet du syndrome "not invented here" (même si au final, ça donne un très bon langage utilisable par la communauté).
J'imagine qu'il faut prendre en compte l'historique du logiciel et des toolkits multi-plateforme disponibles au début du projet. Peut-être qu'en démarrant aujourd'hui ils auraient choisi un toolkit existant multi-plateforme, Qt5 par exemple, au lieu de développer une solution interne.
En particulier aujourd'hui, ils auraient sans doute utilisé en priorité un toolkit utilisé par plus de quelques personnes afin de diminuer le nombre de bugs rencontrés. Bref, ils auraient fait le même choix.
Ceci dit, vu qu'ils ont aussi créé Rust alors qu'il y avait très probablement d'autres langages qui auraient pu convenir, c'est peut-être l'effet du syndrome "not invented here" (même si au final, ça donne un très bon langage utilisable par la communauté).
Je crois justement qu'il n'y avait pas de langage permettant de rassembler les caractéristiques qu'ils voulaient pour le développement du navigateur, soit un langage permettant rapidité d’exécution, sécurité, possibilité de migrer le code par petit bouts facilement. Ce doit être le moins bon exemple de syndrome NIH chez mozilla.
Peut-être qu'en démarrant aujourd'hui ils auraient choisi un toolkit existant multi-plateforme, Qt5 par exemple, au lieu de développer une solution interne.
Je pense que c'est difficile de remettre en cause le fait de développer des solutions maisons quand l'existant ne nous convient pas. À la limite, pourquoi pas. Après, je trouve ça un peu douteux, dans le cadre d'un logiciel comme un navigateur, de ne pas trouver son compte dans les tookits graphiques existants, mais bon, je méconnais peut-être les spécificités des navigateurs ou les problèmes de performances liés à l'utilisation de moteurs de rendus très complexes.
Le problème, c'est de ne pas développer ce toolkit graphique comme un toolkit graphique, justement. Le réflexe de tout programmeur, et surtout de tout libriste convaincu, c'est de réfléchir sur la portée et la généralité du code. Si pour des raisons qui t'appartiennent tu développes un jeu vidéo, et que pour résoudre certains problèmes tu as besoin de coder des routines optimisées pour inverser des matrices ou résoudre des équations différentielles, tu vas forcément te dire "ouhlala, ce code là n'a rien à faire dans un jeu vidéo", et tu vas dissocier les projets. J'imagine que quand on code un navigateur et qu'on en est à recoder un compositeur de fenêtre portable, on finit par se demander si ce qu'on fait ne mérite pas d'être dissocié du navigateur, et d'avoir sa propre vie.
C'est d'ailleurs ce qui s'est passé pour Rust, et c'est très bien. On peut utiliser Rust pour des projets qui n'ont rien à voir avec un navigateur, c'est devenu un outil mis à disposition de la communauté. Et inversement, je vois mal une fonctionnalité dans Firefox devoir attendre que Rust passe à la version supérieure.
Après, je trouve ça un peu douteux, dans le cadre d'un logiciel comme un navigateur, de ne pas trouver son compte dans les tookits graphiques existants, mais bon, je méconnais peut-être les spécificités des navigateurs ou les problèmes de performances liés à l'utilisation de moteurs de rendus très complexes.
Firefox a été conçu autour de la technologie XUL pour définir son interface. Ce n'est pas vraiment possible de considérer que c'est équivalent à GTK+ ou Qt ou que deux ou trois patchs dans ces projet aurait suffit pour obtenir ce qu'ils souhaitaient.
Du coup le rendu de la fenêtre de Firefox est fait par son moteur de rendu Web intégré.
J'imagine que quand on code un navigateur et qu'on en est à recoder un compositeur de fenêtre portable, on finit par se demander si ce qu'on fait ne mérite pas d'être dissocié du navigateur, et d'avoir sa propre vie.
Cela a été fait, cela s'est appelé xulrunner et certains applications tierces s'en sont servies. Mais on ne peut pas dire que cela a eu un grand succès, XUL étant lié à Gecko qui est lié à Firefox, le découplage est particulièrement délicat.
Bref, le contexte historique et technologique de Firefox a grandement justifié ce choix et il n'a pas été déraisonnable.
Firefox a été conçu autour de la technologie XUL pour définir son interface.
Je croyais que XUL était passé aux oubliettes depuis un petit peu de temps? (Wikipédia donne 2015 pour la dernière version de XULrunner?). Du coup, ils ont recodé complètement un autre système d'interface multiplateforme?
xulrunner permettait à d'autres projets d'utiliser xul, mozilla a arrêté d'investir dans cette possibilité il y a qqes années. Aujourd'hui xul est complétement lié à Firefox.
Ils ont fait standardiser des trucs de XUL dans HTML, apparemment. Ça met un peu en lumière le fait qu’il y a dans le HTML, donc des technos au coeur de Firefox, de quoi faire une interface, des Widgets et tout. Du coup le découplage entre ff et le toolkit qu’ils utilisent pour l’interface n’est pas si évident que tu le suggères, au contraire en fait.
# En test dans Fedora depuis longtemps
Posté par Renault (site web personnel) . Évalué à 7. Dernière modification le 28 novembre 2018 à 13:58.
Cela fait quelques mois que Fedora propose le paquet firefox-wayland dans les dépôts pour démarrer Firefox avec Wayland. C'est par ailleurs un script qui utilise une variable d'environnement spécifique pour l'activer à chaud sans changer le code de Firefox sous-jacent.
Bref, n'hésitez pas à tester.
[^] # Re: En test dans Fedora depuis longtemps
Posté par Maderios . Évalué à 1.
Du coté de Arch, trois paquets Aur dispo, dont un fait avec celui de Fedora.
Détails sur le développement:
https://mastransky.wordpress.com/2018/10/09/firefox-on-wayland-update/
# Wayland impacte les applis ?
Posté par mahikeulbody . Évalué à 3.
Dans ma vision naïve des choses, Wayland n'impactait que les toolkits graphiques utilisés par les applications.
Qu'est-ce que je n'ai pas compris ?
[^] # Re: Wayland impacte les applis ?
Posté par Renault (site web personnel) . Évalué à 5. Dernière modification le 28 novembre 2018 à 20:12.
C'est vrai, mais Firefox utilise une solution interne pour cela qui doit donc gérer Wayland également. GTK+ est utilisé uniquement pour quelques trucs, on est très loin d'une application GNOME ou pure GTK+ comme GIMP.
[^] # Re: Wayland impacte les applis ?
Posté par arnaudus . Évalué à 5.
C'est quand même là qu'on se rend compte que le monde de l'informatique est très mal organisé et que la complexité de la plupart des logiciels n'est absolument pas nécessaire.
Si un navigateur ne peut pas se contenter d'un toolkit graphique par défaut (ça me semble douteux, mais soit), alors il doit coder le sien. Un peu à la manière dont GTK a émergé de Gimp. Ce concept de «certains trucs en GTK, et le reste avec une solution maison», ça fait froid dans le dos, en terme de portabilité, de sécurité, d'homogénéité, et d'évolutivité…
[^] # Re: Wayland impacte les applis ?
Posté par mahikeulbody . Évalué à 1. Dernière modification le 29 novembre 2018 à 14:18.
J'imagine qu'il faut prendre en compte l'historique du logiciel et des toolkits multi-plateforme disponibles au début du projet. Peut-être qu'en démarrant aujourd'hui ils auraient choisi un toolkit existant multi-plateforme, Qt5 par exemple, au lieu de développer une solution interne.
Ceci dit, vu qu'ils ont aussi créé Rust alors qu'il y avait très probablement d'autres langages qui auraient pu convenir, c'est peut-être l'effet du syndrome "not invented here" (même si au final, ça donne un très bon langage utilisable par la communauté).
[^] # Re: Wayland impacte les applis ?
Posté par Elfir3 . Évalué à 4.
En particulier aujourd'hui, ils auraient sans doute utilisé en priorité un toolkit utilisé par plus de quelques personnes afin de diminuer le nombre de bugs rencontrés. Bref, ils auraient fait le même choix.
Je crois justement qu'il n'y avait pas de langage permettant de rassembler les caractéristiques qu'ils voulaient pour le développement du navigateur, soit un langage permettant rapidité d’exécution, sécurité, possibilité de migrer le code par petit bouts facilement. Ce doit être le moins bon exemple de syndrome NIH chez mozilla.
[^] # Re: Wayland impacte les applis ?
Posté par arnaudus . Évalué à 2.
Je pense que c'est difficile de remettre en cause le fait de développer des solutions maisons quand l'existant ne nous convient pas. À la limite, pourquoi pas. Après, je trouve ça un peu douteux, dans le cadre d'un logiciel comme un navigateur, de ne pas trouver son compte dans les tookits graphiques existants, mais bon, je méconnais peut-être les spécificités des navigateurs ou les problèmes de performances liés à l'utilisation de moteurs de rendus très complexes.
Le problème, c'est de ne pas développer ce toolkit graphique comme un toolkit graphique, justement. Le réflexe de tout programmeur, et surtout de tout libriste convaincu, c'est de réfléchir sur la portée et la généralité du code. Si pour des raisons qui t'appartiennent tu développes un jeu vidéo, et que pour résoudre certains problèmes tu as besoin de coder des routines optimisées pour inverser des matrices ou résoudre des équations différentielles, tu vas forcément te dire "ouhlala, ce code là n'a rien à faire dans un jeu vidéo", et tu vas dissocier les projets. J'imagine que quand on code un navigateur et qu'on en est à recoder un compositeur de fenêtre portable, on finit par se demander si ce qu'on fait ne mérite pas d'être dissocié du navigateur, et d'avoir sa propre vie.
C'est d'ailleurs ce qui s'est passé pour Rust, et c'est très bien. On peut utiliser Rust pour des projets qui n'ont rien à voir avec un navigateur, c'est devenu un outil mis à disposition de la communauté. Et inversement, je vois mal une fonctionnalité dans Firefox devoir attendre que Rust passe à la version supérieure.
[^] # Re: Wayland impacte les applis ?
Posté par Renault (site web personnel) . Évalué à 6.
Firefox a été conçu autour de la technologie XUL pour définir son interface. Ce n'est pas vraiment possible de considérer que c'est équivalent à GTK+ ou Qt ou que deux ou trois patchs dans ces projet aurait suffit pour obtenir ce qu'ils souhaitaient.
Du coup le rendu de la fenêtre de Firefox est fait par son moteur de rendu Web intégré.
Cela a été fait, cela s'est appelé xulrunner et certains applications tierces s'en sont servies. Mais on ne peut pas dire que cela a eu un grand succès, XUL étant lié à Gecko qui est lié à Firefox, le découplage est particulièrement délicat.
Bref, le contexte historique et technologique de Firefox a grandement justifié ce choix et il n'a pas été déraisonnable.
[^] # Re: Wayland impacte les applis ?
Posté par arnaudus . Évalué à 2.
Je croyais que XUL était passé aux oubliettes depuis un petit peu de temps? (Wikipédia donne 2015 pour la dernière version de XULrunner?). Du coup, ils ont recodé complètement un autre système d'interface multiplateforme?
[^] # Re: Wayland impacte les applis ?
Posté par antistress (site web personnel) . Évalué à 3.
xulrunner permettait à d'autres projets d'utiliser xul, mozilla a arrêté d'investir dans cette possibilité il y a qqes années. Aujourd'hui xul est complétement lié à Firefox.
[^] # Re: Wayland impacte les applis ?
Posté par Thomas Douillard . Évalué à 3.
Ils ont fait standardiser des trucs de XUL dans HTML, apparemment. Ça met un peu en lumière le fait qu’il y a dans le HTML, donc des technos au coeur de Firefox, de quoi faire une interface, des Widgets et tout. Du coup le découplage entre ff et le toolkit qu’ils utilisent pour l’interface n’est pas si évident que tu le suggères, au contraire en fait.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.