PS: je ne cherche pas à spécialement mousser Daniel ou Kaze, juste à rétablir la vérité. Ce sont deux personnes que je connais très bien et que j'estime.
disclaimer : j'ai bossé avec Daniel pendant 4 ans et demi (mais pas sur Nvu).
Un jour, en 2005, il a décidé que Nvu ne le satisfaisait plus
Totalement faux. Un jour, en 2005, Linspire, qui avait commandé à Daniel le développement de Nvu, a décidé de ne pas poursuivre au delà de la version 1.0, pour les raisons qu'on sait par la suite : difficulté financière et cie, qui aboutit à la disparition de Linspire.
Et Linspire a décidé aussi qu'ils ne "libéreraient" jamais la marque Nvu (propriété en fait du fondateur de Linspire). Impossible pour Daniel donc de poursuivre le développement de Nvu sous le nom de Nvu donc, ni même mettre à jour le site web et cie, malgré de long mois de tractations.
À cela faut ajouter de long mois occupés sur d'autres projets (bah ouai, fallait bien manger), donc pas le temps de bosser sur un "fork" pendant pas mal de temps.
Quand il décida de se relancer sur le projet (concrètement en 2008), il y a plusieurs raisons qui ont fait que BlueGriffon a été fait from scratch :
nvu était basé sur le gecko de l'époque: 1.7, qui était alors totalement obsolète en 2008 (gecko 1.9). À ceci il faut ajouter qu'il y avait pas mal de patch sur Gecko pour faire fonctionner Nvu. Patchs qui n'étaient plus trop nécessaires sur gecko 1.9. Mais c'est un travail assez titanesque pour migrer de Gecko 1.7 à 1.9, vous pouvez demander à Kaze, celui qui a maintenu Nvu (sous le nom de Kompozer) et qui a migré vers 1.8.
Le code des couches hautes de Nvu (interface, API générales et cie), était hérité de feu Mozilla Composer (dont Daniel était aussi l'un des auteurs principaux). API qui devint vieille, obsolète, moche, difficilement évolutive, maintenable etc...
Bref, nécessité de tout refaire from scratch, pour gagner en temps, en maintenance, en performance etc..
Pour l'utilisateur, Kompozer n'est pas forcément Obsolète (Coucou Kaze !), et même si Kaze a fait pas mal de boulot pour refondre certaines parties de l'interface et des api générales, il reste encore pas mal d'héritages de Mozilla Composer. Donc oui, d'un point de vue code, Kompozer est en partie obsolète, d'autant plus qu'il est basé encore sur un noyau Gecko 1.8, ce qui, en terme de support de CSS et HTML5, est très très loin derrière Gecko 2.0, utilisé par BlueGriffon.
C'est quand même dommage d'avoir besoin d'installer une application, alos que les technos web auraient permis de faire cela directement dans le browser. Non ?
Non. Les technos web sont loin de permettre de tout faire. (et heureusement, sinon les browsers seraient des vrais gruyères en matières de sécurité).
Clairement, il y a besoin d'utiliser des apis internes de Gecko pour manipuler le composant éditeur de Gecko. Toutes les APIS ne sont pas exposées dans les pages web.
Ne serait-ce que pour charger ou sauver le contenu html de l'éditeur dans un fichier sur le poste utilisateur, il n'y a rien pour ça en HTML. Fort heureusement d'ailleurs... Et il y a plein d'autres fonctionnalités qui ne sont pas possibles dans un contexte non-privilégié d'une page web.
Il produit du HTML5 sérialisé xml, càd du code pas standard
Tu devrais lire la spec HTML5, pour éviter de dire de telles bétises.
surtout de pas mettre de doctype réel
Tu devrais lire la spec HTML5, pour éviter de dire de telles bétises (bis)
(Rappel: même si il peut y avoir des bugs, l'auteur du logiciel s'y connait un tout petit peu au niveau HTML. Il fut co-auteur de HTML4, et il est co-chairman du working group CSS au W3C)
Nvu fut déclaré successeur de Composer, mais n'avait déjà, tout comme BlueGriffon, aucun lien avec Mozilla (à part la techno). Nvu était un logiciel commandé par feu Linspire, à la société disruptive innovations, pour avoir un vrai éditeur HTML wysiwyg sous linux.
tu veux dire que tu es jaloux de l'interface kikoolol de skype sous windows ? :-)
Personnellement, je préfère la "sobriété" de leur client linux.
Le truc qui me fait peur, c'est quid de l'avenir de la version linux. Parce que pour moi, sous linux, je n'ai pas trouvé d'équivalent qui me permettent de converser avec des user windows, mac sans problèmes (à moins que l'offre open source ait évoluée ces derniers mois).
Aller, encore quelques petits efforts et on fera du XUL-like. Finalement, la plateforme Mozilla et XUL a de l'avenir malgré ses 12 ans d'age.. :-)
Et sinon, embarquer V8 n'est apparemment pas une super idée pour le moment (c'est le gars de Nginx qui le dit). Alors que SpiderMonkey est quasi aussi performant, et propose du javascript plus évolué (iterateur, generateur, array comprehension etc). Ceci dit, le choix de V8 est assez naturel puisque webkit est utilisé..
le souci de tmpfs en ram, c'est qu'il faut recopier toutes les sources (plusieurs megas) dans ce système de fichier, ce qui est plutôt long à faire. Et quand on y fait des modifs, faut faire une sauvegarde à chaque modif (si la machine venait à s'éteindre...).
Ou on peut y mettre le résultat de la compil, mais là le problème c'est qu'à chaque fois que tu rallumes la machine, c'est la compil tout entière qu'il faut te retaper (25min à 2h selon les machines).
bref, pas l'idéal le tmpfs je pense. (ou alors laisser allumer la machine 24/24)
Pendant qu'on y est, que pensez-vous de l'usage d'un SSD dans un contexte où il y a beaucoup de lecture écriture ? J'ai souvent besoin de compiler des gros trucs (genre Firefox).
C'est bien gérer maintenant les histoires de gestion d'allocations des mémoires dans le SSD, pour éviter que ce soit toujours la même partie du SSD qui soit utilisé ? ou est-ce que maintenant les composants sont suffisamment "costaud" pour durer longtemps avec des cycles lecture/écriture soutenu ?
Une idée, pour éviter d'avoir une config trop chère : c'est de prendre un SSD avec une capacité juste suffisante pour le système et les logiciels (40 ou 60 Go suffisent la plupart du temps), histoire de booster ton système, et un bon vieux DD grosse capacité pour ton home.
J'ai pas testé mais ça pourrait le faire je pense (pour les desktops)
ça prend 2 à 4 octets, là où pour l'image + code html, ça en prend des dizaines (oui, le volume d'un fichier, ça fait parti de l'accessibilité)
il n'y a pas que le HTML dans la vie, tout les formats de documents n'acceptent pas forcément l'incrustation d'images. Cela peut donc être utile "d'illustrer" des formats de fichiers purement textuel par exemple.
Il y a maintenant 4 depots : central, aurora, beta, release.
Central (minefield). Comme indiqué, c'est le champs de mine. C'est commit à tout va.
Aurora, c'est une image de central à un instant donné, + les corrections pour stabiliser. Au bout de 6 semaines, le code va dans la branche beta
Beta = version plutôt stable, qui est là pour débusquer les derniers bugs. De par son nom, il a une audience plus large. En fait, à chaque branche, l'audience (le nombre de personne qui veut tester) est plus grande, mais la stabilité aussi. Au bout de 6 semaines, basculement du code dans la branche release.
Release = image de la branche beta à un moment donné, c'est à dire image de la beta au moment où la beta est bonne pour être utilisé par tout le monde.
La différence avec le processus précédent (pour Firefox 4), c'est qu'il y avait seulement deux dépôts : central et la branche "beta/release". Et beta/release était fusionné avec central à interval régulier. Ce qui provoquait des "freezes" de central, c'est à dire des periodes pendant lesquels on ne pouvait commiter que des corrections ou des nouvelles fonctionnalités "bloquantes", correspondantes à la roadmap.
Avant le dev de Firefox 4, il y avait encore un autre processus de dev un peu différent avec des freezes plus contraignants encore (la branche beta/release était en fait crée seulement peu de temps avant la release).
Et donc maintenant, dans le central, il n'y a plus de freeze. On peut commiter toutes les corrections et fonctionnalités que l'on veut (enfin, qui sont reviewés). Cela veut dire que c'est la fête tout les jours pour ceux qui suivent les nightly. Les testeurs des nightlies "central" ont des nouveautés tout les jours ou toutes les semaines. miam !
En résumé : la roadmap de développement de Firefox n'est plus orienté "features", mais c'est en quelques sortes du "rolling release". Une version ne sort plus "quand une feature est prête", mais à date fixe, toutes les douzes semaines (qui correspond à la période de stabilisation).
Elle l'utilise : tous les fichiers sources produits par Mozilla et ses contributeurs, sont explicitement sous les trois licences, MPL, GPL, LGPL. À toi de choisir celle qui te convient.
Donc voilà, c'est une grosse déception, mais surtout une grosse bêtise de ma part d'avoir confié au nuage de la mofo tant de données personnelles, sans au préalable vérifier par moi-même que cela allait fonctionner correctement.
Si tu as si peur pour tes données personnelles, la première chose à faire, c'est de ne pas les confier à un quelconque nuage. point barre. (du bons sens quoi). Quant à être parano, autant être parano jusqu'au bout.
Mais il n'y a pas de raison de faire du FUD comme ça envers la MoFo (et d'être parano), tout ce que tu stockes chez eux est chiffré avec une clé que seul toi possède (même quand ça stocke sur ton propre serveur).
Et si Sync ne fonctionnait vraiment pas, ça se saurait, depuis presque 3 ans que ça existe (sous forme d'extension avant Firefox 4). Tu as à priori un problème dans l'utilisation de Sync, ça ne veut pas dire que ça ne fonctionne pas en temps normal.
la version android repose sur le même code que la version desktop, à savoir le moteur Gecko 2.0 (C++).
Ainsi toutes les amélioratoins en terme de perf, et toutes les nouveautés technologiques (html5, CSS3, SVG, SMIL et cie) que vous avez dans Firefox 4 pour desktop, vous les avez dans la version mobile.
Les dev chez Mozilla bossent sur TOUTES les plateformes, et pour cause, une bonne partie du code est indépendant de la plateforme. De plus, il y a des dizaines de machines qui lancent les tests unitaires sur toutes les plateformes.
Maintenant, pour te donner des chiffres sur le nombre de testeurs, je ne pense pas qu'on en ait : ce sont en grande majorité des bénévoles. L'équipe QA de Mozilla n'est qu'une goutte d'eau parmi tout les testeurs.
Les testeurs donc, c'est toi, moi etc.. Et il se trouve que la majorité de rapport de bugs ont été découvert par des utilisateurs sous windows. Donc que la majorité des testeurs sont sous windows.
Il nous manque clairement donc des utilisateurs linux pour tester.
Le vrai problème aurait été de garder l'ancienne interface. À la vue du succès des interfaces "light" avec les autres navigateurs, on ne pouvait que suivre dans cette direction. Et plus c'est minimaliste, plus il est difficile de se différencier.
Là où on peut se différencier, ce sont dans les interfaces et fonctionnalités annexes, l'agencement des éléments d'interface et c'est ce qu'essaye de faire Mozilla. D'ailleurs, je trouve que Fx4 s'intègre bien mieux dans Gnome que Chromium (qui a une barre de titre horrible par exemple, ne reprenant pas le thème gtk)
[^] # Re: FOUTAISES
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de BlueGriffon 1.0. Évalué à 9.
PS: je ne cherche pas à spécialement mousser Daniel ou Kaze, juste à rétablir la vérité. Ce sont deux personnes que je connais très bien et que j'estime.
[^] # Re: FOUTAISES
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de BlueGriffon 1.0. Évalué à 10.
disclaimer : j'ai bossé avec Daniel pendant 4 ans et demi (mais pas sur Nvu).
Totalement faux. Un jour, en 2005, Linspire, qui avait commandé à Daniel le développement de Nvu, a décidé de ne pas poursuivre au delà de la version 1.0, pour les raisons qu'on sait par la suite : difficulté financière et cie, qui aboutit à la disparition de Linspire.
Et Linspire a décidé aussi qu'ils ne "libéreraient" jamais la marque Nvu (propriété en fait du fondateur de Linspire). Impossible pour Daniel donc de poursuivre le développement de Nvu sous le nom de Nvu donc, ni même mettre à jour le site web et cie, malgré de long mois de tractations.
À cela faut ajouter de long mois occupés sur d'autres projets (bah ouai, fallait bien manger), donc pas le temps de bosser sur un "fork" pendant pas mal de temps.
Quand il décida de se relancer sur le projet (concrètement en 2008), il y a plusieurs raisons qui ont fait que BlueGriffon a été fait from scratch :
Bref, nécessité de tout refaire from scratch, pour gagner en temps, en maintenance, en performance etc..
Pour l'utilisateur, Kompozer n'est pas forcément Obsolète (Coucou Kaze !), et même si Kaze a fait pas mal de boulot pour refondre certaines parties de l'interface et des api générales, il reste encore pas mal d'héritages de Mozilla Composer. Donc oui, d'un point de vue code, Kompozer est en partie obsolète, d'autant plus qu'il est basé encore sur un noyau Gecko 1.8, ce qui, en terme de support de CSS et HTML5, est très très loin derrière Gecko 2.0, utilisé par BlueGriffon.
[^] # Re: Pourquoi en XUL et pas en HTML ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de BlueGriffon 1.0. Évalué à 3.
Non. Les technos web sont loin de permettre de tout faire. (et heureusement, sinon les browsers seraient des vrais gruyères en matières de sécurité).
Clairement, il y a besoin d'utiliser des apis internes de Gecko pour manipuler le composant éditeur de Gecko. Toutes les APIS ne sont pas exposées dans les pages web.
Ne serait-ce que pour charger ou sauver le contenu html de l'éditeur dans un fichier sur le poste utilisateur, il n'y a rien pour ça en HTML. Fort heureusement d'ailleurs... Et il y a plein d'autres fonctionnalités qui ne sont pas possibles dans un contexte non-privilégié d'une page web.
[^] # Re: XHTML
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de BlueGriffon 1.0. Évalué à 9.
Tu devrais lire la spec HTML5, pour éviter de dire de telles bétises.
Tu devrais lire la spec HTML5, pour éviter de dire de telles bétises (bis)
(Rappel: même si il peut y avoir des bugs, l'auteur du logiciel s'y connait un tout petit peu au niveau HTML. Il fut co-auteur de HTML4, et il est co-chairman du working group CSS au W3C)
Pour le reste, je t'invite à ouvrir des tickets ici : http://bugzilla.bluegriffon.org/
[^] # Re: Officiellement Mozilla ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de BlueGriffon 1.0. Évalué à 3.
Nvu fut déclaré successeur de Composer, mais n'avait déjà, tout comme BlueGriffon, aucun lien avec Mozilla (à part la techno). Nvu était un logiciel commandé par feu Linspire, à la société disruptive innovations, pour avoir un vrai éditeur HTML wysiwyg sous linux.
[^] # Re: En parlant de troll^Wlinuxfr…
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Bienvenue à Solutions Linux Open Source 2011. Évalué à 10.
c'est pour montrer que linux fonctionne aussi sur le matériel de la pomme. non ?
[^] # Re: c'est pas déjà le cas?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sauve Skype peut..... Évalué à 10.
tu veux dire que tu es jaloux de l'interface kikoolol de skype sous windows ? :-)
Personnellement, je préfère la "sobriété" de leur client linux.
Le truc qui me fait peur, c'est quid de l'avenir de la version linux. Parce que pour moi, sous linux, je n'ai pas trouvé d'équivalent qui me permettent de converser avec des user windows, mac sans problèmes (à moins que l'offre open source ait évoluée ces derniers mois).
(non, ceci n'est pas un troll)
[^] # Re: Sécurité...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les certificats ne marchent plus avec Firefox 4.01 pour la déclaration de TVA. Évalué à 3.
donc effectivement, le ministère propose de désactiver des sécurités. génial.
[^] # Re: Sécurité...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les certificats ne marchent plus avec Firefox 4.01 pour la déclaration de TVA. Évalué à 5.
bah si j'ai bien compris, c'est le site du ministère qui utilise une version du protocol SSL toute moisie, vulnérable...
Mais que font les admin sys de ces sites ? :-)
# Vers du Mozilla like ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Qt 5 à l'horizon. Évalué à 9.
QML +CSS, du js, avec des composants en C++...
Aller, encore quelques petits efforts et on fera du XUL-like. Finalement, la plateforme Mozilla et XUL a de l'avenir malgré ses 12 ans d'age.. :-)
Et sinon, embarquer V8 n'est apparemment pas une super idée pour le moment (c'est le gars de Nginx qui le dit). Alors que SpiderMonkey est quasi aussi performant, et propose du javascript plus évolué (iterateur, generateur, array comprehension etc). Ceci dit, le choix de V8 est assez naturel puisque webkit est utilisé..
[^] # Re: SSD : idéal pour compiler ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 3.
le souci de tmpfs en ram, c'est qu'il faut recopier toutes les sources (plusieurs megas) dans ce système de fichier, ce qui est plutôt long à faire. Et quand on y fait des modifs, faut faire une sauvegarde à chaque modif (si la machine venait à s'éteindre...).
Ou on peut y mettre le résultat de la compil, mais là le problème c'est qu'à chaque fois que tu rallumes la machine, c'est la compil tout entière qu'il faut te retaper (25min à 2h selon les machines).
bref, pas l'idéal le tmpfs je pense. (ou alors laisser allumer la machine 24/24)
[^] # Re: Résumé
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tant qu'à refaire l'électtricité…. Évalué à 3.
et ton frigo, il fait comment pour aller commander tout seul ce qui manque ? hein ? (sauf si il est wifi)
:-)
# SSD : idéal pour compiler ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 2.
Pendant qu'on y est, que pensez-vous de l'usage d'un SSD dans un contexte où il y a beaucoup de lecture écriture ? J'ai souvent besoin de compiler des gros trucs (genre Firefox).
C'est bien gérer maintenant les histoires de gestion d'allocations des mémoires dans le SSD, pour éviter que ce soit toujours la même partie du SSD qui soit utilisé ? ou est-ce que maintenant les composants sont suffisamment "costaud" pour durer longtemps avec des cycles lecture/écriture soutenu ?
[^] # Re: Cher
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 4.
Une idée, pour éviter d'avoir une config trop chère : c'est de prendre un SSD avec une capacité juste suffisante pour le système et les logiciels (40 ou 60 Go suffisent la plupart du temps), histoire de booster ton système, et un bon vieux DD grosse capacité pour ton home.
J'ai pas testé mais ça pourrait le faire je pense (pour les desktops)
[^] # Re: Utilité
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Unicode. Évalué à 8.
c'est plus accessible dans le sens où :
[^] # Re: quelle différence
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La première build de Firefox Aurora est disponible. Évalué à 7.
Il y a maintenant 4 depots : central, aurora, beta, release.
Central (minefield). Comme indiqué, c'est le champs de mine. C'est commit à tout va.
Aurora, c'est une image de central à un instant donné, + les corrections pour stabiliser. Au bout de 6 semaines, le code va dans la branche beta
Beta = version plutôt stable, qui est là pour débusquer les derniers bugs. De par son nom, il a une audience plus large. En fait, à chaque branche, l'audience (le nombre de personne qui veut tester) est plus grande, mais la stabilité aussi. Au bout de 6 semaines, basculement du code dans la branche release.
Release = image de la branche beta à un moment donné, c'est à dire image de la beta au moment où la beta est bonne pour être utilisé par tout le monde.
La différence avec le processus précédent (pour Firefox 4), c'est qu'il y avait seulement deux dépôts : central et la branche "beta/release". Et beta/release était fusionné avec central à interval régulier. Ce qui provoquait des "freezes" de central, c'est à dire des periodes pendant lesquels on ne pouvait commiter que des corrections ou des nouvelles fonctionnalités "bloquantes", correspondantes à la roadmap.
Avant le dev de Firefox 4, il y avait encore un autre processus de dev un peu différent avec des freezes plus contraignants encore (la branche beta/release était en fait crée seulement peu de temps avant la release).
Et donc maintenant, dans le central, il n'y a plus de freeze. On peut commiter toutes les corrections et fonctionnalités que l'on veut (enfin, qui sont reviewés). Cela veut dire que c'est la fête tout les jours pour ceux qui suivent les nightly. Les testeurs des nightlies "central" ont des nouveautés tout les jours ou toutes les semaines. miam !
En résumé : la roadmap de développement de Firefox n'est plus orienté "features", mais c'est en quelques sortes du "rolling release". Une version ne sort plus "quand une feature est prête", mais à date fixe, toutes les douzes semaines (qui correspond à la période de stabilisation).
# En comparaison avec l'ipad
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Asus EEE transformer. Évalué à 6.
Possesseurs d'un Ipad, rassurez-vous, vous pouvez vous aussi attacher un clavier, pour pas cher en plus. C'est juste un peu moins beau.
[^] # Re: FF4 et lenteur audémarrage
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal un mois avec Chrome. Évalué à 9.
C'est très pratique pour poster avec ses multis.
[^] # Re: pourquoi la MPL ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla Public License Beta 2. Évalué à 5.
Elle l'utilise : tous les fichiers sources produits par Mozilla et ses contributeurs, sont explicitement sous les trois licences, MPL, GPL, LGPL. À toi de choisir celle qui te convient.
Exemple tout à fait pris au hasard parmi ce qui m'est venu en tête http://mxr.mozilla.org/mozilla2.0/source/content/base/src/nsXHTMLContentSerializer.cpp
[^] # Re: android ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 4 pour Android et Maemo est sorti. Évalué à 4.
Si tu as si peur pour tes données personnelles, la première chose à faire, c'est de ne pas les confier à un quelconque nuage. point barre. (du bons sens quoi). Quant à être parano, autant être parano jusqu'au bout.
Et donc les paranos, ils installent leur propre serveur sync. Ça fonctionne très bien aussi.
Mais il n'y a pas de raison de faire du FUD comme ça envers la MoFo (et d'être parano), tout ce que tu stockes chez eux est chiffré avec une clé que seul toi possède (même quand ça stocke sur ton propre serveur).
Et si Sync ne fonctionnait vraiment pas, ça se saurait, depuis presque 3 ans que ça existe (sous forme d'extension avant Firefox 4). Tu as à priori un problème dans l'utilisation de Sync, ça ne veut pas dire que ça ne fonctionne pas en temps normal.
[^] # Re: Journal—Firefox 4 pour Android et Maemo est sorti
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 4 pour Android et Maemo est sorti. Évalué à 2.
la version android repose sur le même code que la version desktop, à savoir le moteur Gecko 2.0 (C++).
Ainsi toutes les amélioratoins en terme de perf, et toutes les nouveautés technologiques (html5, CSS3, SVG, SMIL et cie) que vous avez dans Firefox 4 pour desktop, vous les avez dans la version mobile.
Grosso modo, il n'y a que l'interface qui change.
[^] # Re: 64 bits ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 4 est sorti. Évalué à 2.
Ah ? ftp.mozilla.org + tar xjf, c'est compliqué ?
[^] # Re: Les formulaires JTML5 sont maintenant pris en charge
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 4 est sorti. Évalué à 3.
sans compter les pseudos classes CSS3 :valid et :invalid pour styler les champs input valides/invalides.
[^] # Re: 64 bits ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 4 est sorti. Évalué à 2.
Les dev chez Mozilla bossent sur TOUTES les plateformes, et pour cause, une bonne partie du code est indépendant de la plateforme. De plus, il y a des dizaines de machines qui lancent les tests unitaires sur toutes les plateformes.
Maintenant, pour te donner des chiffres sur le nombre de testeurs, je ne pense pas qu'on en ait : ce sont en grande majorité des bénévoles. L'équipe QA de Mozilla n'est qu'une goutte d'eau parmi tout les testeurs.
Les testeurs donc, c'est toi, moi etc.. Et il se trouve que la majorité de rapport de bugs ont été découvert par des utilisateurs sous windows. Donc que la majorité des testeurs sont sous windows.
Il nous manque clairement donc des utilisateurs linux pour tester.
[^] # Re: fan de la première heure
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 4 est sorti. Évalué à 3.
Le vrai problème aurait été de garder l'ancienne interface. À la vue du succès des interfaces "light" avec les autres navigateurs, on ne pouvait que suivre dans cette direction. Et plus c'est minimaliste, plus il est difficile de se différencier.
Là où on peut se différencier, ce sont dans les interfaces et fonctionnalités annexes, l'agencement des éléments d'interface et c'est ce qu'essaye de faire Mozilla. D'ailleurs, je trouve que Fx4 s'intègre bien mieux dans Gnome que Chromium (qui a une barre de titre horrible par exemple, ne reprenant pas le thème gtk)