Parce qu'on parle beaucoup de chrome en ce moment, je me suis dit que ce serait une bonne idée de vous faire une simple liste des trucs sur lesquels on (Mozilla) bosse en ce moment:
* release majeure tous les 6 mois (ce n'est pas évident, mais on va essayer)
* 3.6 qui débarque avec support de la File API, du lourd: http://www.w3.org/TR/FileAPI/ , un tracemonkey plus rapide et des grosses améliorations CSS 3. Niveau UX, Personnas intégré (nouveau gestionnaire de theme)
* 3.7 ensuite très orienté graphisme (SMILE, SVG animations, CSS Transitions, WebGL - mais on en chie sous Linux avec la 3D, ...)
* 4.0 avec une nouvelle UX, truc beaucoup plus clean et moins "à la Netscape 2.0" et plus "à la Chrome simpliste", mais pas trop :)
* MozMessenging: Thunderbird 3 avec un paquet de trucs
* MozMessenging: Raindrop (https://wiki.mozilla.org/Raindrop )
* startup plus rapide (http://autonome.wordpress.com/tag/startup/ )
* jetpack, aka Extensions 2.0 - on va essayer de l'intégrer à Firefox directement
* Electrolysis (multi-process, aujourd'hui ça fonctionne bien pour les plugins. Bientôt, plus de crashs à cause de Flash)
* Parser HTML5
* Fennec (Firefox pour mobiles, on va bientôt releaser pour le n810 et le n900, on bosse aussi sur une version Android)
* Weave, qui va permetre de tout synchroniser (Fennec, Firefox au bureau, Firefox au travail)
* Identité dans le browser (http://blog.mozilla.com/about_mozilla/#identity )
* beaucoup d'énergie dans Firebug
* des trucs spécifiques à Windows (Direct 2D rendering)
... plein d'autres trucs que j'oublie (surtout pour l'UI/UX).
Tous ces projets sont en cours de développement, releasé ou pas, mais très actifs.
À propos de TB3, on est loin de le laisser de côté, mais oui, il y a moins de ressources pour Thunderbird que pour Firefox. Mais on a quand une grosse équipe qui bosse dessus (plus importante et plus structurée qu'à l'époque de TB2).
N'hésitez pas si vous avez des questions, mais évitons les trolls :)
Journal Des news de Firefox
9
déc.
2009
# Ca tombe à pic...
Posté par Graveen . Évalué à 6.
Et je pense qu'il faudrait le faire savoir "à la google".
Mais difficile d'être présent sur tous les tableaux. Allez, j' vais aller faire un don ! :D
# Coool
Posté par eMerzh (site web personnel) . Évalué à 3.
C'est sûr que la concurrence chère à Mozilla est rude ces derniers temps ... et c'est tant mieux!
Vivement la mort de ie 6 d'abords et 7-8 ensuite :)
Un truc qui me manque comme dev web c'est la possibilité de sélectionner plusieurs fichier dans un input file avec multiple (htm5 inside)... j'espère que on verra apparaître cette fonctionnalité dans la 3.6
[^] # Re: Coool
Posté par Paul Rouget . Évalué à 8.
Suivez http://hacks.mozilla.org , on en parle cette semaine.
# Une question bête...
Posté par Bruno Michel (site web personnel) . Évalué à 7.
Sinon, chapeau à l'équipe Mozilla pour tout le travail accompli.
[^] # Re: Une question bête...
Posté par Paul Rouget . Évalué à 6.
On y pense très très fort :) ... mais il se trouve que le code pour la rédaction d'un message est particulièrement compliqué (et ça c'est pas normal) et que c'est pas évident à coller dans un onglet, mais on y travaille.
# à la bourre
Posté par NeoX . Évalué à 5.
* MozMessenging: Thunderbird 3 avec un paquet de trucsil me semble qu'il est sorti hier ;)
bon sinon, j'adore ce que vous (Mozilla) faites ;)
[^] # Re: à la bourre
Posté par Paul Rouget . Évalué à 7.
"Tous ces projets sont en cours de développement, releasés ou pas, mais très actifs."
:)
# La troidé sous X.Org
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Faire de la troidé sous {X.Org|MacOS|Windows}, ça ne se résume pas à utiliser l'API OpenGL et puis voilà ?
[^] # Re: La troidé sous X.Org
Posté par nicko . Évalué à 1.
[^] # Re: La troidé sous X.Org
Posté par ʭ ☯ . Évalué à 3.
Donc, il faut juste utiliser ce qui marche partout, sous peine de voir tout le monde quitter Firefox parce que ça rame sous Linux avec des pilotes libres....
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: La troidé sous X.Org
Posté par Paul Rouget . Évalué à 4.
Faire fonctionner WebGL avec une carte ATI ou Intel, c'est la misère.
Mais on utilise OpenGL, mais avec les différentes versions et les extensions, galères...
[^] # Re: La troidé sous X.Org
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 5.
Je sais c'est pas trop à la mode, y'a pas buzz dedans, ça bouge pas dans tous les sens, donc dans la presse ça le fait moins...
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: La troidé sous X.Org
Posté par Paul Rouget . Évalué à 5.
[^] # Re: La troidé sous X.Org
Posté par cetcheve . Évalué à 2.
« Mediocrity finds safety in standardization. »
-- Frederick Crane
[^] # Re: La troidé sous X.Org
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
Pourtant pour "remplacer Flash" comme le dis Laurent, SVG c'est déjà une étape un peu plus utile que la 3D. Je parle même pas de SMIL qui va peut-être bientôt être implémenté dans FF 3.7. Une spéc qui a 8 ans, comme SVG... Et y'a encore beaucoup de boulot pour rattraper le reste du monde : http://www.codedread.com/svg-support.php
Donc oui pour le moment repousser l'implémentation de nouveaux trucs buzz/hype ça peut être pas mal, pour avoir déjà un support correct des standards existants. Ah c'est sûr ça permet pas de faire des trucs qui clignotent et bougent dans tous les sens (démo à paris web), mais ça, c'est *vraiment* beaucoup "demandé" comme le dis Laurent.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: La troidé sous X.Org
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
Et sinon, je ne sais pas si tu te rend compte de certaines choses aussi : compare par exemple la spec de SVG/SMIL, avec la spec openGL. Implémenter SVG, c'est un véritable braquage en terme de ressources humaines, tellement la spec est un pavés de plusieurs centaines de pages. Implémenter la 3D dans canvas ? c'est rien à coté de SVG, vu que des libs qui implémentant openGL existent déjà. Coté intégration donc, y "juste" à faire du mapping js <--> lib openGL, surtout qu'il ne s'agit ici que de dessiner dans une surface limité (canvas), avec aucune interaction avec le reste du document (par ex, pas de reflow sur le rendu HTML quand on dessine dans Canvas, ce qui n'est pas le cas quand il s'agit d'intégrer/modifier des bouts de svg dans le document) .
Implémenter SVG, ce n'est pas que faire appel à des primitives graphiques 2D, mais il y a aussi à implémenter son DOM, ses propriétés CSS spécifiques, son moteur de rendu, sans compter tout ce qui est timeline/synchronisme pour SMIL, et j'en passe.
Bref, comparons ce qui est comparable en terme d'implémentation. On n'est pas du tout dans la même échelle.
[^] # Re: La troidé sous X.Org
Posté par Paul Rouget . Évalué à 8.
Oui, mais ça c'est normal. C'est une question de choix, et pas un problème technique.
Le truc c'est: "SVG, est-ce un document ou une image?". On est pas encore certain que ce soit une bonne idée de mettre un "document" en background.
Mais a priori, on va tout de même le permettre (je ne sais pas pour quand).
Mais bon, tu ne comprends pas qu'on peut avancer en parallèle sur différentes technos.
On ne peut pas par example mettre l'équipe jetpack ou Fennec sur SVG.
Et *tes* priorités ne sont peut être pas celles de tout le monde.
On innove (oui, ça fait du buzz). On avance aussi sur les standards bien établis (on en parle moins probablement).
Mais bon, on ne peut satisfaire tout le monde.
[^] # Re: La troidé sous X.Org
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Peut être que tu ne vois pas l'intérêt de pouvoir utiliser openGL dans une page web, mais beaucoup le demande. Ce n'est pas pour faire du buzz. C'est vraiment pour répondre à un *besoin* : les jeux, les contenus éducatifs (pouvoir par exemple visualiser une molécule sous toute ses coutures), les contenus informatifs. ex: un site immobilier permettant de visiter les futurs appartements en 3D, ou encore la visualisation d'une collision dans un accélérateur de particules, etc.
Ce n'est pas parce que tu trouves tout ça inutile, que c'est le cas du reste du monde. L'information, ce n'est pas que du plat, du static. c'est aussi de l'interaction.
Il y a un autre avantage à implémenter des trucs "qui bouge dans tout les sens", c'est que petit à petit, ça nous permet de virer flash et consort. Et ce n'est pas rien.
Si tu veux utiliser un brouteur qui ne fais afficher que du HTML à papa, installe Mosaic.
[^] # Re: La troidé sous X.Org
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Là, y mettre de la troidé, je trouve que ça a du sens, dans des pages Web. Mais faire des jeux vidéos, non. Faire de la messagerie instantanée, non plus, par exemple.
[^] # Re: La troidé sous X.Org
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
> Ça répond à une volonté, stupide, d'utiliser le Web pour tout, or Internet n'est pas le Web.
Pour visualiser de la 3D sur internet, il faudrait quoi alors ? un programme à coté ? super pratique pour illustrer un document... web.
Pour lire une video, il faudrait quoi ? un programme externe ? super pratique là encore pour illustrer un document, et surtout ça donne l'impossibilité à la page web de l'intégrer dans le document, de mixer correctement la vidéo avec le reste du contenu. (ce qu'on peut faire avec la balise video et CSS/JS est tout simplement impossible avec un plugin ou l'utilisation d'un programme externe, cf demos de paul rouget)
>Mais faire des jeux vidéos, non.
et pourquoi pas ?
Très franchement, quels sont les raisons à ne pas vouloir faire en sorte qu'on puisse utiliser une plateforme commune pour jouer, lire, ou faire certaines tâches ?
Pourquoi avoir inventer javascript alors ? Pourtant il rend bien des services. Comme celui de pouvoir developper des wbemails, que certains cherissent tant et qui se demandent pourquoi les clients lourds mails existent encore.
C'est bien parce que ça rend service à une partie des utilisateurs. Qu'ils ont *besoin* de ce service.
Et bien voilà, le web evolue, parce que les besoins evoluent. les utilisations des technos changent. la manière d'utiliser internet change. Il faut donc proposer des outils, des technos, pour que cette utilisation soit plus simple, et surtout qu'il soit plus simple à développer les applications qui sont nécessaires à ces besoins.
>Faire de la messagerie instantanée, non plus, par exemple.
qui a parlé de messagerie instantanée ?
[^] # Re: La troidé sous X.Org
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: La troidé sous X.Org
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
Quelle balise??? (je ne connais pas l'histoire)
[^] # Re: La troidé sous X.Org
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: La troidé sous X.Org
Posté par CrEv (site web personnel) . Évalué à -4.
juste parce que la balise ça doit faire un moment quand même qu'elle est intégrée, on peut ptetre passer à un autre argument non ? ;)
[^] # Re: La troidé sous X.Org
Posté par tape . Évalué à 4.
http://la-grange.net/2005/05/27
[^] # Re: La troidé sous X.Org
Posté par fredoche . Évalué à 3.
En fait, maintenant que java est libre, on pourrait envisager de programmer les contenus 3d de façon à utiliser le java-browser-plugin, et ainsi économiser le temps qu'il faudrait pour développer une api équivalente dans le browser, un interpréteur JS JIT et reporter toutes les contraintes de cross-platform à l'implémentation de la JVM...
Après ça résout pas le probleme de la communication entre les divers composants: la balise video est facilement manipulable en js, ce qui, je crois, est pas le cas de la balise embed, mais je trouve ça dommage que les plugins soient passés de mode.
[^] # Re: La troidé sous X.Org
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
D'oh ! C'est vrai que la 3D sur le web c'est l'avenir, y'a qu'à voir le succès immense de VRML ou SCOL... 15 ans plus tard y'en a sur tous les sites web... Ah tiens non, c'est bizarre.
« Peut être que tu ne vois pas l'intérêt de pouvoir conduire avec 10g d'alcool dans le sang, mais beaucoup le demandent. »
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: La troidé sous X.Org
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
C'est pas utilisé parce que :
1) ce n'est pas implémenté par les navigateurs (ils avaient d'autres choses plus "basiques" à implementer)
2) c'était peut-être des technos à chier, trop compliquées à utiliser, ou encore pas assez riche (c'est une hypothèse, je ne les connais pas), et surtout étrangère à ceux qui font de la 3D.
3) peut être aussi un problème de puissance des machines. à l'epoque de VRML, la plupart des machines vendues n'avaient pas de carte 3D -> performances inadéquates pour faire de la 3D. alors que maintenant, toutes machines comportent une puce pour faire de la 3D.
3) il y avait d'autres chats à fouetter, le web dans son ensemble n'était peut être pas assez mature (faut voir le temps que ça a mis pour que les dev utilisent javascript correctement)
alors que bon, tout bon programmeur 3D connait openGL, ou en tout cas les principes fondamentaux de la 3D sur lesquels reposent openGL. Ils auront alors beaucoup moins de mal à "s'exprimer" sur le web qu'avec des technos underground comme VRML.
Ce n'est pas parce que un truc n'a pas marché il y a quelques années, que ça ne marchera pas maintenant, avec les évolutions technologiques tant matériels que logiciels qu'il y a eu.
[^] # Re: La troidé sous X.Org
Posté par Octabrain . Évalué à 2.
OpenGL est très bas niveau. Si l'on doit se contenter d'OpenGL pour faire de la 3D, ça va vite devenir super chiant, et j'ai du mal à imaginer ce que donneraient des libs comme Ogre portés en javascript...
[^] # Re: La troidé sous X.Org
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Intel est lent je veux bien le croire mais il me semblait que leur implémentation d'opengl était correct.
"La première sécurité est la liberté"
[^] # Re: La troidé sous X.Org
Posté par Grunt . Évalué à 2.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Démarrage du navigateur
Posté par Thomas . Évalué à 2.
Une question que j'ai vu souvent sur d'autres sites et qui n'est pas si conne : pourquoi une UI différent pour la version 3.7 et 4.0 ? Autant directement faire celle pour la 4.0.
Une question que je pose pour d'autres car je m'en fou j'ai un Mac :
Pourquoi les temps de démarrage sous Linux et Windows ont autant de mal à être améliorés ? cf. les derniers chiffres :
Summary, relative to Firefox 3.5:* Warm startup: For Mac, 36% better on 3.6 and 35% better on 3.7. For Windows, 5% and 5%. Flat on Linux.
* Cold startup: For Mac, 20% better on both 3.6 and 3.7. For Windows, not measuring yet. For Linux, we're seeing a regression of ~9% across branch and trunk in the snapshot but not on the graphs, so we need to figure out where the discrepancy is.
[^] # Re: Démarrage du navigateur
Posté par Paul Rouget . Évalué à 2.
Pour le startup, je ne sais pas.
[^] # Re: Démarrage du navigateur
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 1.
En tout cas, vue la roadmap, bon courage. Vous avez l'air de vous attaquer à tous les défauts de la bête... sympa de voir un projet vivant comme celui ci.
# Raindrops
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Bon. Raindrop, si j'ai bien compris, c'est une collection de parseurs pour afficher directement dans une lettre électronique des contenus tirés de services Web centralisés. Donc, ça va vers le tout Web, une belle connerie à mes yeux, et vers du bon vieux Minitel.
En attendant, on a aussi le messagerie instantanée, dans le genre truc intéressant qui aurait sa place dans un logiciel de messagerie. Jabber, ça n'intéresse pas Mozilla parce que ce n'est pas Web ?
[^] # Re: Raindrops
Posté par Paul Rouget . Évalué à 2.
L'idée est d'avoir un moteur de traitement et d'aggrégations de messages qui pourra être requeté à travers une UI XUL (Thunderbird 4) ou via une page web.
Le moteur pourra se trouver coté web, mais rester aussi sur le desktop.
[^] # Re: Raindrops
Posté par Tristan Nitot (site web personnel) . Évalué à 6.
Pas vraiment, dans ce sens que c'est surtout un genre de Webmail sous stéroides, qui trie tes messages pour toi (genre les notifications qu'on reçoit par mail, il te les affiche d'une façon différente de messages qui te sont envoyés par ton patron).
Surtout c'est un framework qui va te permettre de rajouter des modules pour interfacer plusieurs protocoles en plus de ceux du mail.
Mais c'est bien une application Web, oui.
Donc, ça va vers le tout Web, une belle connerie à mes yeux, et vers du bon vieux Minitel.
C'est vrai que le tout-Web peut aller vers le Minitel 2.0, mais ça dépend qui le fait et comment. Si c'est une application Web propriétaire qui tourne uniquement sur des serveurs qui sont tous contrôlés par la même boite, et sans possibilité d'exporter tes données, pas de doute, c'est bien du Minitel 2.0.
Par contre, si c'est du logiciel Libre que tu peux télécharger, installer sur ton propre serveur voire même ton propre ordi perso, qui est foncièrement extensible, et que tu peux transporter tes données d'une instance à l'autre, alors t'as tous les avantages du Webmail (et bien plus, dont la messagerie instantanée) en plus de la liberté. `
Si ces conditions sont réunies, alors nous sommes bien loin du Minitel 2.0 !
En attendant, on a aussi le messagerie instantanée, dans le genre truc intéressant qui aurait sa place dans un logiciel de messagerie. Jabber, ça n'intéresse pas Mozilla parce que ce n'est pas Web ?
J'espère bien qu'il y aura un module Jabber dans Raindrop. Tu te portes volontaire ? ;-)
[^] # Re: Raindrops
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -3.
Merci de le préciser. Les pages qui en parlent sur le sites de Mozilla sont tellement peu claires que je ne l'avais pas compris. Pour moi, c'était simplement un logiciel de messagerie intégrant une collection de parseurs hétéroclites pour afficher des informations provenant de services propriétaires massivement centralisés.
Donc en fait, c'est un webmail avec une collection de parseurs. Mozilla réfléchit à un nouveau logiciel , et c'est un webmail. La claque… Je savais déjà que Mozilla poussait le Web à tout prix, pour faire n'importe quoi, mais à ce point, quand même…
# Et XMPP ?
Posté par Nÿco (site web personnel) . Évalué à 10.
Merci pour ce rapide néanmoins complet journal...
Mais... m... mais... y'a toujours pas de XMPP dans la roadmap de la Fondation Mozilla ?
Comment faut-il l'expliquer ? Vous avez fait Weave à partir de zéro, vous avez réinventé la roue, vous avez mis du temps, et derrière il faut encore installer un plugin et un serveur, même si ce dernier est libre... Alors qu'avec XMPP, un user n'a qu'à installer un plugin et utiliser son compte XMPP... C'est pas sorcier pourtant, on a développé OneWeb en 5 jours seulement (et on va peut-être le porter sur mobile sur Fennec sous Maemo).
http://www.pcinpact.com/actu/news/54352-processone-oneweb-xm(...)
http://www.generation-nt.com/firefox-oneweb-xmpp-messagerie-(...)
http://www.process-one.net/en/blogs/article/oneweb_demonstra(...)
La grosse étape suivant le Web 2.0 est sans aucun doute le web temps-réel (ou « real-time web »). De nombreux hacks plus ou moins moches sont tentés sans trop de succès comme PubSubHubbub, SUP, APE, Comet, SPDY, toussa... Alors que XMPP et BOSH offrent tout cela nativement. Il est donc possible et facile d'offrir le push dans le brouteur, via simple ECMAscript ou via un éventuel plugin/extension, le mieux étant que le brouteur lui-même tchatche le XMPP nativement, ainsi les développeurs d'extensions pourront en bénéficier pour enlarger leur hackability/bidouillabilité.
Idem, XMPP comme backend sur les serveurs web, ça peut offrir la communication inter-serveur ou S2S (« server-to-server »), l'authent, le multi-party, le multimédia avec traversement des NAT, des vCard et avatars, du publish-and-subscribe (aka « PubSub »), du stockage d'infos privées ou publiques tels que les bookmarks (voir OneWeb), du contrôle à distance (voir OneWeb), de la présence et de la présence étendue, etc. J'en passe !
Franchement, là je ne vois pas pq Mozilla ne veut pas voir XMPP. Google a déjà pas mal compris, Apple n'a pas encore fait complètement le lien, bien qu'iChat Server soit un serveur XMPP et sur le Push de l'iPhone soit du XMPP...
[^] # Re: Et XMPP ?
Posté par Paul Rouget . Évalué à 3.
On n'a pas le temps de tout faire non plus :)
Mais clairement, je trouve aussi que ça a un sens d'intégrer XMPP, mais il y a des priorités (animations, identité, performances, sécurité, mechanisme d'extensions plus simples, ...).
Il faut aussi définir comment XMPP intervient dans un browser et/ou dans le web (sens "page webs").
[^] # Re: Et XMPP ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -2.
[^] # Re: Et XMPP ?
Posté par Yakulu . Évalué à 2.
xmpp4moz ( https://addons.mozilla.org/fr/firefox/addon/3632 ), base du client SamePlace ( https://addons.mozilla.org/en-US/firefox/addon/3633 )
[^] # Re: Et XMPP ?
Posté par Nÿco (site web personnel) . Évalué à 3.
Ce n'est pas sujet, et je ne fait que tenter de le promouvoir.
> On n'a pas le temps de tout faire non plus :)
Oui, bah t'as vu la liste énorme que tu nous balances ? Faires des (bons) choix, c'est important et difficile, c'est pour cela qu'il faut chercher de l'aide là où elle se trouve.
Je pense que XMPP devrait être une des priorités pour Mozilla, car vous êtes les défenseurs du « open internet ».
> Il faut aussi définir comment XMPP intervient dans un browser et/ou dans le web (sens "page webs").
Et pourquoi pas laisser faire l'écosystème ? Foutez une pile XMPP avec des zoulies API dans Gecko, parlez-en un peu, et voilà... Non ? Vous avez pourtant l'habitude de laisser expérimenter avec les extensions et les labs, non ?
Effectivement, comme dit le dit Fabien, il y a xmpp4moz, mais il y a aussi JSJaC ou encore Strophe, bref tout plein de choix.
[^] # Re: Et XMPP ?
Posté par Paul Rouget . Évalué à 1.
Après, XMPP, tu peux l'intégrer à travers une extension. Ça ne te convient pas?
Bon, a priori, tu restes persuadé qu'on doit faire à ta manière, et que sans XMPP, on fait une grosse erreur. Ouvre un bug, écrit ton API et écrit le code!
Juste dire "integre l'API XMPP", t'es malin, tu te rends compte du boulot?
Désolé, XMPP n'est pas assez prioritaire, il faut que tu le comprennes. Fais un patch ou va voire l'équipe Thunderbird avec un concept ou bosse avec l'équipe Weave ou envoie une description du projet aux Concept Series, mais arrête de nous dire ce qu'on doit faire.
[^] # Re: Et XMPP ?
Posté par Littleboy . Évalué à 2.
Sinon, si il n'y a pas de contributeurs interesses, ca devrait t'indiquer que peut-etre il n'y a pas tant de demande que ca.
Mais si tu penses que c'est l'avenir, rien ne t'empeche de contribuer. Ca ne devrait pas te prendre plus de 5 jours pour integrer tout ca. N'oublie pas de nous donner l'url de l'entree dans bugzilla, qu'on puisse tester tout ca.
# bravo ...
Posté par manatlan (site web personnel) . Évalué à 10.
Il faudrait surtout, au minimum, rendre la version linux au moins aussi véloce que la version windows.
Comment expliquer qu'un firefox/win32 est bien plus rapide dans une VM Virtualbox sous linux, que la version native firefox/linux ?!?
Il y a un truc qui ne va pas ...
[^] # Re: bravo ...
Posté par Paul Rouget . Évalué à 4.
Je ne m'y connais pas assez, mais je sais que les devs galères à faire une version Linux rapide sous Linux, et ce n'est pas 100% de notre faute (Gcc, la couche graphique Linux, systeme de fichier, ...), mais un peu quand même :)
[^] # Re: bravo ...
Posté par manatlan (site web personnel) . Évalué à 2.
Mais force est de constater qu'il y a maintenant, au moins, un navigateur qui n'a rien à envier à son pendant windows, bien au contraire (aka "chrome/chromium")
Disons, qu'elles sont, maintenant, juste un peu moins crédibles, vu que google y arrive (et ce n'est pas leur coeur de métier) ...
Ils sont peut être très fort (ça j'en doute pas). Mais vu les tournures que prends tout ça ... je pense sincèrement que "firefox va se faire bouffer grave". Les versions gpl et dégoogelisée de chrome vont prendre l'ascendant haut la main.
Le produit est bon, voir très bon ... la synchro et les extensions sont là (y développer une extension y est simplissime en comparaison) ... maintenant on va voir très vite arrivé html5, webgl, nacl et cie dans le core ... ils vont leader l'innovation (ils le font déjà dans certain domaine : js) ...
Moi ça fait 6 mois que je tourne avec les dev builds de chromium ... et je vois bien la vitesse d'avancement : c'est fulgurant ... et à cette vitesse là, comme dit, ils vont tout leader sous peu.
[^] # Re: bravo ...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
bof
>Les versions gpl et dégoogelisée de chrome vont prendre l'ascendant haut la main.
rebof
> la synchro
la synchro de quoi ?
> et les extensions sont là (y développer une extension y est simplissime en comparaison)
pareil chez Mozilla. cf jetpack.
>maintenant on va voir très vite arrivé html5, webgl, nacl et cie dans le core
comme chez Mozilla. qui n'a absolument rien à envier à chrome de ce coté là. Tout ce qui est implémenté dans chrome/webkit l'est déjà dans Mozilla ou en passe de l'être, et vice versa.
> ls vont leader l'innovation (ils le font déjà dans certain domaine : js)
js ? tracemonkey est aussi rapide voir plus rapide que V8. En tout cas, c'est kiff kiff. donc bon, pas la peine de se branler la nouille là dessus.
[^] # Re: bravo ...
Posté par Nÿco (site web personnel) . Évalué à 2.
> la synchro de quoi ?
Des données, sur XMPP, que Mozilla réinvente avec Weave.
[^] # Re: bravo ...
Posté par manatlan (site web personnel) . Évalué à 3.
Je ne doute pas un seul instant, qu'ils n'aient pas les moyens de synchroniser tout ça. La base est là, et xmpp est dans la place. C'est uniquement politique !
Laurent, (on a déjà eu de grav'discut dans le passée ;-) ...
jetpack ou pas jetpack ... firefox est "lent" sous notre plateforme. On n'est pas à la sur-enchère de technos ... On a beau être des geeks ... on n'en est pas moins des utilisateurs d'internet ...
que mon navigateur fasse du webgl, du nacl ou du html5 : comme tu dis, on s'en b....
On veut juste pouvoir naviguer dans des conditions correctes, en utilisant les technos utiles/utilisées sur les sites qu'on visite.
il vaut être pragmatique !
"kif-kif" pour les moteurs js ?!?... l'émulateur NES en JS (et je sais bien que ce n'est pas non plus un benchmark) tourne infiniment (100x) plus rapidement sous chrome que sous ffox.
Je suis pragmatique, et bien conscient qu'il en est de même sur les sites abusant de js : gwave et cie ...
Ce n'est peut être qu'une sensation alors ?! mais elle est là !
Ce que je dis, c'est que chrome est une excellente base pour le futur ... pour un 1er navigateur (certes v4, mais ça veut rien dire niveau version): c'est déjà bluffant.
En gros, ils ont les hanches pour faire monter en puissance leur truc ... Ce que je ne peux pas dire de ffox (aka problème de base : certainement lié aux technos xbl/xul/xpcom).
Ils sont arrivés "au niveau" de firefox en un an ... ils vont pouvoir maintenant innover (et leader l'innovation)...
et mon petit doigt me dit, qu'ils seront, ET DE LOIN, les premiers à couvrir html5 (entre autres, pour remplacer gears, qui est une brique importante de l' "os chrome" pour l'offline) ...
Ils en ont la capacité, ils en ont la volonté ... et avec l'os chrome dans 6 mois : ils vont mettre les bouchées doubles.
C'est triste qqpart pour mozilla... mais pour l'utilisateur, c'est bien. Ils ont aussi, à mon sens, un truc que mozilla n'a pas : faire plaisir à l'utilisateur final (et ça ne passe pas forcément par l'innovation (et la sur-enchère de technos))
[^] # Re: bravo ...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
ouai enfin non, on s'en fout pas, enfin moi non. Parce que je veux que n'importe quel site puisse fonctionner correctement, surtout si il n'utilise que des standards (ou futur standards). Pour un utilisateur, surtout si il n'y connait que pouik en techno, un site qui ne fonctionne pas, c'est un site sur lequel il ne reviendra pas. Et si il tombe sur trop de site qui ne fonctionnent pas, il passe à un autre navigateur (si c'est un utilisateur un peu avancé).
>il vaut être pragmatique !
je pense que Mozilla est très pragmatique. Tiens, une preuve : acid3. ils sont pas à 100% parce qu'ils estiment qu'il y a des choses qui méritent plus d'attention, que le support des fontes SVG (les derniers points à gagner sur acid3 concernent ce support principalement). Et ils ont préférés par ex travailler sur le nouveau format WOFF (http://hacks.mozilla.org/2009/10/woff/ ), qui est un meilleur compromis entre les développeurs et les fondeurs.
>l'émulateur NES en JS (et je sais bien que ce n'est pas non plus un benchmark) tourne infiniment (100x) plus rapidement sous chrome que sous ffox.
La majorité des bottlenecks, que ce soit pour cet émulateur ou les gros sites avec plein de DHTML de partout, ce n'est pas la faute au moteur JS, tracemonkey, mais la faute à notre couche de communication DOM <-> JS.
Dans l'exécution d'une page web, il y a pleins de trucs qui entre en action, comme c'est expliqué sur http://blogs.msdn.com/ie/archive/2009/11/18/an-early-look-at(...) , faut donc pas mettre toutes les fautes sur le moteur JS.
>Ils sont arrivés "au niveau" de firefox en un an
ils n'ont, et n'auront jamais une extensibilité aussi forte que ce que permet Firefox. Ils sont au niveau en terme de navigation et visite des pages. Maintenant Chrome est loin d'être une plateforme de dev comme l'est Firefox. Faut bien voir ça. Firefox n'est pas qu'un moteur de rendu de page web. Chrome si (avec quelques boutons autour). Peut être que tu t'en fiches, que tu veux qu'un simple browser, mais Firefox n'en serait pas là où il est si il n'avait pas cette formidable extensibilité. Il (ou plutôt XulRunner, sur lequel est bati Firefox) a servi de base à plein d'appli.
>qu'ils seront, ET DE LOIN, les premiers à couvrir html5 (entre autres, pour remplacer gears, qui est une brique importante de l' "os chrome" pour l'offline) ...
euh, tout ce que fait gear, Firefox le fait depuis des lustres il me semble. Faut arreter un peu. En matière de support HTML5, chrome n'est pas si en avance, et Firefox ne prend en rien du retard. Et puis il n'y a pas que HTML5, mais aussi XBL2, et d'autres technos sur lesquels Chrome a encore du retard (à quand une implem XForms par ex, ou MathML).
>Ils ont aussi, à mon sens, un truc que mozilla n'a pas : faire plaisir à l'utilisateur final
ça c'est ton avis propre. Ce n'est pas l'avis des 330 millions d'utilisateurs de Firefox. Et aux dernières nouvelles, la progression de Chrome n'est pas si fantastique que ça, en terme de part de marché (surtout que Firefox continue à bien progresser aussi sur ce sujet). Il va falloir beaucoup de temps, à mon avis, avant que Chrome ne parviennent à rattraper Firefox.
Enfin bon, on verra...
[^] # Re: bravo ...
Posté par manatlan (site web personnel) . Évalué à 1.
> ce que permet Firefox. Ils sont au niveau en terme de
> navigation et visite des pages. Maintenant Chrome est loin
> d'être une plateforme de dev comme l'est Firefox. Faut bien
> voir ça. Firefox n'est pas qu'un moteur de rendu de page web.
Je ne dis pas le contraire, je sais très bien les différences entre les 2 plateformes ...
J'étais un early adopter des technos mozilla, et utilisateur(et evangeliste) de phoenix/firebird/firefox ...
Les technos derrière ffox : xbl/xpcom/xul sont très biens ...
Mais madame michu, ou même moi, s'en fiche du côté "plateforme de dev", ou extensibilité extrème du navigateur...
(cependant, pour la grosse majorité des extensions utiles/efficaces de ffox : je ne vois pas ce qui ne pourrait pas être fait dans chrome/chromium ... pour parler "extensibilité")
Donc, pour l'utilisateur final : kif kif.
Ce que je dis, c'est que c'est quand même incroyable le niveau de maturité qu'à atteint leur navigateur en 1an. (tout en restant très véloce).
Et qu'ils ont ainsi une (très) bonne base pour innover (maintenant que le plus gros est derrière).
> euh, tout ce que fait gear, Firefox le fait depuis des lustres
> il me semble
oui, et pour cause : c'est eux qui l'ont fait ... ils n'avaient pas encore de navigateur ;-)
Je ne sais pas si tu as testé "chrome os", mais il manque toute la brique offline, pour que le concept puisse prendre (et je n'ai aucun doute).
Et c'est pour ça, à mon sens, qu'ils vont se dépêcher d'implémenter les morceaux html5 nécessaire pour l'offline. (vu que gear est officiellement abandonné now) ...
quant à la progression de chrome ... l'os chrome sur netbook risque quand même de prendre ;-) ...
j'ai installé "os chrome" sur mes eee pc ... c'est clairement le temps minimum entre l'allumage de la machine et la présence web ... avec le plaisir de partager ses bookmarks entre les eeepc ... mon chromium/desktop et mon chromium@boulot ...
(pour l'anecdote, le lancement de firefox dans un jolicloud sur un eee 701 4g, prends autant de temps que le boot du 701 pour se retrouver sous chrome online... ça laisse rêveur)
Ce que je veux juste dire, c'est qu'ils ont un truc rapide/efficace et déjà pas mal ... maintenant, ils ont la liberté de pouvoir innover, et ils vont le faire très rapidement à mon avis.
Pour ne pas renier totalement mes anciens amours, j'utilise encore firefox, uniquement pour firebug, et les devs webs (quand je suis sous windows, car sous linux : c'est inutilisable sur ma machine) ...
[^] # Re: bravo ...
Posté par Littleboy . Évalué à 1.
rebof
Ah non, ils risquent en effet de leader l'innovation sur le market linux, soit almost 1% du market web total! C'est clair que vous avez tout a craindre la dessus.
[^] # Re: bravo ...
Posté par thedude . Évalué à 2.
T'oublies tout ceux qui changent leur user agent et ceux qui bloquent xiti.
C'est donc 1.02% du parc mondial.
[^] # Re: bravo ...
Posté par gnumdk (site web personnel) . Évalué à 1.
Car, IE9 possède un nouveau moteur Js qui met une branler à Google Chrome et Firefox sur le test sunspider...
Certe, d'ici la sortie de IE9, ca laisse du temps aux devs de firefox de rattraper leur retard... et à ceux de Google de reprendre la première place.
[^] # Re: bravo ...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Et un parseur XML (un vrai, je veux dire) ? Il serait temps…
[^] # Re: bravo ...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: bravo ...
Posté par Nÿco (site web personnel) . Évalué à 1.
Non, mais sérieux, arrêter pendant 5 ans le développement d'un bout de soft aussi important, ils vont mettre du temps à faire leur rééducation...
Sans compter qu'ils ont un énorme boulet que les autres n'ont pas : la compatibilité ascendante.
En attendant quelques années de plus, IE ne peut que faire rire... ou pleurer...
[^] # Re: bravo ...
Posté par thedidouille . Évalué à 5.
Les distributions préfèrent avoir des binaires facilement debugable qu'optimisées. Elles optimisent plein de trucs, mais apparemment pas le build.
La version Windows est simplement beaucoup plus optimisée, lors de la compilation. Ce n'est pas un problème de code ou de volonté des développeurs (selon moi). Pour faire du développement Drupal, Firefox Linux (Ubuntu, Fedora, Mandriva) se prend une méchante raclée par rapport à la version Windows.
On peut obtenir des gains intéressants en recompilant Firefox avec les dernières optimisations de gcc. J'ai recompilé ma propre version en faisant du profile feedback il y a quelque temps, et ça marche pas mal (j'ai tout effacé, et j'ai pas fait ça de la bonne manière).
Peut-être qu'il faudrait revoir les options de build de Firefox ou des distributions.
[^] # Re: bravo ...
Posté par aurel . Évalué à 2.
http://www2.webkit.org/perf/sunspider-0.9/sunspider-driver.h(...)
Chromium 4.0.269.0 : 476 ms +/- 5.5%
Firefox 3.5.5 : 2549 ms +/- 3.3% 5.35x slower
Swiftfox 3.5.3 : 1062 ms +/- 0.7% 2.23x slower
(le tout testé sur une Kubuntu 9.10 AMD64 à jour ce matin)
[^] # Re: bravo ...
Posté par aurel . Évalué à 2.
Swiftfox 3.5.5 : 1141.ms +/- 1.7% 2.39x slower
Ainsi, en bonus, qu'un test de safari sur un macbook pro (moins rapide que ma machine principal)
Safari 4.0.4 : 423 ms +/- 0.9% (on a slower machine)
Safari, ca poutre.
[^] # Re: bravo ...
Posté par aurel . Évalué à 2.
[^] # Re: bravo ...
Posté par Grunt . Évalué à 6.
Firefox est un peu le Ubuntu des navigateurs (et ce n'est pas un reproche): il est destiné à apporter les premiers secours et la cure de désintoxication aux windowsiens totalement formatés par Microsoft. À bouffer IE, exactement comme Ubuntu veut bouffer Windows.
Mais je ne vois pas où est le problème si les utilisateurs d'OS libres ont des navigateurs plus performants que Firefox et tout aussi libres.. Après tout, si l'ensemble des gnulinuxiens passe à Epiphany/Konqueror/what else, ça changera quoi?
Firefox y perdrait très peu de parts de marché, et ce serait en faveur d'autres logiciels libres. Le marché se diversifierait au-delà de l'éternel duel IE/FX, ce qui ne pourrait que pousser les webmasters à produire du code "conforme aux standards" et pas "testé sur FX/IE", comme c'est encore trop souvent le cas.
Je préfère voir 10% d'IE, 80% de Firefox et 10% d'autres navigateurs, que 30% d'IE, 69% de Firefox et 1% d'autres navigateurs :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: bravo ...
Posté par alice . Évalué à 3.
[^] # Re: bravo ...
Posté par Grunt . Évalué à 3.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: bravo ...
Posté par alice . Évalué à 2.
Moi je le trouve assez rapide mon Firefox. Pas pour les jeux 4D en javascript, mais pour les sites normaux, ça va.
# Questions...
Posté par Melkor73 . Évalué à 2.
...
* des trucs spécifiques à Windows (Direct 2D rendering)
Concernant Electrolysis, les plugins seront dans des process séparés et c'est une excellente chose (tout le monde pense à ses déboires avec Flash effectivement...). Cependant, verra-t-on à terme un process par onglet, comme dans Chrome ?
J'ai tendance à penser que c'est limite crade : surconsommation mémoire (Ff n' pas besoin de ça...) et bonjour la pollution du gestionnaire des tâches quand on ouvre une trentaine d'onglets...
Utiliser un thread par onglet me paraît plus pertinent, non ?
Ensuite, sur le rendu Direct 2D, vous travaillez upstream avec les devs de cairo sur un backend ?
[^] # Re: Questions...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
oui.
La version 3.7 apportera la séparation des processus pour les plugins, et la 4.0, la séparation des processus dans les onglets.
>Utiliser un thread par onglet me paraît plus pertinent, non ?
bah non. parce que tu n'a pas une séparation complète. Si il y a un crash dans un thread, c'est tout le processus qui crash (la preuve avec les crash de Firefox, qui utilisent pourtant de threads un peu partout). Mais un crash dans un processus ne fait pas crasher les autres processus (en theorie, sauf si ce crash provoque un kernel panic :-)).
Après, au niveau consommation mémoire, faut voir comment cela va être géré.
>bonjour la pollution du gestionnaire des tâches quand on ouvre une trentaine d'onglets...
personnellement, je n'ouvre le gestionnaire de taches que lorsqu'il faut que je tue un processus, c'est à dire rarement....
[^] # Re: Questions...
Posté par Melkor73 . Évalué à 2.
Cela dit, je ne sais pas comment Ff est architecturé au niveau des threads...
Par contre, côté performances, j'imagine qu'autant de processus séparés, cela doit être également couteux au niveau des IPC, non ?
[^] # Re: Questions...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Notons aussi que grâce aux webworkers (ff3.5), les pages web ont la possibilité de réaliser en javascript des trucs dans un thread séparé, ce qui évite les temps de "chargements" trop long.
Sinon, au niveau IPC, je ne suis pas assez calé là dedans pour t'affirmer quoi que ce soit. Je sais juste que chez Mozilla, ils ont repris la lib IPC de chromium, avec une petite API par dessus pour que ce soit simple de communiquer entre processus via javascript.
[^] # Re: Questions...
Posté par Grunt . Évalué à 2.
Ça c'est une bonne nouvelle!
Parce que jusqu'ici, cette fonction de recherche remplaçait avantageusement Flash pour la fonctionnalité "monopoliser le CPU".
C'est très sensible sur une petite machine:
- Firefox avec une page, tout va bien.
- Firefox avec 10 onglets, tout va bien.
- Firefox sur une page plein de javascript, tout va bien.
- Saisie d'une suite de caractères dans la barre d'URL, qui déclenche la recherche de cette séquence de caractères dans plusieurs dizaines de ko d'historique et de cache: rien ne va plus.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# en effet
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 4.
J'ai vu sur debian des lenteurs indescriptible de Iceweasel, mais également avec un firefox 3.5 provenant du site Mozilla. Fuite mémoire à gogo, le processus prenait 1.5Go au bout de 2 jours. Et ça raaaaaame. Sur opensuse, avec la meme utilisation, meme extensions, meme sites, c'est bien + rapide, et je reste dans les 300 - 400Mo. Va comprendre.
Ensuite, faut savoir que Firefox utilise des accelerations XRender (ça c'est bien), notemment sur le scroll, mais du coup le resultat est inégal en fonction de la qualité des drivers video. Pareil que KDE4 donc.
# Travailler plus, pour plus de lapsus.
Posté par Rémi PALANCHER (site web personnel) . Évalué à 3.
Tu travailles vraiment trop /o\
[^] # Re: Travailler plus, pour plus de lapsus.
Posté par VoixOff . Évalué à 1.
Comme moi quoi :-)
[^] # Re: Travailler plus, pour plus de lapsus.
Posté par Donk . Évalué à 1.
;-)
# Thunderbird et Firefox dans une seule fenêtre
Posté par MCMic (site web personnel) . Évalué à 1.
Est-ce que ça ressemble à ça le navigateur mozilla tout-en-un nomé seamonkey? Est-ce qu'il est compatible avec les add-ons Firefox et tout ça?
[^] # Re: Thunderbird et Firefox dans une seule fenêtre
Posté par Simon (site web personnel) . Évalué à 1.
Firefox n'est pas là pour lire mes mails !
[^] # Re: Thunderbird et Firefox dans une seule fenêtre
Posté par CrEv (site web personnel) . Évalué à 3.
A voir encore plus l'intérêt de passer à du html5, balise vidéo et cache offline des datas...
Donc ptetre que firefox n'est pas un lecteur de mail en soit mais si il est quand même là pour lire mes mails !
[^] # Re: Thunderbird et Firefox dans une seule fenêtre
Posté par aurel . Évalué à 3.
http://www.onlinearcadegames.nl/index.php/R-Type.html
http://www.onlinearcadegames.nl/index.php/Rick-Dangerous.htm(...)
Pas de linux encore à l'époque, ca ne nous rajeunit pas !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.